Human Interface Guidelines

When phone apps first started arriving in bulk, opening a new one meant learning it from scratch. In one app the back button sat at the top left, in another it sat at the bottom center, and in a third there was no back button at all. Delete was red text in one app and a gray icon in the next, so people stopped before tapping anything to work out what it would do.

The people building the apps had it no easier. Every screen meant deciding from nothing how many tabs to allow, how large to make a button, where to put an alert. With taste as the only evidence, design reviews started with "I think" and ended without a decision. An app could take a month to build and still come back from app store review as not matching standard behavior, which meant reworking screens that had already been signed off internally.

Apple's answer was to settle those decisions in advance, as the company that makes the device. If the hardware maker also writes down the rules for the screen, the gestures that differed app by app collapse into one set, and a person opening an app for the first time already knows how to use it. Those answers live in a document usually shortened to HIG.

HIG removes the decisions a team used to make from scratch on every screen. The answers are already written as sentences and numbers, so a designer looks them up and spends the remaining time on what is actually specific to the product.

The document answers three kinds of question.

1. Concrete numbers. Up to five tabs along the bottom, a tappable area of at least 44 points on a side, back at the top left. The 44 points come from how much screen an adult fingertip actually covers, so anything smaller means hitting the neighboring button. Numbers like that one are the reason two designers can disagree about a layout and still reach the same answer within a minute.
2. Differences between devices. iPhone, iPad, Mac and Watch each get their own chapter. A mouse lands on a single point and can hit a small button, and a finger on glass cannot. The same feature therefore gets a different control on a Mac than it gets on a phone, and the document says which one.
3. Variations driven by user settings. There are separate sections on how a screen should look for someone who switched to dark mode and for someone who enlarged the system text. Accessibility — designing so the product works regardless of disability or circumstance — sits in the same place.

One more thing rides on top. App store review cites this document, so parts of it work less like advice and more like a condition for shipping. Using a standard control for something it was not meant for, or building a payment flow that departs from the document, gets flagged in review.

Nobody reads it front to back. You look up the one chapter that covers the screen you are about to draw, you quote it in a design review when opinions split over placement, and you skim the changed entries each time the operating system ships a new version. It behaves more like a dictionary than a book.

There are three ways to work without HIG, and the choice turns on which platform gets which product.

1. Material Design. Google's document of the same kind, and what Android follows. Shipping one feature to both platforms means writing the spec once and drawing the screens twice, because the two diverge — a confirm-delete dialog slides up from the bottom on iPhone and appears in the middle of the screen on Android.
2. An in-house design system. Teams that want screens shaped by their own brand define colors, spacing and controls themselves. Rebuilding behavior people already learned from the operating system, like back navigation or alerts, pushes the learning cost onto them. The usual compromise keeps HIG underneath and swaps in brand colors and a few custom UI components.
3. The stock controls of a cross-platform toolkit. Tools that build both apps from one codebase ship their own controls, some of which imitate the Apple shapes. That saves drawing every screen twice, at the cost of waiting for the toolkit whenever the operating system introduces something new.

Whichever route a team takes, the decision reaches down to the design tokens. Values that differ per platform get two sets, and values that don't — brand color, wording — get one. Splitting them at the token level keeps the platform differences in one place instead of scattering them across every screen.

"Let's check what HIG says about this before we decide."

A proposal to argue from the written rule instead of from taste.

"Six tabs puts us outside HIG, and that could get flagged in review."

The five-tab limit has been crossed, and that particular line is closer to a shipping condition than to advice.

"Material handles this differently on Android, so I'll draw this screen twice."

One spec, drawn separately against each platform's rules.

In the quarter Pagedeck shipped its first mobile app, Noa drew the document list screen. She carried over the web pattern — a three-dot menu at the top right holding delete and rename — and Theo pointed out that on iPhone people already expect to swipe a row left to delete it. The two opened the HIG chapter on lists, checked the recommended behavior, and made swipe-to-delete the default while keeping the three-dot menu alongside it.

The judgment ran the other way on the next screen. HIG has no entry for showing several people's cursors moving across a shared document, so that one kept the web pattern exactly as it was.

The common complaint is that following HIG makes every app look the same. Since the document fixes numbers and placement, identical output seems like the natural result. What it fixes, though, is the part people have learned as operation — tab counts, minimum button sizes — and it leaves color, typeface, imagery, voice and information structure alone. That is why apps built against the same rules look nothing like each other. An app that reinvents the gestures tends to be called awkward rather than distinctive.

The other misreading is that everything in the document is mandatory. After one rejection, every sentence starts to look like regulation. Most of it is guidance, and the entries tied directly to review are a specific few around payments and personal data. Miss that distinction and a team gives up variations the product actually needs on the grounds that HIG doesn't mention them.