3.1 — Apple HIG overview

Opening scenario

You ship an app to App Review. Three days later: rejected. The reviewer’s note says “Guideline 4.0 — Design. Your app’s interface does not align with iOS conventions.” No specific bug. No failing test. Just a vibe-based “this doesn’t feel like an iOS app.” Welcome to the Human Interface Guidelines — the unwritten rules that are also written, in a 1,000-page document, that you’ve never read.

The HIG is not optional. It is the law that App Review enforces, the muscle memory your users already have, and the design vocabulary every iOS designer assumes you speak. This chapter teaches you the four principles, what each one looks like in code, and the rejection-bait patterns to never ship.

Concept → Why → How → Code

Apple’s four design principles

Apple distilled decades of Mac and iOS design into four principles. Every component, every transition, every icon is justified against these four words.

1. Clarity — Text is legible. Icons are precise. Adornments are subtle. Function drives form.
2. Deference — The UI helps people understand and interact with the content, but never competes with it. Translucency, blur, depth — used to show what’s underneath.
3. Depth — Distinct visual layers and realistic motion convey hierarchy and aid understanding. The cards-on-cards stack, the push-and-pop nav, the modal-from-below sheet.
4. Feedback — Every tap, gesture, and state change produces immediate, perceptible response. Haptics, animation, sound. If nothing happens visibly when the user taps, the user assumes the app froze.

Why this matters

The principles are not aesthetic preferences — they are cognitive load reducers. Users on iOS have been trained for 18 years to expect:

• A back chevron means “go back”
• A blue label means “this is interactive”
• A long-press shows a context menu
• A swipe-from-edge goes back
• A bottom sheet can be dragged down to dismiss

Violate any of these and the user has to learn your app before they can use it. The bounce rate spikes. Reviews complain “buggy” even when nothing crashed. App Review rejects.

Platform idioms per OS

Each Apple OS has a different “personality.” Memorize the headline patterns:

A common rookie mistake: building an iPad app that’s just “iPhone but bigger.” Apple explicitly calls this out in the HIG as the #1 reason iPad apps feel cheap.

The “wrong nav for the platform” trap

// Wrong on iPad: phone-style tab bar
TabView {
    Tab("Home", systemImage: "house") { HomeView() }
    Tab("Search", systemImage: "magnifyingglass") { SearchView() }
}
// ↑ Wastes the iPad's screen real estate. Reviewer will flag.

// Right on iPad: NavigationSplitView
NavigationSplitView {
    SidebarView()
} content: {
    ListView()
} detail: {
    DetailView()
}

SwiftUI’s NavigationSplitView automatically collapses to a stack on iPhone — write it once, ship to both.

Clarity in practice — text and contrast

// Wrong: hardcoded light-mode color
Text("Welcome")
    .foregroundStyle(.black)
    .background(.white)

// Right: semantic, adapts to dark mode and high contrast
Text("Welcome")
    .foregroundStyle(.primary)
    .background(Color(.systemBackground))

Use semantic colors (.primary, .secondary, Color(.label), Color(.systemBackground)) — never raw hex unless it’s a brand color. We’ll go deep on this in Chapter 3.3.

Deference — let content lead

// Wrong: heavy chrome competes with the photo
VStack {
    Text("My beautiful photo")
        .font(.largeTitle)
        .background(.thinMaterial)
        .padding()
    Image("photo")
}

// Right: photo dominates, label is unobtrusive
ZStack(alignment: .bottomLeading) {
    Image("photo")
        .resizable()
        .scaledToFill()
    Text("My beautiful photo")
        .font(.caption)
        .foregroundStyle(.white)
        .padding()
}

Photos app, Camera, Maps, TV — all let the content fill the screen. Chrome only appears on tap.

Depth — modals and transitions communicate hierarchy

// Right: sheet for "modal task" (compose, share, settings)
.sheet(isPresented: $showCompose) { ComposeView() }

// Right: full-screen cover for "immersive experience" (video, onboarding)
.fullScreenCover(isPresented: $showOnboarding) { OnboardingFlow() }

// Right: push for "next step in same task" (list → detail)
NavigationLink("Open") { DetailView() }

Don’t push a modal task; don’t sheet-present the next step in a navigation flow. Users read the transition direction as semantics.

Feedback — every action gets a response

import SwiftUI

struct LikeButton: View {
    @State private var liked = false
    var body: some View {
        Button {
            withAnimation(.spring) { liked.toggle() }
            // Haptic feedback
            UIImpactFeedbackGenerator(style: .light).impactOccurred()
        } label: {
            Image(systemName: liked ? "heart.fill" : "heart")
                .symbolEffect(.bounce, value: liked)
                .foregroundStyle(liked ? .red : .secondary)
        }
    }
}

Three layers of feedback: visual (icon change), motion (.bounce), tactile (haptic). The user feels the like.

In the wild

• Apple Photos is the textbook “deference” app — content fills the screen; chrome only on tap.
• Tweetbot (RIP) was famously over-chromed by some metrics — its loss to Twitter’s official app correlated with Apple-style minimalism winning.
• Airbnb rebuilt its iOS app around HIG principles in 2022 and reported a 13% increase in conversion — the case study is “respecting the platform pays.”
• Things 3 from Cultured Code is referenced in Apple design talks as the gold standard for following HIG on both iOS and macOS without feeling generic.
• Instagram on iPad is the canonical failure example — it’s still effectively a stretched phone app in 2025, and it has been rejected for awards and design recognition because of it.

Common misconceptions

1. “HIG is just suggestions.” It is enforced under App Review Guideline 4.0. Apps using custom non-standard controls for system tasks get rejected.
2. “I can use my brand’s visual identity instead of HIG.” Brand expresses through colors, typography, illustration, voice. Navigation, controls, gestures must be HIG-standard.
3. “My designer didn’t mention HIG.” Then your designer is wrong. Send them the link. Designers who design iOS without reading HIG ship apps that get rejected.
4. “Cross-platform consistency is more important than HIG.” No. Android users expect Material; iOS users expect HIG. Same app, two different navigation paradigms. Companies that try one universal design (looking at you, mid-2010s web-first companies) lose to platform-native competitors.
5. “HIG = boring.” Wrong. Apple’s own apps (Music, Maps, Health) are HIG-conformant and visually distinct. HIG is the grammar; you bring the poetry.

Seasoned engineer’s take

The HIG isn’t a document you read once — it’s a document you reference like a dictionary. Bookmark it. Open it when arguing with a designer about whether a particular pattern is okay. Send screenshots of HIG sections in PR review when someone tries to push a custom slider that isn’t a Slider.

The fastest way to internalize HIG: spend an hour deconstructing Apple’s own apps. Open Mail. Open Notes. Open Reminders. Count the gestures. Note the transitions. Watch what happens on long-press, swipe, drag. That’s the test set you need to pass.

Also: HIG changes every WWDC. The 2025 update added a whole new section on visionOS and refined the iOS chapter for Liquid Glass. Re-read your relevant platform’s chapter every June.

TIP: When in doubt, copy Apple. If you can’t decide between two patterns, find an Apple app that does the same task and copy that.

WARNING: Custom gestures that override system gestures (swipe-from-edge, top-pull, drag-to-dismiss) are an instant rejection. Don’t fight muscle memory.

Interview corner

Junior-level: “What are Apple’s four design principles?”

Clarity, Deference, Depth, Feedback. Be ready to give one example of each from an app you’ve used.

Mid-level: “How would you adapt an iPhone-only app to iPad?”

Use NavigationSplitView instead of NavigationStack. Replace tab bars with sidebars on regular size class. Support iPad-specific input: pencil, hover, keyboard shortcuts. Test in Split View and Stage Manager. Never just stretch the iPhone UI.

Senior-level: “You disagree with a designer who wants to ship a non-HIG pattern because ‘it’s our brand.’ How do you resolve?”

Frame the cost: app review risk, user training cost (measurable as drop-off in first-session analytics), accessibility regression. Propose A/B testing a HIG-conformant variant. If the brand pattern must ship, scope it tightly (one screen, not navigation), document the rationale, and revisit after launch metrics.

Red flag in candidates: Saying “we don’t really follow HIG, our designers do whatever they want” — signals a team that ships rejection-bait apps and burns review cycles.

Lab preview

You’ll audit a pre-made app for 6 deliberate HIG and accessibility violations in Lab 3.2 — HIG & Accessibility Audit.

Next: 3.2 — Figma for developers