The iPhone 5 comes with a gorgeous new screen that has a lot more space for your app’s content – 88 points (176 pixels) to be exact.
But like in the past with the Retina display, you need to do a little work to gain the benefits of the larger screen.
Luckily, it’s simple to “turn on” the new screen size. Then, with a little thought and design, your apps can make use of the added space in interesting ways.
If you haven’t already updated your app for the new 4-inch display, this tutorial will show you how easy it is and how it can improve your app!
Getting Started
First off, you need to have a version of Xcode that’s capable of building for the iPhone 5, which means at least version 4.5. You can find Xcode’s version by selecting Xcode\About Xcode. If you have an earlier version than 4.5, head to the Mac App Store and download or upgrade to the latest version.
Note: With Xcode 4.5, Apple dropped support for the armv6 instruction set. This means that apps you build with Xcode 4.5 and above won’t be able to run on the original iPhone, iPhone 3G, or the first two iPod Touches.
For the project code, you’re going to take what may be a walk down memory lane if you are a devoted reader of this site, and revisit How to Use Blocks in iOS 5 – the first tutorial I wrote for this site!
Even though the iOS Diner project from that tutorial had lovely artwork created by Ray’s wife Vicki, I was never really happy with how crowded it had to be to fit on the screen. This tutorial is the perfect opportunity to fix that!
Download the finished project from the old tutorial (plus some bug fixes) here to open the diner for business once more.
Open the project and immediately build and run it. Make sure you run the iPhone 6.1 Simulator, because all iPhone 5s will be running at least iOS 6. If the app does not come up in the iPhone 5 4-inch Simulator, change the device type in the Hardware menu and build and run again.
BOOM! The iPhone 5 Simulator in all its 4-inch glory!
Oh, but wait. What are those ugly black bars on both sides (indicated by the red circles)? It’s because the app isn’t iPhone 5 aware yet. You’re about to change that.
Hey, You’ve Got Space!
It’s a relatively simple matter to make your app aware of the fact that it’s capable of running on the 4-inch screen.
If you’ve been doing the proper thing all along (like I know you have been) and setting a launch image, then you already have some files like Default.png and Default@2x.png. All you have to do is add a Default–568h@2x.png launch image! You don’t need a non-@2x version since all 4-inch screens are retina. Simple, huh?
Download this new launch image named Default–568h@2x.png and add it to the project by dragging it from the Finder into the spot shown below.
Build and run.
First, the app loads with the correct, larger launch image:
But then…
Well, it’s not entirely automatic after all. You can see just how much space the new screen gives you to play with, but you can also see that, at least in this case, you’ll have to do some legwork to get it to behave correctly.
This is because this app was designed with the normal screen dimensions in mind, and doesn’t use autosizing, Auto Layout, or other techniques. You will fix that soon!
Working With Constraints
There are different techniques you can use to get your views to resize themselves according to the different screen dimensions, but in this tutorial you are going to use the Auto Layout system that was introduced in iOS 6. With Auto Layout, you can pin edges and set views to auto-expand or shrink.
Note: This tutorial just scratches the surface of working with Auto Layout. For a more in-depth look, check out the Beginning Auto Layout in iOS 6 series on this site. You can find the first part of the series here.
First, enable Auto Layout. It must be enabled on each storyboard file individually, allowing you to use it where necessary and leave things as-is if they already look good on the larger device.
In this project, there is only one storyboard file, named MainStoryboard.storyboard. Select it, then open the file inspector and check Use Autolayout, as shown below.
Now in the Diner App user interface, look at the right-facing arrow that lets the user select the next item from the available items.
It seems like it pins itself to the right so that when the frame gets bigger, the right arrow is the only one that pops over. You’re going to change it so it’s pinned to the left like the other views.
Select the arrow and then the Size Inspector. You can see the Auto Layout constraints already on the view.
At the bottom of the storyboard canvas, select the icon (the one that looks like a sideways “I”) and select Leading Space to Superview, as shown below.
You will see the new constraint is selected immediately.
Instead of having to recompile and rebuild the whole project, you can test the effect this will have on a 4-inch screen by changing the screen size in the storyboard. Do this either with the menu item Editor\Apply Retina 4 Form Factor, or with the form factor button at the bottom of the canvas that looks like a rectangle with an arrow at the top and bottom.
Hmm, that’s not quite what you were going for! Reselect the arrow and the Size Inspector to find out why.
Ah, you can see that there are three constraints now. One aligns the view to the top of the other button, which is correct. Another is the one you just added.
But that middle one, Trailing Space to: Superview, pins the right-hand side of the button to the right-hand side of the superview. So with the left-hand side pinned by your new constraint and the right-hand side pinned by the old constraint, Auto Layout has no choice but to stretch the middle when the screen is expanded!
Fixing this is easy, but before you do anything else, be sure to switch back to the small screen size or else things will not work out the way you expect. (To understand why, see the Note below.)
Then, simply select the gear icon for the Trailing Space to: Superview constraint and choose Delete. There’s no need to pin the right-hand side of the button to the superview.
When you switch back to the large screen size, it should look like the image below.
Ah, that’s better.
Why switch back to the small screen size? If you had deleted the constraint while displaying the larger form factor screen, Xcode would have added a new width constraint that forced the arrow to stay stretched out. So instead of fixing it, you would have broken it for both screen sizes!
This is because when Auto Layout is enabled, any change you make to the views or the constraints causes Xcode to recalculate the current set of constraints. Xcode always adds whatever constraints it thinks it needs in order to produce the view as it currently looks on screen. So if you delete a constraint while the arrow is stretched out, Xcode will add another constraint to keep it stretched out.
This is why, while working with Auto Layout, you will often see constraints appear that you don’t think you want. When this happens, simply deleting them usually won’t work, because Xcode will just put them right back. Instead, you need to create different constraints until Xcode decides the ones you want to delete are no longer necessary.
The Incredible Expanding and Contracting Diner
Now you need to expand the diner itself – that is, the background and counter images.
Switch back to the smaller screen size and select both the background and counter views: Image View – bg_wall.png and Image View – bg_counter.png, respectively. They already have leading constraints, so if you pin the trailing side, these views will stretch when the screen expands. Again, choose the pin icon…
Add the Trailing Space to Superview constraint…
And then hit the form factor toggle button to see the effect.
The background tries to expand as you expected, but the image isn’t large enough, so it just gets centered. You need to change the image when the app runs on a 4-inch screen. But there isn’t a mechanism to say, “Use this image for a 3.5-inch screen and this other image for a 4-inch screen,” so this is where you need to do a little coding.
In the storyboard, turn on the assistant view and control-drag the counter and background UIViews to create IBOutlets. Name them ibCounter and ibBackgroundImage.
Next select iOSDiner-Prefix.pch in the Supporting Files folder and add this line right before the last #endif at the bottom of the file (credit to StackOverflow):
#define IS_IPHONE5 (([[UIScreen mainScreen] bounds].size.height-568)?NO:YES) |
This will let you know whether or not you are running on a bigger screen. It just subtracts the size of an iPhone 5 screen, in points, from the size of the current device’s screen. If the answer is zero, then you know the device is an iPhone 5.
Using this macro, in IODViewController.m, add the following code to the end of viewWillAppear::
if (IS_IPHONE5) {
self.ibBackgroundImage.image = [UIImage imageNamed:@"bg_wall-568h.png"];
self.ibCounter.image = [UIImage imageNamed:@"bg_counter-568h.png"];
}
|
This code block checks to see if it is running on an iPhone 5 (large screen); if it is, it sets the images to the newer, larger versions. These images are already part of the starter project you downloaded.
You might be asking, “Hey, shouldn’t it be bg_wall–568h@2x.png?” Well, no. Remember UIImage automatically appends “@2x” to look for retina images. So even though you only included the bg_wall–568h@2x.png image, you select the image without the “@2x” appended at the end.
Build and run the app, and it should look like this:
Move Over, You’re Crowding Me!
Now there is a larger background for the app, but also a lot of unused space on the right side. Meanwhile, everything crammed together on the left side makes it awkward for Bill, the cashier, to do his job. You’re going to reposition him to use the extra space.
Once again, make sure you are editing the storyboard using the 3.5-inch form factor. Now select Bill (the view named Image View – person.png) and add a new Trailing Space to SuperView pin constraint.
Just as with the Next arrow, Bill already has a Leading constraint, so if you switch to the 4-inch screen now, Bill will be stretched. You know Bill works at a fast food restaurant but he hasn’t gained that much weight! Select the Leading Space to: Image View constraint and delete it.
Toggle the form factor switch again.
Great! Bill is now pinned to the right and moves into place on the larger screen.
Note: The item description area (it says “Hamburger” in the screenshot above) is also pinned to the right. But you didn’t change this. So what happened?
It’s because that image is pinned to the text label, which is pinned to the Bill image. So when Bill’s position is changed, the changes cascade down and update the description label and description image. Cool, huh?
Wait… Doesn’t Auto Layout Require iOS 6?
If you try running iOS Diner app right now in the iPhone 5.1 Simulator, it will crash on start-up. In fact, had you tried it, this would have happened right after you enabled Auto Layout on the storyboard. That’s because Auto Layout strictly requires iOS 6.
This may not be a big deal for your app, because at this time roughly 87% or so of users are using iOS 6, but it is something to keep in mind.
When you release an app, you have to decide the minimum version of iOS you will support. For newer apps, you may wish to choose iOS 6, but in this tutorial you’re upgrading an existing app. That adds the additional wrinkle that if you raise the minimum iOS version, your current users may not be able to upgrade to your latest software.
Basically, you have two choices:
- You can change the project’s deployment target, requiring the device to have that version of iOS for your app to run.
- You can make your app backwards-compatible.
Let’s go over both options. You can do either one, or both for this tutorial – or skip this entire section if you would prefer!
Changing the deployment target
To change the deployment target, simply select the iOSDiner project in the Project Navigator and then select iOSDiner at the top, under Projects. Choose the Info tab and change the iOS Deployment Target to 6.0 (at least).
Note that you can also change this setting directly on the iOSDiner build target in the Targets list, as shown below.
The difference between the two approaches is that the value in the specific build target overrides the value set in the project. This is useful if you have multiple build targets that need to deploy on different platforms.
Making the app backwards compatible
If you’d prefer to make your app backwards-compatible with earlier versions of iOS, then you’ll have to do a bit more work. If you’re using Storyboards, as in IOSDiner, then the easiest way to accomplish it is to create two different Storyboards, one that uses Auto Layout and one that does not. Then you’ll tell your app which to use when it starts up.
Right now the app is set to load a storyboard on launch. This is referred to by the project as its Main Storyboard.
For this dual storyboard approach, you need to stop the app from auto-loading a storyboard at launch. To do so, simply clear out the Main Storyboard field in the target’s Summary settings. Just remove the current value so it looks like the following screenshot:
Select MainStoryboard.storyboard and choose File\Duplicate…. Name your new file MainStoryboard-legacy.storyboard and save it.
Now select MainStoryboard-legacy.storyboard, set your editor to display the smaller form factor and uncheck Use Autolayout.
Now open IODAppDelegate.m and make the following changes from this article.
Add the following code just above the @implementation IODAppDelegate:
#define SYSTEM_VERSION_GREATER_THAN_OR_EQUAL_TO(v) ([[[UIDevice currentDevice] systemVersion] compare:(v) options:NSNumericSearch] != NSOrderedAscending) |
This defines a macro that lets you check the version of iOS on a device against some minimum version that you specify when calling it.
Replace application:didFinishLaunchingWithOptions: with the following:
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { // 1 UIStoryboard *mainStoryboard = nil; if (SYSTEM_VERSION_GREATER_THAN_OR_EQUAL_TO(@"6.0")) { mainStoryboard = [UIStoryboard storyboardWithName:@"MainStoryboard" bundle:nil]; } else { mainStoryboard = [UIStoryboard storyboardWithName:@"MainStoryboard-legacy" bundle:nil]; } // 2 self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]]; self.window.rootViewController = [mainStoryboard instantiateInitialViewController]; [self.window makeKeyAndVisible]; return YES; } |
Here’s what happening above:
- This checks the version of iOS running on the device. If it is at least 6.0, it loads the storyboard you worked on earlier with Auto Layout enabled. Otherwise, it loads the other storyboard that does not use Auto Layout.
- This sets up the app’s window with a view controller created from the appropriate storyboard.
Now you have two good options for how to deal with Auto Layout and device compatibility – but there’s one big question that remains.
What To Do With the Extra Space In Your Apps?
With this new expanded interface, there’s a lot more room to breathe. The changes you made were aesthetic rather than functional, and if you like, you can stop there when it comes to accommodating the new 4-inch screen. But what else could you do with this extra space?
To put the luxurious new space you’ve been given to use, generally speaking you’ve got two choices.
First, if the app is really data-driven, you can expand the view and show more data. This can be useful in apps that prominently feature lists or grids, such as a Twitter app. You can add another one or two list items per screen.
Your other option is to use the extra space to add functionality to your app. Looking at the Twitter example again, you could add a tab bar at the bottom that would allow for easy access to frequently-used or hard-to-access functions.
With the old 3.5-inch interface, the developers were just able to fit both turntables on the screen. For the user to access functionality like viewing the BPM or changing the tempo, the app had to change views and block the table.
The new iPhone 5-optimized app shows both turntables, some basic BMP information and a tempo slider all on one view.
Enhanced interfaces like these are great, but they bring up a major looming question: how do you design or update your existing apps to accommodate both the old 3.5-inch and the new 4-inch screens?
The answer depends in part on whether your app uses Storyboards or .xib files. If it does not and you are just creating your UI in code, then you could use something like the IS_IPHONE5 macro from earlier to find the device’s form factor and then adjust your UI elements accordingly.
If you are using Storyboards, then it’s easiest to do much the same thing you did to make this app backwards-compatible. That is, simply create multiple Storyboards and then in code, use something like the IS_IPHONE5 macro from earlier to decide which to load for the current device.
iOS Tutorial 
