Human Interface Guidelines in Practice

This content was generated with the assistance of AI and should be verified against the official documentation before being relied on in production; see the section bibliography for the reference material consulted while preparing these pages.

Apple’s Human Interface Guidelines (the HIG) are the design counterpart of the API documentation: where the documentation says how to build a sidebar, a toolbar or a sheet, the HIG says when each is the right choice, how it should behave on each platform, and what people will expect from it. An app that follows the HIG feels native without extra effort, because it reuses conventions that people already know from the system apps. This page is written against the guidance that accompanies iOS, iPadOS, macOS, watchOS and visionOS 27, with code built with Xcode 27 and Swift 6.4 and FieldNotes keeping a deployment minimum of 26; guidance and APIs that exist only on the 27 releases (and iOS 27.1 for iPhone Duo) are labelled as new and guarded with if #available.

This page summarizes and links. The HIG is long, carefully written, illustrated, and updated several times a year, so the only reliable way to use it is to read the pages themselves; nothing here reproduces their text. What this page adds is a map of the HIG, a short explanation of why each key foundation matters, and, for each one, the concrete decision FieldNotes made and the SwiftUI code that implements it. The design system that the 27 releases share (Liquid Glass, materials and icons) has its own page, Liquid Glass, Materials and Icons, and accessibility, which the HIG treats as a foundation, is covered in depth on Accessibility.

How the HIG Is Organized

The HIG’s landing page groups its content into six sections. Knowing what each holds is the difference between finding an answer in a minute and reading for an hour.

Section What it holds When FieldNotes consults it

Getting started

The design principles, and one "Designing for …​" page per platform (iOS, iPadOS, macOS, tvOS, visionOS, watchOS, games, and, new in 2026, iPhone Duo) describing the device’s display, ergonomics, inputs, typical sessions and system features.

Before adding a platform target, and whenever a feature feels "ported" rather than native.

Foundations

Cross-cutting topics that apply to every screen: accessibility, app icons, branding, color, Dark Mode, icons, images, immersive experiences, inclusion, layout, materials, motion, privacy, right to left, SF Symbols, spatial layout, typography, writing.

Continuously; every section of Key Foundations Applied to FieldNotes below starts here.

Patterns

Common user tasks and flows: onboarding, launching, loading, searching, entering data, feedback, modality, multitasking, undo and redo, settings, file management, drag and drop, managing notifications, and more.

When designing a flow (capturing a note, searching notes, undoing a delete) rather than a single control.

Components

The system controls and containers, grouped as content, layout and organization, menus and actions, navigation and search, presentation, selection and input, status, and system experiences (widgets, Live Activities, complications).

When choosing between two controls, for example a sheet versus a popover, or a segmented control versus a picker.

Inputs

How people control the device: gestures, keyboards, pointing devices, Apple Pencil and Scribble, the Digital Crown, eyes, the Action button, Camera Control, game controllers, remotes.

When adding keyboard shortcuts on iPad and Mac, crown handling on the watch, and gaze-and-pinch on visionOS.

Technologies

Design guidance for Apple technologies an app integrates: Siri, widgets-adjacent services, Apple Pay, Sign in with Apple, iCloud, Maps, machine learning, generative AI, SharePlay, Wallet, and more.

When FieldNotes adds a system integration, for example the on-device summaries of Apple Intelligence and Machine Learning.

Three reading habits make the HIG far more useful:

  • Read the "Platform considerations" section at the bottom of each page. Most topics have one common body and then platform-specific notes; the differences that matter (a menu bar on the Mac, the Digital Crown on the watch) are there.

  • Follow the "Developer documentation" links. Almost every HIG page ends with the SwiftUI, UIKit and AppKit symbols that implement it, which is how the design guidance and the code on this site connect.

  • Watch the change log. Each page lists its revisions, and the landing page highlights new and updated guidance; after each WWDC and after hardware launches (iPhone Duo in 2026) several pages change at once.

Apple also publishes design templates and the SF Symbols app on Apple Design Resources, which designers use alongside the HIG.

Figure: The Structure of the HIG

The mind map below shows the six sections, with the pages this site relies on most expanded under each.

mindmap root((Human Interface Guidelines)) Getting started Design principles Designing for iOS Designing for iPadOS Designing for macOS Designing for watchOS Designing for visionOS Designing for iPhone Duo Foundations Layout Color Typography Dark Mode Materials SF Symbols Motion Writing Privacy Accessibility Patterns Onboarding Searching Entering data Modality Undo and redo Settings Components Navigation and search Presentation Menus and actions Selection and input System experiences Inputs Gestures Keyboards Pointing devices Digital Crown Eyes Technologies Siri iCloud Maps Generative AI

The Design Principles

The HIG opens with a short page of design principles that the rest of the guidelines build on. They are grouped under eight themes. The table paraphrases the intent of each theme in one line and records how it shaped FieldNotes; read the design principles page itself for Apple’s wording and the full set of points under each theme.

Theme Intent, in brief FieldNotes decision

Purpose

Know what the product is for, and put its most important job first.

The app does one thing: capture and find notes in the field. Capture is one tap from every screen (CaptureButton); everything else is secondary.

Agency

Get people to their task quickly, let them move freely, and make mistakes easy to undo.

No sign-up wall; the note list opens straight away. Deleting a note can be undone.

Responsibility

Be clear about what the app does with people’s data, and collect only what it needs.

Location is requested only when the user attaches a place to a note, with a specific purpose string.

Familiarity

Reuse concepts people already know and keep behavior consistent.

Standard NavigationSplitView, List, toolbars and sheets; no custom navigation scheme.

Flexibility

Design for everyone, every input method, and every platform the app supports.

Dynamic Type, VoiceOver and keyboard support on every screen; a tailored layout per platform.

Simplicity

Include only what is needed, say it concisely, and make hierarchy obvious.

A note has a title, a body, tags and a notebook. Nothing else is required to save one.

Craft

Be deliberate about every detail and keep refining after shipping.

Adopts each year’s system design (Liquid Glass in 26, iPhone Duo layouts in 27.1) rather than freezing a custom look.

Delight

Know the feeling the app should evoke, without letting decoration get in the way.

Calm and practical: subtle symbol effects when pinning, no celebratory animations over the user’s work.

The Agency decision above is a good example of how a principle becomes code. SwiftUI exposes the window’s undo manager in the environment, so a delete from the list registers its own undo, and Shake to Undo on iPhone, Command-Z on iPad and Mac, and the Edit menu all work without further effort:

import SwiftUI
import FieldNotesModel
import FieldNotesServices

struct NoteList: View {
    @Environment(NoteStore.self) private var store
    @Environment(\.undoManager) private var undoManager

    var body: some View {
        List {
            ForEach(store.notes) { note in
                NoteRow(note: note)
                    .swipeActions {
                        Button("Delete", role: .destructive) { delete(note) }
                    }
            }
        }
    }

    private func delete(_ note: Note) {
        store.delete(note)
        undoManager?.registerUndo(withTarget: store) { store in
            store.add(note)
        }
        undoManager?.setActionName("Delete Note")
    }
}

See Apple Developer Documentation — undoManager and Human Interface Guidelines — Undo and redo.

A related WWDC session walks through the principles with examples: WWDC26 — Principles of great design.

Key Foundations Applied to FieldNotes

Each subsection below names one HIG foundation, says in a sentence or two why it matters, records the FieldNotes decision, and shows the code. The links go to the HIG page for the guidance and to the API page for the code.

Layout

The layout foundation is about adaptability: an interface should respond to its available space through size classes, safe areas and layout margins instead of being designed for one screen size. With iPhone Duo, iPad windowing and resizable Mac windows, the same view routinely appears at a dozen sizes.

FieldNotes decision: the notebook overview uses a grid whose column count comes from the horizontal size class, always an even number of columns (2 or 4) so that content divides cleanly across the fold of iPhone Duo, and padding comes from the safe area rather than hard-coded insets.

import SwiftUI
import FieldNotesModel

struct NotebookGrid: View {
    @Environment(\.horizontalSizeClass) private var sizeClass
    let notebooks: [Notebook]

    private var columns: [GridItem] {
        let count = sizeClass == .regular ? 4 : 2
        return Array(repeating: GridItem(.flexible(), spacing: 12), count: count)
    }

    var body: some View {
        ScrollView {
            LazyVGrid(columns: columns, spacing: 12) {
                ForEach(notebooks) { notebook in
                    Label(notebook.name, systemImage: notebook.symbolName)
                        .frame(maxWidth: .infinity, minHeight: 88)
                        .background(.background.secondary, in: .rect(cornerRadius: 16))
                }
            }
            .safeAreaPadding(.horizontal)
        }
    }
}

See Apple Developer Documentation — horizontalSizeClass and Human Interface Guidelines — Layout.

The layout system itself (stacks, grids, ViewThatFits, custom Layout) is on SwiftUI Layout.

Color

The color foundation asks for color that is used purposefully and consistently, adapts to light and dark appearances and increased contrast, and is never the only carrier of meaning. System colors and semantic styles (.primary, .secondary, the accent color) adapt automatically; hard-coded RGB values do not.

FieldNotes decision: one accent color for interactive elements; a pinned note shows a symbol and a color, so the state is visible to people who cannot distinguish the hue; secondary text uses the .secondary style rather than a custom gray.

import SwiftUI
import FieldNotesModel

// NoteRowHeader and an excerpt of NoteRow, as declared on Views and Modifiers
struct NoteRowHeader: View {
    let title: String
    let isPinned: Bool

    var body: some View {
        HStack {
            Text(title).font(.headline)           // .primary by default
            if isPinned {
                Image(systemName: "pin.fill")     // the symbol carries the state...
                    .foregroundStyle(.orange)     // ...the color only reinforces it
                    .accessibilityLabel("Pinned")
            }
        }
    }
}

// In NoteRow's body: the body preview is secondary text
NoteRowHeader(title: note.title, isPinned: note.isPinned)
Text(note.body)
    .font(.subheadline)
    .foregroundStyle(.secondary)
    .lineLimit(2)

See Apple Developer Documentation -- foregroundStyle(_:) and Human Interface Guidelines — Color.

Typography

The typography foundation centers on legibility and Dynamic Type: use the system text styles so text scales with the user’s preferred size, keep a clear hierarchy with a small number of styles and weights, and let layouts grow with the text instead of truncating it.

FieldNotes decision: every text uses a text style (.headline, .body, .caption), never a fixed point size; the padding inside a TagChip (set by its TagChipStyle modifier) scales with the body text through @ScaledMetric, so chips stay proportionate at the largest accessibility sizes.

import SwiftUI

// The TagChipStyle modifier behind TagChip, with padding that follows Dynamic Type
struct TagChipStyle: ViewModifier {
    var isSelected = false
    @ScaledMetric(relativeTo: .caption) private var horizontalPadding = 8
    @ScaledMetric(relativeTo: .caption) private var verticalPadding = 4

    func body(content: Content) -> some View {
        content
            .font(.caption.weight(.medium))
            .padding(.horizontal, horizontalPadding)
            .padding(.vertical, verticalPadding)
            .foregroundStyle(isSelected ? Color.white : Color.primary)
            .background(isSelected ? AnyShapeStyle(Color.accentColor) : AnyShapeStyle(.tint.opacity(0.15)),
                        in: .capsule)
    }
}

See Apple Developer Documentation — ScaledMetric and Human Interface Guidelines — Typography.

TagChip and its TagChipStyle modifier are introduced on SwiftUI Views and Modifiers; the text APIs are on Controls, Forms, Text, Images and SF Symbols.

Dark Mode

The Dark Mode foundation asks apps to respect the system-wide appearance rather than offering a separate in-app theme, to use semantic colors and materials that adapt automatically, and to check contrast in both appearances, including with Increase Contrast turned on.

FieldNotes decision: the app has no appearance setting of its own. Its single custom color, the "paper" tone behind a note’s body, is an asset catalog color with light and dark variants, and every screen has a preview in both appearances.

{
  "colors" : [
    {
      "idiom" : "universal",
      "color" : { "color-space" : "display-p3",
                  "components" : { "red" : "0.980", "green" : "0.965", "blue" : "0.925", "alpha" : "1.000" } }
    },
    {
      "idiom" : "universal",
      "appearances" : [ { "appearance" : "luminosity", "value" : "dark" } ],
      "color" : { "color-space" : "display-p3",
                  "components" : { "red" : "0.145", "green" : "0.141", "blue" : "0.133", "alpha" : "1.000" } }
    }
  ],
  "info" : { "author" : "xcode", "version" : 1 }
}

See Apple Developer Documentation — Specifying your app’s color scheme and Apple Developer Documentation — Managing assets with asset catalogs.

That file is Assets.xcassets/NotePaper.colorset/Contents.json, which Xcode’s asset catalog editor writes; since Xcode 15 the build also generates a Color.notePaper symbol for it. The previews check both appearances:

import SwiftUI

#Preview("Editor, light") {
    NoteEditor(noteID: Note.samples[0].id)
        .background(Color.notePaper)
        .environment(NoteStore(notes: Note.samples))
}

#Preview("Editor, dark") {
    NoteEditor(noteID: Note.samples[0].id)
        .background(Color.notePaper)
        .preferredColorScheme(.dark)
        .environment(NoteStore(notes: Note.samples))
}

See Apple Developer Documentation -- preferredColorScheme(_:) and Human Interface Guidelines — Dark Mode.

Note.samples is the fixture array that FieldNotes's previews use (see Xcode Projects, Targets, Schemes and Previews).

Materials

The materials foundation describes two layers. Liquid Glass forms a functional layer for controls and navigation that floats above content, and the standard materials (ultra-thin to thick) separate content within that content layer. The key rule is not to mix them up: glass is for controls, not for content, and not glass on glass.

FieldNotes decision: the floating CaptureButton is the one custom glass element; everything else gets glass from the system toolbars and tab bars. A photo caption overlay inside a note uses a standard material, because it is content.

import SwiftUI

struct CaptureButton: View {
    var action: () -> Void

    var body: some View {
        let button = Button(action: action) {
            Label("Capture", systemImage: "plus")
                .labelStyle(.iconOnly)
                .font(.title2)
                .padding()
        }
        #if os(visionOS)
        button.buttonBorderShape(.circle)      // visionOS draws its own glass behind controls
        #else
        button.glassEffect(.regular.interactive(), in: .circle)
        #endif
    }
}

struct PhotoCaption: View {
    let text: String

    var body: some View {
        Text(text)
            .font(.footnote)
            .padding(8)
            .background(.regularMaterial, in: .rect(cornerRadius: 8))
    }
}

See Apple Developer Documentation -- glassEffect(_:in:) and Human Interface Guidelines — Materials.

Liquid Glass variants, glass effect containers, scroll edge effects and the accessibility settings that change glass rendering are the subject of Liquid Glass, Materials and Icons.

SF Symbols

SF Symbols is Apple’s library of several thousand symbols designed to align with the San Francisco font: they scale with Dynamic Type, match the adjacent text’s weight, support several rendering modes, and can animate. The foundation’s advice is to prefer a system symbol whose meaning people already know, and to keep a custom symbol visually consistent with the set.

FieldNotes decision: every notebook stores an SF Symbol name (Notebook.symbolName), shown with the hierarchical rendering mode; pinning plays a short bounce effect on the pin symbol.

import SwiftUI
import FieldNotesModel

struct NotebookLabel: View {
    let notebook: Notebook

    var body: some View {
        Label {
            Text(notebook.name)
        } icon: {
            Image(systemName: notebook.symbolName)
                .symbolRenderingMode(.hierarchical)
        }
    }
}

struct PinIndicator: View {
    let isPinned: Bool

    var body: some View {
        Image(systemName: isPinned ? "pin.fill" : "pin")
            .symbolEffect(.bounce, value: isPinned)
    }
}

See Apple Developer Documentation -- symbolEffect(_:options:value:) and Human Interface Guidelines — SF Symbols.

Motion

The motion foundation asks for animation that communicates (where something came from, what changed, what happened), stays brief, and respects the Reduce Motion setting by replacing large movements with fades or nothing at all. On visionOS, motion also affects physical comfort.

FieldNotes decision: the only non-system animations are the pin bounce and the reordering of the list when a note is pinned; with Reduce Motion on, the list changes without animation.

import SwiftUI
import FieldNotesModel
import FieldNotesServices

struct PinButton: View {
    @Environment(NoteStore.self) private var store
    @Environment(\.accessibilityReduceMotion) private var reduceMotion
    let note: Note

    var body: some View {
        Button(note.isPinned ? "Unpin" : "Pin", systemImage: "pin") {
            withAnimation(reduceMotion ? nil : .snappy) {
                store.togglePin(note)
            }
        }
    }
}

See Apple Developer Documentation — accessibilityReduceMotion and Human Interface Guidelines — Motion.

Writing

The writing foundation treats interface text as part of the design: decide on a voice and keep it consistent, be brief, use plain words, name buttons with the action they perform, and write empty states and errors that tell people what to do next.

FieldNotes decision: buttons are verbs ("Capture", "Pin", "Delete"), titles are nouns, and the empty note list explains how to start rather than just saying there is nothing there. Every string lives in a String Catalog for localization.

import SwiftUI

// Revision of EmptyNotebookView from Liquid Glass, Materials and Icons: same signature and
// glass button styles, plus a description and verb-first button titles.
struct EmptyNotebookView: View {
    var createNote: () -> Void
    var importNotes: () -> Void

    var body: some View {
        ContentUnavailableView {
            Label("No Notes Yet", systemImage: "note.text")
        } description: {
            Text("Create your first note, or import a notebook. Notes are saved on this device right away.")
        } actions: {
            Button("Create a Note", action: createNote)
                .buttonStyle(.glassProminent)
            Button("Import Notes…", action: importNotes)
                .buttonStyle(.glass)
        }
    }
}

See Apple Developer Documentation — ContentUnavailableView and Human Interface Guidelines — Writing.

Privacy

The privacy foundation asks apps to request access only when it is needed, at the moment the feature is used, with a purpose string that says exactly why, and to work gracefully when access is declined. It also covers the privacy information an app declares on the App Store.

FieldNotes decision: location is optional. The app asks for "when in use" access the first time the user taps "Add Location" on a note, never at launch, and notes work fully without it.

<!-- FieldNotes/Info.plist (excerpt) -->
<key>NSLocationWhenInUseUsageDescription</key>
<string>FieldNotes attaches your current location to a note only when you tap Add Location.</string>

See Apple Developer Documentation — NSLocationWhenInUseUsageDescription.

import CoreLocation
import SwiftUI

struct AddLocationButton: View {
    @State private var locationManager = CLLocationManager()

    var body: some View {
        Button("Add Location", systemImage: "location") {
            // Asked at the point of use, never at launch.
            if locationManager.authorizationStatus == .notDetermined {
                locationManager.requestWhenInUseAuthorization()
            }
        }
    }
}

See Apple Developer Documentation — requestWhenInUseAuthorization() and Human Interface Guidelines — Privacy.

The location flow itself, including live updates and service sessions, is on Location and Maps, and privacy manifests and App Store privacy details are on Security and Privacy.

Designing for Each Platform

Each "Designing for …​" page in the HIG’s Getting started section describes one device in the same terms: display, ergonomics, inputs, how long people typically use an app, and the system features an app should integrate with, followed by a short list of best practices. The subsections below condense each page into the design brief FieldNotes works from, show one platform-specific decision, and point to the platform page later in this section that covers the implementation in depth.

iOS

In short: a medium-size display held in one or both hands, used for anything from a ten-second glance to an hour of reading, controlled mostly by touch. The HIG’s emphasis is on keeping the primary task in focus with few visible controls, adapting to orientation, Dark Mode and Dynamic Type, placing frequent controls where thumbs reach them, and using device capabilities (with permission) instead of asking people to type.

FieldNotes decision: on iPhone the capture action lives in the bottom toolbar, within easy reach of the thumb, rather than in the top navigation bar.

#if os(iOS)
import SwiftUI

struct NoteListToolbar: ViewModifier {
    var capture: () -> Void

    func body(content: Content) -> some View {
        content.toolbar {
            ToolbarItem(placement: .bottomBar) {
                CaptureButton(action: capture)
            }
        }
    }
}
#endif

See Apple Developer Documentation — bottomBar and Human Interface Guidelines — Designing for iOS.

iOS is the baseline every other platform page builds on, so there is no separate part-3 page for it; the iOS app is the default target described in Getting Started with Apple Platforms and One Codebase for iOS, iPadOS, macOS, watchOS and visionOS.

iPadOS

In short: a large display used handheld, on a stand or with a keyboard and trackpad, often next to other apps. The HIG asks iPad apps to use the space to show more content with fewer modal screens, to size content for the viewing distance and input in use, to support touch, keyboard, pointer and Apple Pencil (and combinations of them), and to adapt to multitasking and resizable windows.

FieldNotes decision: the three-column NavigationSplitView shows notebooks, notes and the editor at once, and every frequent command has a keyboard shortcut that appears in the iPad menu bar and the shortcuts overlay.

import SwiftUI

struct NewNoteButton: View {
    var capture: () -> Void

    var body: some View {
        Button("New Note", systemImage: "square.and.pencil", action: capture)
            .keyboardShortcut("n", modifiers: .command)
    }
}

See Apple Developer Documentation -- keyboardShortcut(_:modifiers:) and Human Interface Guidelines — Designing for iPadOS.

Windowing, the iPad menu bar, pointer interactions and Apple Pencil are on iPadOS: Windows, Multitasking, Pointer and Apple Pencil.

macOS

In short: a large (often multiple) display at desk distance, used with keyboard and a precise pointer, for sessions that can last hours with many apps open. The HIG’s Mac best practices stress showing more content with less nesting and modality, freely resizable windows and full-screen support, a complete menu bar, keyboard shortcuts for everything frequent, precise selection and editing, and personalization such as customizable toolbars.

FieldNotes decision: every command is reachable from the menu bar (the Mac’s primary command surface): the standard sidebar commands are included, the Help menu opens the FieldNotes guide, and preferences live in a standard Settings window reached with Command-comma.

import SwiftUI

@main
struct FieldNotesApp: App {
    @State private var store = NoteStore()

    var body: some Scene {
        WindowGroup {
            ContentView()
                .environment(store)
        }
        .commands {
            SidebarCommands()
            CommandGroup(replacing: .help) {
                Link("FieldNotes Help", destination: URL(string: "https://example.com/fieldnotes/help")!)
            }
        }

        #if os(macOS)
        Settings {
            SettingsView()
                .environment(store)
        }
        #endif
    }
}

See Apple Developer Documentation — CommandGroup, Apple Developer Documentation — SidebarCommands and Human Interface Guidelines — Designing for macOS.

Windows, menus, MenuBarExtra and AppKit-specific behavior are on macOS: Windows, Menus, Commands, Settings and Menu Bar Extras; the AppKit menu model underneath .commands is on UIKit and AppKit Essentials, and Mixing Them with SwiftUI.

watchOS

In short: a small display on the wrist, raised for a few seconds at a time, operated with one hand, the Digital Crown and touch, often while moving. The HIG asks for glanceable, single-screen interactions, shallow navigation with the crown for vertical movement, proactive and relevant content, complications and notifications as primary surfaces, and an app that works on its own.

FieldNotes decision: FieldNotesWatch shows only the latest pinned notes as vertically paged cards (scrolled with the crown), each with a full-screen tinted background, plus a single dictation-based capture action.

import SwiftUI
import FieldNotesModel

// FieldNotesWatch target
struct PinnedNotesPager: View {
    let pinned: [Note]

    var body: some View {
        TabView {
            ForEach(pinned) { note in
                VStack(alignment: .leading) {
                    Text(note.title).font(.headline)
                    Text(note.body).font(.body).lineLimit(4)
                }
                .containerBackground(.orange.gradient, for: .tabView)
            }
        }
        .tabViewStyle(.verticalPage)
    }
}

See Apple Developer Documentation — verticalPage and Human Interface Guidelines — Designing for watchOS.

The watch app, complications and Smart Stack widgets are on watchOS: App Structure, Connectivity, Workouts and the Smart Stack.

visionOS

In short: an unbounded 3D canvas seen through passthrough, where apps live in windows, volumes or immersive spaces, controlled mostly by looking and pinching. The HIG’s emphasis is on familiar windows for UI-centric tasks, choosing the right level of immersion for each moment, and above all comfort: content within the field of view, gentle motion, gestures that work with hands at rest, and no pressure to move around.

FieldNotes decision: the main window stays a familiar window; its capture and filter controls sit in an ornament below the window instead of inside it, and the map of notes opens in the ImmersiveSpace(id: "map") only on request.

#if os(visionOS)
import SwiftUI

struct VisionContentView: View {
    @Environment(\.openImmersiveSpace) private var openImmersiveSpace

    var body: some View {
        ContentView()
            .ornament(attachmentAnchor: .scene(.bottom)) {
                HStack {
                    CaptureButton { /* start capture */ }
                    Button("Map", systemImage: "map") {
                        Task { await openImmersiveSpace(id: "map") }
                    }
                }
                .padding()
                .glassBackgroundEffect()
            }
    }
}
#endif

See Apple Developer Documentation — ornament(visibility:attachmentAnchor:contentAlignment:ornament:), Apple Developer Documentation — glassBackgroundEffect(displayMode:) and Human Interface Guidelines — Designing for visionOS.

Windows, volumes, immersive spaces and RealityKit content are on visionOS: Windows, Volumes, Immersive Spaces and RealityKit.

iPhone Duo

In short: new in 2026, iPhone Duo is a foldable iPhone (shipping with iOS 27.1) with a compact outer display, a large inner display, a camera on each, and a hinge that supports several poses: closed, open, folded like a book, or standing. The HIG page stresses that it is still an iPhone, so iOS guidance applies, and then adds four ideas:

  • Build for resizing, not for poses. Compact width on the outer display and regular width on the inner one, driven by size classes and safe areas, cover every pose; no pose-specific layouts.

  • Respect reserved regions. The outer camera, the inner camera when active, and the fold when partially open are regions content should avoid. System components adapt automatically; custom layouts query the regions.

  • Accept vertical controls. In most poses the system moves navigation bars, toolbars and tab bars to the side of the display. Apps keep the default placement and set priorities so the most frequent actions stay visible when items overflow.

  • Use arrangement views for two-pane content. A split or overlay arrangement adapts a primary and a secondary view to the fold; navigation stays outside of it.

FieldNotes decision: the capture button gets the highest toolbar visibility priority (new in iOS 27), the note detail uses an ArrangementView for editor and map (new in iOS 27.1), and the sketch canvas keeps its handles out of the fold by reading reserved regions (new in iOS 27.1).

import SwiftUI
import MapKit
import FieldNotesModel

// Shared by every platform: the priority matters wherever toolbars overflow.
struct CaptureToolbar: ViewModifier {
    var capture: () -> Void

    func body(content: Content) -> some View {
        if #available(iOS 27, macOS 27, watchOS 27, visionOS 27, *) {
            content.toolbar {
                ToolbarItem {
                    CaptureButton(action: capture)
                }
                .visibilityPriority(.high)   // new in 27: stays visible when vertical bars overflow
            }
        } else {
            content.toolbar {
                ToolbarItem {
                    CaptureButton(action: capture)
                }
            }
        }
    }
}

#if os(iOS)
// iPhone and iPad only: ArrangementView and reserved regions do not exist on the other platforms.
struct NoteDetailArrangement: View {
    let note: Note

    var body: some View {
        if #available(iOS 27.1, *) {
            ArrangementView {
                NoteEditor(noteID: note.id)
            } secondary: {
                Map()
            }
            .arrangementViewStyle(.split)
        } else {
            NoteEditor(noteID: note.id)
        }
    }
}
#endif

See Apple Developer Documentation — ToolbarItemVisibilityPriority and Apple Developer Documentation — ArrangementView.

Custom layouts read the reserved regions from a GeometryProxy. The .division kind is the fold; the returned frames are already mirrored for right-to-left layouts:

#if os(iOS)
import SwiftUI

struct SketchToolbarOverlay: View {
    var body: some View {
        GeometryReader { proxy in
            if #available(iOS 27.1, *) {
                let fold = proxy.reservedRegions(kind: .division).first(where: \.isActive)
                SketchTools()
                    .padding(.leading, fold.map { $0.frame.maxX + 8 } ?? 16)
            } else {
                SketchTools()
                    .padding(.leading, 16)
            }
        }
    }
}
#endif

See Apple Developer Documentation — ReservedRegion and Human Interface Guidelines — Designing for iPhone Duo.

(SketchTools is the tool palette of the note sketch canvas.) Apple’s developer checklist for the device is Preparing your app for iPhone Duo; the UIKit equivalent of ArrangementView is covered in UIKit and AppKit Essentials, and Mixing Them with SwiftUI, and adaptive layout in general on SwiftUI Layout. There is no separate part-3 page for iPhone Duo: it is an iOS device, and its layout work is the same resizable-layout work that iPadOS: Windows, Multitasking, Pointer and Apple Pencil covers for windows.

Using the HIG in a Design Review

The HIG is most useful as a checklist applied to a finished screen, not only as reading before starting. The table below is the review FieldNotes runs for every new screen; each question points at the HIG page that answers it.

Question Where the HIG answers it

Is the primary action obvious, and reachable one-handed on iPhone?

Designing for iOS, Layout

Does the screen work at every size, from the iPhone Duo outer display to a full-screen Mac window?

Layout, Designing for iPhone Duo

Does it read correctly at the largest Dynamic Type size and in Dark Mode with Increase Contrast?

Typography, Dark Mode

Is any state conveyed only by color?

Color

Are glass and materials used for the right layer?

Materials

Do animations still make sense, or disappear cleanly, with Reduce Motion on?

Motion

Are labels verbs, and does the empty state tell people what to do?

Writing

Is every permission requested at the point of use, with a specific purpose string?

Privacy

Accessibility review (VoiceOver labels, traits, focus order, Voice Control) is a separate pass described on Accessibility.

References