Maybe you’ve never designed an iPhone app, and have no idea where to begin.
Maybe you’ve designed a dozen, but still want one place to reference best practices. Heaven knows Apple’s Human Interface Guidelines are awful to try and read.
Either way, this is the guide for you. I cover basically everything you need to know to create an iOS app that follows standard iOS 13 conventions .
Here’s what we’ll cover today:
For the first 5 or 6 years of iPhone releases, screen sizes were pretty manageable. If your design worked on a 320x480 screen, you were golden. Now , it’s the wild west out there. There are 3 new screen sizes from just the last 3 years!
Here’s the full list for your reference (dragto bookmark; get the downloadable PDF)
|Device||Artboard Size||Export Scaling|
|11 Pro Max, XS Max||414 x 896||@3x|
|11 Pro, X, XS||375 x 812||@3x|
|11, XR||414 x 896||@2x|
|6+, 6S+, 7+, 8+||414 x 736||@3x*|
|6, 6s, 7, 8||375 x 667||@2x|
|5, 5s, 5c, SE||320 x 568||@2x|
|4, 4s||320 x 480||@2x|
|1, 2, 3||320 x 480||@1x|
*display on phone is technically 2.61x
Use the most common iPhone screen size for your audience, but if you have any dense, data-heavy screens, make sure to test those on smaller screen sizes.
*Google Analytics records this at Audience > Mobile > Devices, and then go to the label that says “Primary Dimension” and set it to “Screen Resolution”
A design that works well on a narrower screen (375pt) will almost certainly work well on a slightly wider screen (414pt) – but the reverse is not true . So it’s always better to design for narrower screens first, then double-check and adjust for larger screens. Since height is less of a constraint, it matters less whether your art boards are, say, 667 or 812 pixels tall.
A “point” is a measure for designers to compare the sizes of fonts and UI elements across iOS devices. A “pixel” is a tiny square of light that your iPhone screen is made up of. Smaller pixels mean a clearer image , which is great. But if you merely make your pixels smaller, everything on the screen would get smaller too! To balance this, designers measure the size of elements on the screen in points . Once pixels were half as tall/wide as they started, we could just use a 2x2 square of pixels for every point (this is called @2x). And once pixels were roughly a third as tall/wide as they started, we could use a 3x3 square of pixels for every point.
Points is the unit that allows us to have higher resolution screens without all the elements on the page just shrinking. Yay, points ! That being said, occasionally designers use the terms interchangeably, and you’ll just have to know from context which they mean. Boo, designers.
While different iOS apps have different layouts, many standard pages will have a layout something like the following:
Note: in thebelow, I have an iPhone Sketch template that has rulers dividing these page areas, plus the status bar and home indicator. It allows you to start filling in this framework of the page very quickly.
If you’re interested in a specific section of the page, you can skip ahead to that section:
The status bar appears at the top of every page – except for some full-screen images, videos, or media.
The status bar contains the time, signal, wifi, and battery indicators, and can be written (text and icons) in either black or white.
The background to the status bar can be any color – or even transparent. To find variations on a color that contrast suitably against white, use the Accessible Color Generator .
If you’re using a status bar on anything except the lightest of images, you’ll probably want to use white text .
Or, if you want a minimal status bar over a variety of images, use a background blur .
This “frosted glass”-style status bar doesn’t add any additional colors, borders, or needlessly attention-attracting elements to the interface – it merely blurs whatever colors are below it, making the text more readable.
In the example above, the light gray page background color is the “default” color of the frosted glass, meaning the text above it should be black – not white.
Only since iPhone X do iPhones have the “notch” design and rounded corners on the border. Older iPhones (and all iPads) have a shorter, more compact status bar.
The nav bar is where the app displays navigation (surprise!), the page title, primary page actions, and – often – search.
You can think of the iOS nav bar as being comprised of up to three “rows” .
In myiPhone UI Sketch Template, I include guides at all of these demarcating where these rows typically sit.
(These measurements are not always exact, and iOS default apps deviate from them somewhat, but they will get you started)
So an iPhone app will show one, two, or three rows, depending on (a) the needs of the page and (b) the scroll state.
Use a single row if you just need to compactly display some page actions (even the page title is optional).
However, if you can afford the space, the default iOS app page layout contains two rows : one for page actions, and a second for a large page title.
But if you need to show search , then you need a third row (even if the first row is left blank!).
Now the screenshots above only show the pre-scrolled behavior. As soon as the user starts scrolling, iOS specifies for some interesting behavior.
If a search bar is important to see at all times, it merely moves up from the third row to the second row while the app is scrolled.
If it’s less important, it will disappear entirely – only visible when the user is at the very top of the page.
When iOS nav bar rows disappear upon scrolling, they will re-appear when the user scrolls back to the top .
Note that the transitions between states is animated totally smoothly – a small, yet characteristic detail of the iOS style.
On iOS apps, primary destinations in the app are listed as tabs across the bottom.
Let’s note a few things styling-wise:
And a few notes on the behavior of the tab bar and its buttons:
There should be 2-5 tabs in total. If you need to display more than 5, the fifth icons should be a “More” catch-all that shows other destinations on a quasi-when tapped.
New iPhones (X and more recent) all have a home indicator – a thin, rounded bar omnipresent at the bottom of the screen. Well, omnipresent except for when you’re already on the home screen.
It is black on all light screens, but can be made white on darker screens.
And by dragging it up some amount, you can navigate between apps and to the home screen:
Usually, the home indicator “owns” its own 34pt tall “box” that no other fixed elements can be shown in.
But scrollable lists can be shown scrolling under the home indicator – and you can even select the item directly under the home indicator by tapping. The home indicator only responds to swiping up.
Navigating between the main areas of the app is covered in thesection.
On iOS, you can navigate backwards in 4 different ways, depending on the context.
|Method of Navigating Back||Context in Which it Works|
|Tap “Back” action on top-left of screen||Any screen on which a “Back" action appears|
|Swipe right from left edge of screen||Any screen on which a “Back” action appears|
|Tap “Cancel” or “Done” action on top of screen|
|Swipe down on screen content||or fullscreen (e.g. photos, other media) views|
The top 2 ways usually apply to the same screens.
See thesection below for more on how to navigate away from them.
There are 3 primary entry points to search in Phone apps:
However, no matter where the search entry point is, the search experience looks fairly similar:
Optionally, you can show popular or recent searches below the search box. I cover some of the best practices for search experiences in my course on designing intuitive, easy-to-use apps, Learn UX Design .
Some tasks involve a single screen – or a linear series of screens – that you want users to complete without totally leaving the context they were in.
In iOS 13, we now have a perfect UI element for that: the modal sheet.
A modal sheet is a normal page that (a) slides up from the bottom covering almost all of the previous page, but (b) leaves the previous page visible, yet recessed, in the background.
Modals can be dismissed by:
Remember: “90% of mobile design is list design”. If you want to get good at designing iPhone apps, learn how Apple thinks about its lists (or, as they say “Table Views”).
Any time you’re making a list on iPhone, you need to ask yourself three questions:
Let’s cover each of these in turn.
What text do you want to display on each list item? You can choose:
To the left of the text , you can optionally display an icon or image.
Finally, there are a handful of options for the right-hand side of a list item:
There are more iOS paradigms for what you can do with lists not covered here – but this is an overview of some of the most common ways to using lists. For more, check out.
Usually we think of buttons as being colored rectangles with centered text – and iPhone apps certainly use those kinds. But if you’re coming from the world of web design, you might be surprised to realize that many buttons on iOS are simply either (a) icons or (b) colored text – in either (a) the nav bar (at the top of the screen) or (b) action bar (at the bottom of the screen).
However, iOS does have on-page buttons as well.
Because page-wide actions appear on fixed menus (theor action bar), many on-page buttons apply only to a certain part of the page – and hence will appear on cards.
One non-obvious thing about how iOS apps do input controls is they’re almost all styled as list items .
Text inputs appear like a list item with a hint that disappears on typing.
Switches appear within a list item with the label on the left and the binary choice switch on the right.
At first, it appears just like a list item with the label on the left and the value on the right, but if you tap on the list item, it expands into a special “spinner” control.
You can modify this to pick (a) just a time, (b) just a date, (c) both a time and a date, or (d) some other custom value. That being said, Irecommend against using this as a universal replacement for dropdowns. Instead, on mobile, you’ll often want to use the “picker screen” pattern – which is a great lead-in :wink:
If you’re ever tempted to use a dropdown (which youshouldn’t be – but let’s pretend), you probably should be using the picker screen pattern on iPhone apps. The whole idea is that you have something resembling a list item, but it actually leads to another page where you pick the value.
So, the ingredients:
(1) A single list item with a label, value, and chevron leads to (2) a page with many options in a list, one of which can be selected, and will show this state with a checkmark .
Once you’ve made your selection, you can navigatewith a swipe or by pressing the button in the upper-left.
For more on iOS typography (and, in particular, font sizes), see my full article on ithere.
iOS has a distinctive paradigm for styling text. Perhaps the most surprising lesson is that where many design systems style with size or uppercase, iOS styles with weight or color . We’ll unpack this lesson looking at many of the text styles across iPhone apps. Here’s a quick reference in case you want to skip ahead:
|Page title (unscrolled)||34pt bold #000|
|Page title (scrolled)||17pt medium #030303|
List item titles,
|17pt normal #000|
|Secondary text||15pt normal #8A8A8E|
|13pt normal #8D8D93|
Text input controls
|17pt normal, various colors|
|Action bar labels||10pt regular #8A8A8E|
Page titles are written in two distinct ways on iPhone apps.
When the user hasn’t scrolled yet (or has scrolled, but then scrolled back to the top ):
When the user has scrolled down :
The “default style” for text on iPhone apps is:
You can get a lot of mileage by making slight tweaks to this basic style.
For instance, while normal list items are written with the default text style, the Mail app shows email senders in bold – as it helps the sender’s name stand out from the subject line and preview.
Likewise, text-based link buttons are basically the default text, but with different colors.
And search field hint text is the default text, but a lighter gray.
iPhone apps have a standardized style for any supporting “secondary” text.
Any explanatory “captions” are given an even smaller, lighter treatment than secondary text.
With any design system, it can save you a lot of headache to just define a minimum size. For iPhone apps, that’s the action bar labels, at 10pt:
If you design an app icon specifically at the size that it appears in every possible location for every possible iPhone and iPad, you will end up needing to create a dozen variations of the same icon .
You’re welcome to do that.
(If you use Sketch, you can do it rather simply with their template – File > New from Template > iOS App Icon)
However, if you’re like me, you’d rather make sure the more common sizes on the more common (or newer) devices are covered, and call it. After all, isn’t the whole point of this @3x business that the individual pixels are too small to see?
Here’s Erik’s 80/20 iPhone app icon design plan:
Even though you should always export your icons as squares, Apple will cut out the corners using a type of shape called a superellipse.
A superellipse – or squircle – looks a lot like a normal rounded rectangle. In fact, the difference is basically invisible to the naked eye. Apple’s rationales for the swtich are (a) a superellipse more gently transitions from the straight part to the curved part, leading to an overall more organic shape, and (b) this aligns better with the corners of Apple’s hardware devices.
This really only matters if your icon has a border, in which case your border shape should be determined by a superellipse, not a rounded rectangle. Here’s how to create a superellipse/squircle in Sketch and Figma:
There are a couple other things you should probably know about if you’re designing an iPhone app. I will just go ahead and list them here:
Everything the user should be able to tap on – every button, every slider, every input control – should be at least 44x44 pts in size.
The only exception where it’s really excusable to break this is text links. In paragraph text, each line of text will likely be quite a bit shorter than 44pt. That means that (a) your links will have tap target of less than 44pt size and (b) if there are links in the same position in two consecutive lines of text, it will be pretty difficult for users to tap them accurately. While this can’t always be avoided, it’s worth knowing about this as something to minimize.
As of iOS 13, iOS has an OS-level “dark mode” setting, where participating apps have (generally) dark backgrounds and light text, instead of light backgrounds and dark text.
While iOS will automatically transition to the dark version if you’re using native controls and colors, you should understand the general principles of dark mode for any custom UI you do. Here are a few simple guidelines:
Creating dark UI is its own topic, deserving of its own guide – and its one of the things I cover in a lot more depth inLearn UI Design.
I’ve created a few resources for easy reference. Links and descriptions below :sunglasses:
Pixels, points, inches, oh my. This is a quick guide to each version’s iPhone’s screen size and resolution.
:link: FREE DOWNLOAD
This Sketch file (which you can also open in Figma) includes an iPhone 11 artboard with (a) rulers to make off common sections of the screen, (b) a mask with the notch and rounded corners, and (c) an easy-to-recolor status bar. Once you’ve downloaded it, open it in Sketch and choose File > Save as Template for easy access.
:link: FREE DOWNLOAD
Apple’s Human Interface Guidelines for iOS . Apple’s own standards are notoriously difficult to read through. First you have to wade through their abstract principles, and you constantly face an uphill battle against their hackneyed terminology (why are lists called “Tables” and filed under “Views”!? Shouldn’t that be under “Controls”? No, but apparently plain text is a “control” – just look under “Labels”!). Anyhow, I will say that once you adjust your mindset, the Apple cool-aid makes a lot more sense, and – let’s face it – if you’re designing an iPhone app, you’re going to be here anyways. Best get used to it.
iOS vs. Android App UI Design: The Complete Guide . OK, let’s say you think you’re going to be making an Android version of your iPhone app at some point. Best to start thinking about some of the design differences now. Who knows – you may end up stealing some great ideas from Android design principles. This article actually covers a few iOS design paradigms that I didn’t get to here. Worth the read!
The iOS Font Size Guidelines . One of the most unexpected parts of getting good at UI design is developing an intuitive sense of what font sizes to use . So, to help with that, I wrote the world’s most comprehensive guide to font sizes. One part is one iOS apps, and if you’ve gotten this far, you should probably read that too.
Ivo Mynttinen’s iOS Design Guidelines . The most comprehensive guide I could find besides this one on making human-readable iPhone app guidelines (besides this one :wink:). Fantastic read.
Did I miss anything? Something look wrong? Give me a shout at [email protected] . I’ll be continually updating this guide to be the most accurate and human-readable guide on the web for creating iPhone apps.
If this is your first time here, you might also be interested in:
Some people have some really nice stuff to say about the newsletter.
Praise for the Design Newsletter
Thank you for your newsletter. It’s possibly the best newsletter I’ve received since 1999, when I started freelancing.
Each time I receive an email from you, I'm like ‘Damn, this is a long email! No way will I read all of this’, then I began to read and I'm like ‘Damn, this is so freaking brillant’ and read it all.
UX Strategist, Freelance