Last Chance: RW Accelerator Bootcamps

Bootcamps start August 15th — Don't miss out!
Save 50% and go from novice coder to job-ready mobile developer in just 12 weeks.

Home Archive Tutorials

How to Port Your App to the iPhone 6, iPhone 6 Plus and iOS 8: Top 10 Tips

Check out our top 10 tips about how to port your apps to iOS 8 and the new devices and screen sizes!


  • Other, Other, Other


Update April 10, 2015: Updated for Xcode 6.3 / Swift 1.2

It’s the holiday season! Check out the geeky poem I wrote about this article to celebrate:

‘Twas the night before the Keynote, and no one could know
Whether new APIs would be part of the show.

Some wished for Siri, others Touch ID.
But when iOS 8 came, no one was ready.

Extensions, Swift, Metal and more.
And who would’ve guessed — universal storyboards.

Many cheered, but others started to think about support.
All these existing apps, so many we need to port!

No need to worry about porting, as this tutorial will show
New APIs and screen sizes to make your apps glow.

Follow these 10 tips and you’ll see.
iOS 8 is awesome! Ummmmmm, mom’s spaghetti?

Poems aside, now it’s time for the article itself – 10 handy tips about porting your apps to iOS 8 and the new devices – just in time for the holidays! :]

Getting Started

You might be thinking “I checked out my existing app on an iPhone 6 Plus and it displayed just fine”. You’re correct, your app should work just like before, but that doesn’t mean there’s no work to do!

Apple has done well with allowing existing apps to run in Scale Mode, and you’ll notice the app is simply scaled up to fit the larger screen. At first glance it seems okay, but you can see that the status bar is larger too. You’re definitely going to want your app to work in fullscreen mode; just look at the difference:

Fullscreen vs Scaled

Fullscreen mode allows the app to display much more information in the same screen space. Notice that the status bar size is different as well. The text may look too small in this photo, but it looks just right on the Retina HD Screen.

Now that you’re on-board to support fullscreen mode, there’s one more question that needs to be answered: Should you drop iOS 7 support?

You’re going to have to make the final call, but here are a few points to consider:

  • iOS 7 users will still have access to the current version in the App Store.
  • The large screen devices (iPhone 6 and iPhone 6 Plus) only run iOS 8 or higher.
  • iOS 8 adoption rate, although lower than what iOS 7 was in the same timeframe, is already over 60%.
  • All the glorious new APIs. :]


Alright, now that you’ve made up your mind, here are the top 10 tips for porting your app to the iPhone 6, iPhone 6 Plus and iOS 8, grouped into three sections.

Note: If you do choose to target iOS 7 for your update, you can still take advantage of the new APIs. Check out Supporting Multiple iOS Versions and Devices for tips on how to support multiple iOS versions and devices in the same app.

Section 1 – Supporting the New Screen Sizes

Tip 1: Adopting Adaptive Layout and the Universal Storyboard

If your app uses storyboards and auto-layout, good for you; porting will be a breeze. If not, right now is the best time to start doing so. Size classes require auto-layout, and with Universal Storyboards, Apple has made it pretty clear that storyboards will be a centerpiece for iOS apps in the future.

Furthermore, the latest SDK WatchKit won’t even work without one.

The good news is that if you haven’t adopted them yet, has some great tutorials on storyboards and auto layout. A couple of my favorites:

To take the first step towards implementing adaptive layout, you first want to turn your existing storyboard into an universal storyboard — a storyboard that can handle your interface for any screen size.

It only takes one click to do so! Open up your storyboard and go to the info panel (command + alt + 1) and check the box for Use Size Classes:
Screen Shot 2014-12-14 at 11.25.43 PM

You’ll notice that your views all turn into squares. Don’t get too excited though, as that doesn’t mean your app now supports the Blackberry Passport. It’s just an arbitrary size that now works for any size screen.

Your constraints should all be kept the same as before, and nothing has really changed (yet!). You can confirm this by using the new Preview mode in the Assistant Editor:

Screen Shot 2014-12-14 at 11.28.27 PM

What you can do now is set up your constraints independently for different size classes. Check out our Beginning Adaptive Layout for an in-depth tutorial on adaptive layout, size classes and universal storyboards.

Note: If your app is universal, chances are you have separate storyboards for your iPhone and iPad interfaces. You have two options here:

  1. Continue to use separate storyboards. Turn only your iPhone storyboards, or all your storyboards, into universal ones and still use them separately for the iPhone and iPad.
  2. Go all out and replace them with a single universal storyboard! This allows you to only maintain a single storyboard going forward. However, this approach likely requires quite a bit of work. Currently, there are no refactoring tools in Xcode to help you with this so you’re on your own with the conversion.

Tip 2: Enabling Fullscreen Mode and the Launch Screen File

As you recall, fullscreen mode is much better than scale mode, and all that work you just did to adopt adaptive layout doesn’t offer any rewards unless your app is in fullscreen mode. Fortunately, enabling fullscreen mode is very easy, and it comes with an awesome bonus perk!

According to Apple:

At runtime, the system looks for a storyboard launch screen file, so as to let the system know your app supports iPhone 6 screen sizes, including a storyboard launch screen file in your app’s bundle

If such a file is present, the system assumes your app explicitly supports the iPhone 6 and 6 Plus and runs it in fullscreen mode.

Wait – a launch screen storyboard? You’re probably asking, “Is that what I think it is? Do I no longer need to provide 20 launch screen images?”

Yes, yes and yes!

To get started, add a new file to your app by going to New File…. In iOS > User Interface, there is a new file type called Launch Screen that add — as the name suggests — a new launch screen to your app! Beware though, Xcode creates a rather unappealing one for you:

Screen Shot 2014-12-14 at 11.35.00 PM

Rather amusingly, after all that talk about storyboards, Xcode creates a xib for you. Go ahead and clear out the existing, hideous labels in the xib and set up the launch screen as you like. If you want to keep it the same as before, simply add a UIImageView with your launch image.

Finally, go to your project’s general settings and choose your new xib file for the field Launch Screen File, like this:
Screen Shot 2014-12-14 at 11.23.39 PM

Build and run your app on the iPhone 6 Plus simulator, enjoy your new launch screen and marvel at your app running fullscreen mode.

Note: If you still support iOS 7 and/or earlier, you still need to supply 4-inch launch images. If you don’t, your app will display in 3.5″ mode.

Tip 3: Better-Than Retina Displays and @3x Images

The iPhone 6 Plus brings with it a new Retina HD display with 401 PPI. To support that amazing resolution, you now need to supply images in 3 times resolution. Just like @2x images, all you need to do is supply @3x images and iOS will load the correct image for you.

Note:The iPhone 6 also has a Retina HD display, but has the same pixel density as previous Retina iPhones and still loads the @2x assets.

With your app in fullscreen mode you must feel quite happy.
There’s still much to do though, don’t leave in a hurry!

Section 2 – User Permission Changes

iOS 8 comes with privacy changes that users will sure love.
Unfortunately, your app will break if they are incorrectly made use of.

In this section, you’ll fix these issues and keep your users happy.
Just keep reading along, and follow these tips three:

Tip 4: Fix Location Permissions

iOS 8 uses two new permissions to request a user’s location: one that only receives updates when the app is running, and another to receive updates even when your app is not running.

Before, iOS would ask for permissions for your app automatically whenever you started to monitor the location. This changed in iOS 8, and you need to explicitly request permissions before starting the location updates.

To do so, you need to explicitly call requestWhenInUseAuthorization or requestAlwaysAuthorization on the CLLocationManager if the current authorization status is undetermined.

Simply add this call before you call startUpdatingLocation on the manager. Here’s a very simple example:

  self.locationManager = [[CLLocationManager alloc] init];
  self.locationManager.delegate = self;
  if ([CLLocationManager authorizationStatus] == kCLAuthorizationStatusNotDetermined) {
    [self.locationManager requestWhenInUseAuthorization];
  [self.locationManager startUpdatingLocation];

One last step: In your app’s info.plist, you need to add either NSLocationWhenInUseUsageDescription or NSLocationAlwaysUsageDescription as a new key, and enter a string that’ll show to the user with the permission-request prompt. For instance, “Location is required to show you nearby items.”

Screen Shot 2014-12-14 at 11.44.19 PM

iOS Simulator Screen Shot Dec 14, 2014, 11.44.36 PM

Tip 5: Fix Notification Registration

User notification permissions have changed, mostly to support actionable notifications. All the previous APIs are deprecated and will not work in iOS 8.

There are now two layers of notification permissions. Your app must first request permission to display certain types of notifications. Once the user grants those, you need to request permission to receive these notifications remotely.

Previously, you could call -registerForRemoteNotificationTypes: right inside -application:didFinishLaunchingWithOptions: and receive the delegate callbacks to check the status. If you did the same in iOS 8, you’d notice the delegate methods are not called at all.

This is because you need to request the first layer of permission first. Here is a simple example inside the appDelegate:

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
  // 1
  UIUserNotificationSettings *settings = [UIUserNotificationSettings settingsForTypes:UIUserNotificationTypeAlert | UIUserNotificationTypeBadge | UIUserNotificationTypeSound categories:nil];
  // 2
  [application registerUserNotificationSettings:settings];

  return YES;

- (void)application:(UIApplication *)application didRegisterUserNotificationSettings:(UIUserNotificationSettings *)notificationSettings {
  // 3
  if (notificationSettings.types != UIUserNotificationTypeNone) {
    // 4
    [application registerForRemoteNotifications];

// 5
- (void)application:(UIApplication *)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken {
  // ... (no changes needed)

- (void)application:(UIApplication *)application didFailToRegisterForRemoteNotificationsWithError:(NSError *)error {
// ... (no changes needed)

It is one more callback longer than before. Here is a quick explanation of the steps:

  1. You first create an UIUserNotificationSettings, a settings object that defines the type of notification your app needs to display, as well as the categories that define the actions.
  2. Call -registerUserNotificationSettings: and pass in the settings object. This prompts the user for the permissions.
  3. Once the user responds, the new delegate method -application:didRegisterUserNotificationSettings: is called. The notificationSettings passed in here do not necessarily match what you passed in from step 2. They describe only the permissions the user granted. You’d check `types` to verify which permissions were granted.
  4. If the user has granted you permissions, you can now call -registerForRemoteNotifications. Note how this method no longer accepts parameters. Those settings are now captured by the settings object, and here you’re only requesting to receive notifications remotely.
  5. You can then obtain the device token through the same callbacks as before.

Tip 6: Kindly Asking for Permissions…Again

If a user denies a permission the first time the prompt appears, they won’t see the prompt again. If users deny a permission that is essential, it’s common for apps to show an error page or an alert to direct users to Settings\Privacy to enable the required permissions. It was a bit clunky and many an app received a poor review due to this.

iOS 8 simplifies all this by providing UIApplicationOpenSettingsURLString, a constant string that takes users directly to your app’s settings when passed to -openURL:. It makes asking for permissions much simpler.

Add the following line to the action of a button or alert to take advantage of this:

[[UIApplication sharedApplication] openURL:[NSURL URLWithString:UIApplicationOpenSettingsURLString]];


Section 3 – Beyond Porting

Now your app functions on iOS 8, congratulations, the new APIs of iOS 8 await.
The porting of features is finally done. But with your app fully working, it’s now time to have fun :]

Tip 7: Unleash The Power of Swift

Using Swift introduces several benefits, most noticeably the reduction of file count and overall lines of code. You don’t have to rewrite any existing code with Swift but you can definitely start using it for new classes and files, even in existing projects.

To make sure that Swift and Objective-C work play nice in your project, follow these tips:

  1. When you add the first Swift file to your project Xcode will create a bridging header for you. Make sure you allow it to do so.
  2. If you want to use your Objective-C class in your Swift file, import your Objective-C header file into the bridging header using a standard #import.
  3. If you want to use a Swift class in your Objective-C, import the umbrella header ProductModuleName-Swift.h into your .m files, where ProductModuleName is the name of your module. In many cases this will be your project name, but you can double check in your project settings under Product Module Name.
  4. Make sure your Swift classes either inherit from an Objective-C class (i.e. NSObject) or are marked with @objc

To learn more about Swift, be sure to check out all our Swift tutorials and also our iOS tutorial books, most of which have been updated to Swift, or written about it.

If you want to learn more about using Swift and Objective-C together, refer to Apple’s Using Swift with Cocoa and Objective-C guide.

Tip 8: Significant API Deprecations/Updates

iOS 8 updates a few fundamental pieces of Cocoa Touch. UIAlertView, UIActionSheet and UISearchDisplayController all have new replacements that are much more pleasant to work with, and UIPresentationController now has much-needed control over the view controller presentation process.

UIAlertController replaces both UIAlertView and UIActionSheet with a clean, block-based interface. A simple usage example is:

UIAlertController * alert = [UIAlertController alertControllerWithTitle:@"Are you sure?" message:@"Once deleted this item cannot be recovered." preferredStyle:UIAlertControllerStyleAlert];

[alert addAction: [UIAlertAction actionWithTitle:@"OK" style:UIAlertActionStyleDefault handler:^(UIAlertAction * action) { [self deleteItem ]}];
[alert addAction: [UIAlertAction actionWithTitle:@"Cancel" style:UIAlertActionStyleCancel handler:{}];

[self presentViewController:alert animated:YES completion:nil];

As you can see, you don’t need a delegate anymore and you show it using -presentViewController: that just feels right. UIAlertController also brings new functionality like multiple buttons and simple configuration of text fields in alerts.

Take a look at the great article on UIAlertController from NSHipster to learn more.

UIPresentationController gives you all the control you could ever want when presenting a view controller. You can fully adjust the chrome, position and animations of presentations in a clean, reusable manner.

Check out the official documentation or Chapter 6, “Introducing Presentation Controllers” in iOS 8 by Tutorials to learn all about presentation controllers.

Tip 9: Cool New Visual Effects

One of the beloved additions in iOS 7 was the blur effect. Apple finally delivered this API in iOS 8 with the brand new UIVisualEffectView and UIVibrancyEffectView classes!


UIVisualEffectView is an effective way to de-emphasize the background and UIVibrancyEffectView makes the foreground really pop. They are optimized for performance, but if overused they will slow down your app’s performance, so be careful.

If you want to get started with visual effects hop right in to our iOS 8 Visual Effects Tutorial.

Tip 10: A New World of Options

This tutorial is about making your app run on iOS 8, and if you’ve followed the tips up to now, consider it a job well done. The good (bad?) news is this is still just the beginning, iOS 8 has just so much to offer!

There are numerous ways to extend the functionality of your app in iOS 8, and these were not possible before. Here are just a few more ways you can spice up your app:

  • Use WatchKit and create a Watch Extension for your app.
  • Create a Today Extension for users to see information in their notification panel.
  • Use Document Providers for users to share files between apps.
  • Add Actions to your notifications.
  • Integrate Touch ID to let users authenticate with ease.

And much, much more… make sure you take a look at iOS 8 Tutorials and WatchKit by Tutorials if you want to dig deeper into what iOS 8 and WatchKit have to offer.

Where To Go From Here?

iOS 8 opens the door to more functionality than ever before.
With all these new tools it feels like a beginning, once more.

I hope that you enjoyed this, and found these tips useful.
Now go on, dear friend, and create something joyful :]

This tutorial was quite crammed, and I hope it made sense.
Here are all the links, for a quick reference:

There is much do learn, but it is all so exciting.
Please share your thoughts and comments below, but remember, no fighting!




More like this