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! By Jack Wu.

Leave a rating/review
Save for later
Share
You are currently viewing page 2 of 3 of this article. Click here to view the first page.

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.

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.

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.

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

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

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.
Jack Wu

Contributors

Jack Wu

Author

Over 300 content creators. Join our team.