Apple Human Interface Guidelines, What They Mean If You're Paying for the App

Most articles about the Human Interface Guidelines are written for designers. This one is written for the person paying the invoice, the founder or marketing lead who commissioned an iOS app and needs to know which parts of Apple’s rulebook can delay a launch or trigger a rebuild.

What are the Apple Human Interface Guidelines?

The HIG is Apple’s published guidance on how apps on its platforms should look and behave, navigation, typography, colour, touch targets, layout, accessibility and platform conventions. It is documentation, not a specification you can compile against, which is exactly why it causes disputes between clients and developers: two people can both claim to have followed it.

The practical version is narrower. A handful of HIG rules overlap with App Store Review Guidelines, and those are the ones that stop your release.

Which HIG rules actually get apps rejected?

App Store Review Guideline 4.0 covers design, and the rejections it produces cluster around a small set of issues. These are the ones worth naming in a contract.

Rule	What it requires	What happens if ignored
Minimum touch target	Tappable controls at least 44×44 pt	Rejection under 4.0, plus measurable drop-off on small controls
Dynamic Type	Text scales with the user’s system font size	Rejection risk and an unusable app for older users
Safe area layout	Content clears the notch, Dynamic Island and home indicator	Clipped UI on current devices; visible in review screenshots
Sign in with Apple	Offered wherever third-party social login is offered	Hard rejection under Guideline 4.8
Platform navigation	Standard back and tab patterns, not invented ones	Rejection for confusing navigation; higher support load
No “minimum functionality”	The app does more than a wrapped website	Rejection under 4.2: the most expensive one to fix

Guideline 4.2 is the one that should worry you most. If your app is a thin wrapper around your website, Apple can reject the entire concept, and no amount of design polish fixes that. Establish this before development starts, not after.

What does HIG compliance cost on a real project?

Compliance is cheap when it is a design constraint and expensive when it is a bug report. Dynamic Type is the clearest example: designing layouts that reflow at large text sizes is a Figma decision, while retrofitting reflow into built screens means revisiting every fixed-height container in the app.

The pattern holds across the list above. Safe area handling is a layout decision. Touch target sizing is a component decision. Sign in with Apple is an architecture decision that touches your auth backend. All three are cheap in week two and painful in week twelve.

This is why we run a HIG review against the prototype before any iOS code is written. It is the same review either way, the only variable is how much has been built on top of the assumptions it corrects.

How does this change your timeline?

Apple’s review turnaround is usually 24 to 48 hours, so the queue is rarely the problem. The problem is the cycle: reject, diagnose, fix, resubmit. A design-related rejection typically costs a few days of engineering plus another review round, and if you booked a launch campaign against the original date, that slip is the expensive part.

Plan for one review round in your schedule and treat a first-attempt approval as upside. Do not book paid media against an unapproved build.

What should you require from your developer?

Ask for these four things in writing before the build starts:

1. A design review against the HIG at the prototype stage, delivered as a written list of issues and fixes, not a verbal “we follow Apple’s guidelines”.
2. Named acceptance criteria in the contract: Dynamic Type support up to accessibility sizes, 44 pt minimum touch targets, safe area handling on notch and Dynamic Island devices, and Sign in with Apple if any social login exists.
3. Screenshots at the largest Dynamic Type setting as a delivery artifact. This single check catches most reflow problems and takes minutes to verify yourself.
4. Resubmission at the developer’s cost if the app is rejected for a design reason covered by the criteria above. This aligns the incentive correctly.

If a development partner resists point four, that tells you what they expect the outcome to be.

Does this apply to cross-platform apps?

Yes. Apple reviews what the user experiences, not what framework produced it. React Native and Flutter ship components that resemble native ones closely enough for most screens, but the specifics the HIG cares about (type scaling, safe area insets, touch target sizing, back-navigation behaviour) need to be checked explicitly rather than assumed.

The corollary is that your iOS and Android builds should not be pixel-identical. Users expect the platform conventions they already know. Keep the brand consistent and let the navigation differ.

Where the guidelines stop mattering

The HIG governs whether your app ships and whether it feels native. It says nothing about whether anyone wants it. We have seen HIG-perfect apps with no retention and scrappy ones with strong engagement, and the difference was always whether the product solved a real problem.

Treat HIG compliance as a floor (the cost of entry to the App Store) and spend your remaining budget on the thing that actually differentiates the product.

---

We build and ship iOS apps for U.S. clients from Sacramento, and we review designs against the HIG before code is written rather than after review rejects it. If you want a second opinion on an app that is already in progress, see our mobile app development work, our UI/UX design process, or get in touch for a scoping call.