Designing for iPad Power Users

An increasing number of people — myself included — use an iPad for work. There are plenty of apps designed with that in mind, but I often find rough edges, as if the developers haven’t quite considered that people are potentially spending their entire day using the software.

The needs of iPad power users aren’t conceptually different from those of desktop or laptop users, but the nature of the hardware and its capabilities tends to cause some things to be overlooked. Based on my own experience, here’s some stuff that you, as a developer, should think about implementing if your customers are working with their iPads.

The short version is that you need to think of your app as a workhorse for professionals. You want to eliminate friction, promote efficiency, and let people work the way they want to; that’s all just common sense. For a touch-screen tablet device running iOS, that means considering some of the stuff below. I won’t labour any of the points, because you’re a designer or developer and you can do your own research and thinking, but you do want to capture the market of people who want to get away from old-style computers, and enjoy the freedom of working with a more human device. The writing is on the wall.


You’d think that this would be universal knowledge by now, but there are still some iPad apps that only support one orientation; commonly portrait. You can’t know in advance, and shouldn’t try to dictate, how people will use their device. They’ll use it in both orientations during the same work session, quite possibly. Lots of pros put their iPad in a stand/case of some kind, and landscape is a very common orientation for those. Support both major orientations. Make your views dynamically sized and positioned, which will greatly help with handling all the different sizes of iPads your app might be running on, and you can get this almost for free. Here’s the documentation.

Handling the on-screen keyboard

You don’t need to do anything special to get input from the on-screen keyboard, but you do need to make sure your app copes when it’s not there — i.e. ensuring you don’t leave a big blank space where the keyboard normally is, and generally not laying out the interface weirdly. iPad power users routinely use external keyboards, the presence of which automatically hides the on-screen one. There’s also a small shortcuts bar running across the top of the virtual keyboard which may (or may not) still be there even if the virtual keyboard is hidden — and that goes for both orientations. There are several scenarios to be aware of. Make sure your UI isn’t screwed up in any of those cases, because it’ll be a big annoyance to users. Here’s the documentation.

Keyboard shortcuts

Using pointing devices all day is an amateur’s game, and on a touch-screen device, fatigue is an even bigger worry than with a mouse. Power users expect keyboard shortcuts on iOS every bit as much as on a desktop computer, so make sure your app provides them. Take a look at some of the iOS Omni apps for inspiration. Follow macOS guidelines on which shortcuts to use if you’re unsure; iOS certainly does. You can press ⌘H to go to the Home screen (which is conceptually similar to its “Hide this app” functionality on macOS). ⌘Space triggers Spotlight, just like on the Mac. ⌘Tab cycles through running apps. You get the idea. By common sense, the available shortcuts should change contextually, too — iOS has a nice feature whereby if you hold the ⌘ key, you’ll see an overlay listing the available shortcuts, inspired by CheatSheet on the Mac.

Add lots of shortcuts, and don’t forget to visually indicate focus and/or actions when necessary: remember that keyboard users don’t have the enforced context of having physically tapped an interface element. Here’s the documentation, and also a tutorial.


Data is valuable, and work data may be especially so. Think about encryption, and app-specific passcode locks, and supporting Touch ID. Don’t ask for any permissions you don’t need. Don’t send user data to your own servers. Protect privacy. Design for security from the start.

Sync and backup

Data sync matters to people, especially stupid people who don’t care about it until they’ve lost data (sympathy: low). Even if your app only runs on iPads (and not iPhones), pro users will conceivably have more than one such device, and in any case will maybe use sync as a kind of remote backup service too. Support sync for your app’s data — but be sensible about really big files. Also, be aware that lots of people use Dropbox for their files, instead of the notoriously unreliable (and tricky to robustly implement, so I hear) iCloud file storage.

Here’s the iCloud documentation, and the Dropbox API.

You’ll also want to look into supporting document storage providers, and allowing the export of user data selectively and en masse.

Sharing and Sending

All this means is supporting the standard Share icon (box with an up-arrow) that you’ll see in a lot of iOS apps’ toolbars. You want to let people share data, and send documents to other installed apps. You want to support AirDrop too. You also want your app to be a destination for sharing. So, do all that. Here’s the documentation.

Similarly, support cut, copy, and paste — and especially do support pasting into your password fields. It lets people with password managers (like 1Password) use their secure passwords, even if your app doesn’t natively let them trigger that functionality.

Split View

There’s a user interface control/layout called a split view, but that’s not what I’m talking about here: I mean the iOS 9-or-later feature whereby, on iPads, you can have two apps on screen at once. You really want to support this for iPad power users. Not just the “Slide Over” version; the full thing called Split View. It’s useful in all manner of circumstances, and if your app already handles the various orientations and screen sizes, it shouldn’t be a huge hassle. Amongst pro iPad users, apps that don’t support Split View are second class. Here’s the documentation.

Preserve state

We all switch from app to app, and when we come back, we want things to be the same as before. iPad apps are bad at this, particularly since (if you have lots of apps open), iOS will sometimes kill a less-recently-used one, and it’ll then have to fully launch again when you switch back to it. You always want to preserve state, so everything looks the same when the user returns. If you don’t, it’s hugely irritating. Here’s some stuff you want to track and preserve/restore:

I can’t provide a simple link to API documentation for this, but hopefully the logic is simple enough: notice whenever things change, notice whenever the app backgrounds or is killed, and restore the prior state next time. Use whatever you want to store the state. You’re a professional. I’ll leave it up to you.

Nice to have

Generally, think about what will help the user, particularly if they’re living in your app and trying to get serious work done. Whether your app is viable for those situations is entirely in your hands. Here’s some stuff that pros (and plenty of regular users) will appreciate.

And finally

Don’t forget about accessibility. Stay up to date with changes to OS functionality, and new features. Above all, charge a price that lets you stay in business. Professional users want the app to stay around for a long time. $20, $30, $40, more… all fine. We’ll pay.

The iPad is absolutely a platform for serious work. All it needs is apps that are up to the challenge.