Building Apps for iPhone XS, iPhone XS Max, and iPhone XR

Betsy Langowski: In 2017, the iPhone X was released.

Linking against the iOS 11 SDK let your app take advantage of the beautiful new display.

This year, we are introducing the iPhone XS, the iPhone XS Max, and the iPhone XR.

While iPhone XS has been completely redesigned from the ground up, the screen size is the same as an iPhone X, so this video will focus on the iPhone XS Max and iPhone XR with their all-new resolutions.

If your app primarily uses UIKit frameworks and you've already adapted your app for iPhone X, you should be in great shape.

All you'll need to do is link against iOS 12 to take full advantage of these great new phones.

If you need a refresher on how to update your app for iPhone X, and now iPhone XS Max and iPhone XR, check out the video, "Building Apps for iPhone X." This video walks you through making sure the TrueDepth camera doesn't occlude your UI, ensuring your UI elements are positioned away from the Home indicator, and other common adjustments that you may need to make.

While most of the heavy lifting is done for you by UIKit, you may still need to optimize your app, and this video provides guidance that is great for iPhone XS Max and iPhone XR, as well as iPhone X.

Let's talk about a couple of things that we've made better for you this year to make updating your apps for iPhone XS Max and iPhone XR a breeze.

If you watched "Building Apps for iPhone X," you remember the importance of testing in landscape mode.

One of the places this is critical is in collection views.

I've built this really simple sample app, which is just a collection view controller, embedded in a navigation controller, which is embedded in a tab bar controller.

There are offsets to space out the cells, but otherwise this is just using the defaults.

At first glance, in portrait, it looks really good.

But in landscape, this app has a problem: the cells on the left side are behind the TrueDepth camera.

In order to address this, the collection view's section inset reference needs to be set to the safe area, instead of the default content inset.

This can be done in code, and when the iPhone X was first released, that was the only way to do it.

But since this app was built with storyboards, in more recent Xcode, we can make this change directly in Interface Builder.

With the collection view selected in the storyboard, we can select the Size Inspector and change the Inset From value to safe area.

Now when I build and run my app, my collection view avoids the TrueDepth camera in landscape, no code changes needed.

Auto layout is the Cocoa and Cocoa Touch layout system.

If your app uses auto layout, you'll find that most of the work of optimizing for new screen sizes, like those on the iPhone XS Max and iPhone XR, is done for you.

If you aren't taking advantage of the great benefits you get from auto layout, now is definitely the time to update, because this year we dramatically improved its performance.

Here are some examples of iOS 11's auto layout performance in gray compared with iOS 12's auto layout performance in blue.

Look how much less time moving trees take in iOS 12 compared with iOS 11.

Using auto layout in your app just got a lot faster.

If you'd like a behind-the-scenes look at how we did it, check out the WWDC 2018 video, "High Performance Auto Layout." One change for iPhone XS Max and iPhone XR specifically is in the behavior of UISplitViewController in landscape.

It's a lot like how it works in Mail in portrait mode on iPad.

Take a look at this very simple test app I made running in the iPhone XS Max simulator.

My master view with four cells comes in with the press of a button and is dismissed similarly.

My app got this behavior automatically on the new hardware because I set a displayModeButtonItem.

This behavior will also be set if you use presentsWithGesture.

Let's take a peek at what this looks like in code.

In my App Delegate, I've gotten the UISplitViewController's displayModeButtonItem and set it as the left bar button item in the navigation bar for my customer to tap.

So now I'm opted-in to the behavior on the iPhone XS Max and iPhone XR.

I'm also setting presentsWithGesture to true.

This makes it possible for my customer to access the master view with a swipe.

This is optional, and it can be set to false if needed for your app.

One thing to note.

If you've relied on setting preferredDisplayMode to automatic, this is now the automatic behavior.

If you've done some customization and you'd like to opt out of this behavior, simply avoid using the displayModeButtonItem entirely and set presentsWithGesture to false.

You can also set preferredDisplayMode to allVisible.

OK.

Let's move on to talk about some common pitfalls.

Some apps may have a background image set to specific dimensions, or certain assets pinned to a spot on the screen.

This is most common in games, but your app may use a technique like this for a variety of reasons.

If your app has set a scaled image, when you run it on an iPhone XS Max or iPhone XR, you may notice your content is scaled incorrectly.

Unlike apps that use standard UIKit frameworks, while these phones are still new, you may need to do a little bit of special-casing and tell your app -- or the framework your app is using -- about the new screen.

The display dimensions for both the iPhone XR and iPhone XS Max are 414 points wide by 896 points tall.

As you're building your assets, keep in mind that the iPhone XR is a 2x device, and the iPhone XS Max is a 3x device.

So in pixels, the resolution of iPhone XR is 828 by 1,792 pixels.

The resolution of the iPhone XS Max is 1,242 by 2,688 pixels.

Caution! You should only hard-code screen dimensions if your framework absolutely requires it.

While this can make your game or similar app work right out of the gate, you should avoid using these methods unless you absolutely need to.

Please let UIKit do the work for you and use auto layout instead.

While it may be tempting to force your app to behave in specific ways on various hardware models, you should avoid making special cases per piece of hardware.

This will take time away from developing new features, and it's largely redundant work.

Additionally, when your code is running on a model of phone it doesn't recognize, unexpected problems can occur.

This can hurt your customers if you aren't able to update your app right away.

If you made a special case for your iOS app to run on iPhone X, now you have to redo all your hard work for iPhone XS Max and iPhone XR.

Even if you need to set dimensions within your app to accommodate graphical needs, do not search for a device model and gate behavior behind that string check.

You should never write code that reads like, "Is this an iPhone X? Do A.

Else? Do B." This is a great opportunity to make sure you have adopted safe-area insets universally throughout your app and save your future self a lot of time and effort.

Now is also a great time to be really diligent about how you're branching your code when you're looking for feature availability.

Just like the other iPhones you already support, such as iPhone SE and all iPads, iPhone XR doesn't support 3D Touch and dual cameras, so it's important that you don't rely on those behaviors.

Let's use 3D Touch as an example.

The Home app is a fantastic example of an application that uses 3D Touch on supported devices but provides the full feature set on devices that do not support 3D Touch, or for users who may have turned it off.

Checking whether a device uses 3D Touch is simple.

Let's take a look at some sample code.

First, check at launch whether or not the device supports the feature, as shown highlighted here.

However, remember a user can turn off 3D Touch while your app is running.

Therefore, you should also do this check as part of your implementation of the traitCollectionDidChange delegate method.

In either case, branch your code to use an alternative such as UILongPressGestureRecognizer for devices that don't support 3D Touch, so that the full feature set is represented for all devices.

When in doubt, make sure your code can handle nil and is robust enough to gracefully fail when getting back something unexpected.

For most apps, there won't be much work for you this year to support iPhone XS, iPhone XS Max, and iPhone XR, especially if you already are optimized for iPhone X.

If you need any support, there's lots available from the iPhone X videos and this year's WWDC 2018 sessions.

Check out the related content, and you can find more on developer.apple.com.