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.
Sign up/Sign in
With a free Kodeco account you can download source code, track your progress, bookmark, personalise your learner profile and more!
Create accountAlready a member of Kodeco? Sign in
Sign up/Sign in
With a free Kodeco account you can download source code, track your progress, bookmark, personalise your learner profile and more!
Create accountAlready a member of Kodeco? Sign in
Contents
How to Port Your App to the iPhone 6, iPhone 6 Plus and iOS 8: Top 10 Tips
20 mins
- Getting Started
- Section 1 – Supporting the New Screen Sizes
- Tip 1: Adopting Adaptive Layout and the Universal Storyboard
- Tip 2: Enabling Fullscreen Mode and the Launch Screen File
- Tip 3: Better-Than Retina Displays and @3x Images
- Section 2 – User Permission Changes
- Tip 4: Fix Location Permissions
- Tip 5: Fix Notification Registration
- Tip 6: Kindly Asking for Permissions…Again
- Section 3 – Beyond Porting
- Tip 7: Unleash The Power of Swift
- Tip 8: Significant API Deprecations/Updates
- Tip 9: Cool New Visual Effects
- Tip 10: A New World of Options
- Where To Go From Here?
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:
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:
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.
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:
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.”
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:
- 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. - Call
-registerUserNotificationSettings:
and pass in the settings object. This prompts the user for the permissions. - Once the user responds, the new delegate method
-application:didRegisterUserNotificationSettings:
is called. ThenotificationSettings
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. - 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. - You can then obtain the device token through the same callbacks as before.