How to design apps for all of Apple's screen sizes

Apple's app ecosystem has expanded massively in recent times

When the App Store first arrived, designing for Apple mobile devices was relatively straightforward. Sure, developers had to get to grips with touchscreens and gestural interaction, and rethink visual language for smartphone apps and games a world away from desktop conventions. But the iPhone was one device, with one screen size and one interaction model.

With Apple's current range of touchscreen devices, input remains similar to that first iPhone, but there are new gestures and additional features within iOS, mostly to cater for the larger iPad displays. The Apple Watch, though, accepts touch interaction alongside utilising the Digital Crown and voice input. And you interact with the new Apple TV using a remote rather than by directly manipulating objects on a screen.

Developers creating games to work across iOS and tvOS devices seem largely unconcerned. But then games often cope well with screens of very different sizes. "I do all my layouts in such a way they're scaled relative to a screen's dimensions," says games designer Paul Pridham, who admits that this "doesn't matter much, since most of my games are chunky and lo-fi by nature". Nitrome MD Matthew Annal uses another common trick for cross-device mobile games: his titles have a 'safe zone'. Important elements are kept within that frame, and elongated screens simply show more of the surroundings.

Seelemann's approach recalls modern web design: concentrate on content and show more as available space increases. Eternal Storms Software founder Matthias Gansrigler reckons this is even more important when tackling Apple Watch and televisions: "Start designing your interface with the smallest device you're targeting in mind." As screens increase in size, you can introduce more elements, although Gansrigler warns this isn't always necessary: "Sometimes, keeping things minimal is beneficial, even though space allows for more. It's all about the user experience: overwhelming someone can be as bad as underwhelming them."

When creating CARROT Weather for iOS, watchOS and tvOS, developer Brian Mueller admits he often just went with what felt right: "I played with layouts so it felt good on my main test device, an iPhone 6 Plus, but knowing what would work elsewhere. I had to cut some elements for smaller screens, and add stuff on iPad so the screen didn't feel empty. But that was basically it – doing what came naturally, while thinking about how things might work when scaled or rotated."

Sometimes, other practical considerations impact on layout, as Streaks creator Quentin Zervaas explains: "Building Streaks to work with over twenty languages forced us to think how text would fit and be laid out, which naturally made it easy to scale to different device sizes." For example, a string of German text takes more room than English – "which is like fitting something designed for a 4.7-inch screen into a 3.5-inch one" – while Chinese characters need less space. Apple's Auto Layout was a boon, aiding layout across multiple devices and also robust language support.

Screen sizes aren't the only problem stemming from multiple display sizes – pixel density must also be considered. Even iPads with different dimensions have the same resolutions; and some Apple devices require @2x graphics, while others prefer @3x. "That screwed me up when making CARROT Fit," admits Mueller. "I created hundreds of exercise poses as raster images at @2x, because that's all I needed originally." When @3x devices appeared, all the assets had to be remade. Mueller now recommends vectors: "With CARROT Weather, everything's saved out as PDF, and Xcode handles asset generation. I also use PixelCut's PaintCode to generate assets in code, to create different sizes dynamically."

Rasters can still work, but you must plan ahead. Producer Ron Packard, Jr. says he too has had "difficulty in needing to upgrade image sizes," and "faced the daunting task of redoing all our renders". So for game Castle Breakout, "all the renders are ginormous, and can be downgraded to smaller screens as necessary". For Annal, whose games mostly use pixel art, scaling can also be a problem: "So we tend to stick with a much lower than screen-density pixel size that matches the density of the lowest supported devices. That way, pixels look crisp on older devices, and newer ones have such high pixel density that everything looks great anyway."

In terms of specific user interactions, we ask whether scale can be a concern, not least on iPad Mini. Seelemann, whose Ulysses is mostly keyboard-driven, mulls that "Apple determined 44pt is the minimum size every element should have" and as long as you follow along with that, you should be okay. "So although some devices have different PPI values, users will have adjusted to them. We don't see a need to deviate from Apple's recommendations."

In fact, some developers say Apple's rapidly expanding ecosystem may soon make such decisions commonplace. "I design for a 'main' device and then adapt my work for others, but then indie developers don't have access to the full range of devices for testing," explains developer Álvaro Maroto Conde. Complaining developers can't all afford to keep investing in new hardware every six months, Conde says they must take their chances with one or two and the "buggy emulator". He adds Apple's secrecy combined with the "race against launch dates" also results in App Stores stuffed with software that's "not properly tested, and proffers this might have instigated Apple's surprising decision to issue Apple TV dev kits.

Where possible, though, Gansrigler says developers should try to get at least one example of each major piece of kit they intend to ship something for. Primarily, this is because simulators are rarely as nuanced as the real thing: "The Xcode tvOS simulator doesn't do the Siri Remote justice, for example. You use a mouse or trackpad, but the remote's touch-sensitive area is used with a thumb. You must try it and get a feel for how it works." Additionally, he says new methods of interaction may need thought when porting apps from other systems: "Tap a Siri Remote touchpad edge and focus advances one step in that direction. That interaction is not available out of the box on iOS, and so must be considered when bringing an app to Apple TV."

Given the variances between devices, then, should they be considered separate platforms? And if so, how do you create coherence when a single universal app (in reality separate binaries, but this is invisible to the user) is made available for them all? "A lot comes down to branding and staying true to the spirit of your app," suggests Annal. "If you echo the same visual identity while retaining what makes your product special, it won't matter that inputs or screen sizes change."

This, according to Zervaas, must be twinned with an awareness of usage. With Streaks, a key feature is the payoff people feel on tap-holding a task to mark it as done. "But this interaction model isn't possible on Apple Watch or Apple TV," he says. "On Apple Watch, we therefore use Force Touch, which is a different interaction model but still provides that visceral feeling of having completed a task. On Streaks Workout for Apple TV, we use a simple click on the remote to mark exercise as done. This suits the style of app, but you still get the payoff of an animation filling up the progress bar and showing the big tick."

Any notion of trying to go too much further, effectively creating the same app across platforms, is roundly dismissed. "Our goal as designers and developers is not to reduce our workload, but to make great products," says Murrison. "Remember common UI frameworks across Mac and Windows? Horrible. You end up with something that's not at home anywhere. It's the same when building apps for different device families in the Apple ecosystem."

Successful development for the modern Apple ecosystem is, then, primarily about context; as Thomson notes, you must "where possible design for the strengths of each platform". With PCalc, he reasons people won't perform long multi-stage calculations on a watch, but might tot up groceries or split a bill. "So while my app on tvOS, iOS and watchOS is similar from a coding perspective, the interfaces are designed to fit – even on iPhone and iPad, you do things differently."

All this choice, though, could also serve as a warning of an ever more complex future. We began by noting things were once simple: one device; one screen size; one interaction model. Now, although Apple's ecosystem will never have the diversity of Android, it will continue to grow. "You'll see new challenges, such as iPad's Split View," says Seelemann. "In one release, this introduced five completely new UI sizes with unprecedented aspect ratios. It became clear apps must support any arbitrary screen size. Optimising for them all is no longer feasible and no longer makes sense."

According to developer Enrico Susatyo, anyone creating apps for Apple kit should no longer be surprised by such changes. "Apple is good at ushering developers towards the future of its platforms without revealing much," he says. "In 2011, we got Auto Layout, a year before the iPhone 5. Size Classes appeared a year before the iPhone 6, making it easier for developers to support bigger iPhones and iPads. Image Assets were introduced before @3x Retina devices."

Thank you for reading 5 articles this month* Join now for unlimited access

Enjoy your first month for just £1 / $1 / €1

*Read 5 free articles per month without a subscription

Join now for unlimited access

Try first month for just £1 / $1 / €1

Craig is an editor, writer and designer. He writes about design and tech, specialising in Mac, iPhone and iPad, and has written for Creative Bloq, Stuff, TechRadar, MacFormat, The Guardian, Retro Gamer and more. You can view more of his writing on his blog, Revert to Saved.

How to design apps for all of Apple's screen sizes

Playing the game

What feels right

A question of scale

A sense of focus

Together, but apart

Perfect fit

Related articles