Professional Documents
Culture Documents
In this article, we’re going to cover basically everything you need to know to design
an iPhone app following standard iOS 16 conventions and style.
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.
FRAME SIZE
DEVICE EXPORT SCALING
(E.G. FOR FIGMA)
Frame size. This is the “point size” or “@1x” size of a given device. I strongly
recommend designing on frames of this size for a given device. (Here’s an
explanation of points vs. pixels)
Export scaling. This is how much bigger to make a raster image (PNG, JPG)
when exporting to take maximum advantage of the higher resolution of some
devices.
If you’re recording analytics on your current app or website, check those* for
your audience’s most common screen sizes
If you’re designing an app for a general audience, use the overall most popular
iPhone screen size: 375x812pt or 375x667 pt (but as they’re the same width, it
doesn’t make much difference)
If you’re designing an app for a tech- or design-savvy audience, the most
popular iPhone screen size is likely the newer 390x844 pt
*Google Analytics records this at Audience > Mobile > Devices, and then set Primary
Dimension 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.
If you’re interested in a specific section of the page, you can skip ahead to that
section:
Status bar
Nav bar
Tab bar
Home indicator
The iPhone 14 Pro and 14 Pro Max contain a taller status bar with the camera and
sensor area completely surrounded by screen pixels. This is called the “Dynamic
Island”, since it can vary slightly.
Either way, 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 the 10th generation of iPhones (iPhone X and newer) do iPhones have the
“notch” design and rounded corners on the border. Older iPhones (and all iPads)
have a shorter, more compact status bar.
You can think of the iOS nav bar as being comprised of up to three “rows”.
(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.
The selected icon is denoted with the app theme fill color
The labels are 10-11pt text in SF, the default font
The background can be ever-so-slightly translucent and have a background
blur – the “frosted glass” effect, a la the nav bar
And a few notes on the behavior of the tab bar and its buttons:
Different tabs remember their state. If you travel to a certain destination in one
tab, switch to another tab, then switch back to the first tab, you’ll be where you
left off in that tab – not the “main screen” for that tab
If you tap the active tab, you’ll return to the “main screen” for that tab
The tab bar is always visible within the app, except:
When a keyboard is shown
When a modal is open (during critical tasks, the user should focus on the
task at hand rather than navigate to other parts of the app)
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-picker screen
when tapped.
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.
Navigation in iOS Apps
Navigating Back
On iOS, you can navigate backwards in 4 different ways, depending on the context.
iOS Search
There are 3 primary entry points to search in Phone apps:
Pressing the “close”-like action at the top (above, it’s “Cancel” in the upper-
right)
Swiping down on the modal card itself
Any time you’re making a list on iPhone, you need to ask yourself three questions:
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:
A (right-pointing) chevron. Almost the default, this lets users know they’ll be
navigating to another screen
Text and a chevron. This means the user can navigate to another screen to
choose the value to be shown here
A checkmark. Allows the user to choose between one of the list items in that
group (Note: not multi-choice, as web checkbox lists are)
Switch. Allows the user to toggle the property that list item refers to on or off.
Text buttons. Use a system color to link to another page or flow. Use red text to
represent a “destructive action” – turning something off, deleting it, removing it,
etc.
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 input controls.
iOS Buttons
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 (the nav bar or action bar), many
on-page buttons apply only to a certain part of the page – and hence will appear on
cards.
Tap one, and you’ll see a date (or time) picker control appear in place.
These controls can pick (a) just a time, (b) just a date, (c) both a time and a date, or (d)
some other custom value. And there’s also a “spinner” style layout you can use (not
pictured).
Pull-Down Menus
A newer control in iOS is the pull-down menu, which shows some extra
options/actions without navigating to a different screen – much like a dropdown
control on web browsers.
iOS Picker screens
The pull-down menu (above) is useful if you need to display a fairly short list of
options, but for anything more complex, try the picker screen pattern.
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 navigate back with a swipe or by pressing
the button in the upper-left.
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:
Paragraph text,
List item titles, 17pt regular #000
Links
When the user hasn’t scrolled yet (or has scrolled, but then scrolled back to the top):
Size: 34pt
Font weight: bold
Color: #000
Dark mode color: #FFF
Alignment: left
Size: 17pt
Font weight: medium
Color: #000
Dark mode color: #FFF
Alignment: center
Default Text Styling for iPhone Apps
The “default style” for text on iPhone apps is:
Size: 17pt
Font weight: normal
Color: #000
Dark mode color: #FFF
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.
Size: 15pt
Font weight: normal
Color: #3C3C43 at 60% opacity
Dark mode color: #EBEBF5 at 60% opacity
Size: 12pt
Font weight: normal
Color: #C3C43 at 60% opacity
Dark mode color: #EBEBF5 at 60% opacity
Also note that sometimes this tertiary size is used in a secondary manner – i.e. there’s
only size 17 and size 12, with no size 15 text in between them.
Size: 10pt
Font weight: normal
Color: #999 (when unselected)
Dark mode color: #757575 (when unselected)
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?
1. Create a square icon that looks good at 60x60px (and verify it looks good
masked with the Apple superelljpse*)
2. Blow it up to @2x (120x120px) and optionally adjust it to be as pixel-perfect as
you’d like
3. Blow it up to @3x (180x180px) and optionally adjust it to be as pixel-perfect as
you’d like
4. Blow it up to 1024x1024px
5. Export all 4 sizes as PNGs. Done
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 swich 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 Figma and in Sketch:
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.
Text colors are inverted. It’s a bit of an oversimplification, but black text
becomes white, dark gray text becomes light gray text, and middle gray text
stays basically the same. If you look at the typography styles above, you’ll notice
iOS actually drops a few extra shades and simplifies the text colors for their dark
theme. If you can’t tell whether you should make a middle-brightness gray
darker or lighter, go with the option that has a higher contrast text contrast
against its background.
Background colors are shifted. Unlike text, where darker colors become lighter,
the background colors are all just shifted darker. If a background color was
lighter in light mode, it’s still lighter in dark mode. Why? Because light comes
from the sky. If you understand that, you’ll understand we’re relying on
background color for depth cues (unlike text). And so it works in a totally
different way.
Theme colors are translated to pop against dark. Any accent colors that you
were previously using on light backgrounds now need to pop similarly against
dark backgrounds. Since white has a brightness of 100% and black has a
brightness of 0%, this often means you’ll be lowering the brightness of bright
colors (and, in my greater theory of color adjustments, raising their saturations).
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 in Learn UI Design.
Downloads
I’ve created a few resources for easy reference. Links and descriptions below
FREE DOWNLOAD
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 ). Fantastic read.
Wrapping It Up
Did I miss anything? Something look wrong? Give me a shout at erik@learnui.design.
I’ll be continually updating this guide to be the most accurate and human-readable
guide on the web for creating iPhone apps.
Some people have some really nice stuff to say about the newsletter.
— TRICIA LITTLEFIELD
FOUNDER, THESIMPLEWEB
— JEAN-PHILIPPE
UX STRATEGIST, FREELANCE
Design Hacks
Email Address
First name