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

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.

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:

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.”

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

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.