Native

Platform routing

Shared product identity does not mean a shared AppShell. Shared business logic does not require identical platform chrome. Keep Field Management and Network identities and release evidence separate.

HIG-001, Scope and source receipts

Every mobile specification, component change, implementation PR, and release review MUST name the app, platform, supported OS range, affected surfaces, applicable rule IDs, Apple topic URLs, and date consulted. This includes Field Management and Network, onboarding, authentication, customer-facing flows, billing surfaces, and shared native adapters. Native is mandatory context even when another skill owns the feature. Read relevant topics, not the entire HIG for every button. A source receipt is evidence of consultation, not proof of conformance.

Source: Human Interface Guidelines (opens in a new tab). Lifecycle scope and receipts are Thorbis policy.

HIG-002, Platform authority before desktop resemblance

For iOS and iPadOS, implementation MUST follow applicable Apple HIG behavior over conflicting Linear-derived shell, density, icon-only, typography, motion, or surface rules. Preserve Thorbis terminology, identity, semantic tokens, permissions, and durable work state. Do not force Apple-specific chrome on Android. A visual preference cannot override accessibility, safety, privacy, or recovery. Report unresolved architecture conflicts under D-012 rather than silently violating the platform contract.

Source: Layout (opens in a new tab). Conflict resolution is delegated by D-025.

HIG-003, Native components and system materials

Use platform-native controls and approved native-backed adapters where available. Custom alternatives MUST demonstrate equivalent semantics, accessibility, interaction, and supported-version behavior before adoption. Do not reproduce system pickers, sharing, authentication prompts, or navigation using web-styled imitations. OS-provided materials, including Liquid Glass where supported, belong in their system-defined navigation/control roles; they are not a decorative effect for every content card. D-018 and D-021 do not prohibit native system materials. Never emulate a newer OS by painting fake chrome over an older one.

Source: Materials (opens in a new tab).

HIG-004, Touch geometry without density loopholes

Thorbis policy: every app-owned iOS/iPadOS interactive target MUST provide at least 44 × 44 points of usable hit area, including icon buttons, text actions, chips, dismiss controls, and list accessories. Targets must not overlap or be occluded. Native system-owned controls retain system metrics; do not distort their geometry. Apple's accessibility guidance distinguishes a 44 × 44-point default from a smaller minimum; Thorbis deliberately adopts the stricter floor for its own controls. This is not a claim that Apple universally mandates 44 points. Points are logical native units, not physical pixels or CSS pixels. Android app-owned targets use at least 48 × 48dp. Measure effective hit areas, not only glyph bounds.

Source: Accessibility (opens in a new tab).

HIG-005, Navigation is destinations, not actions

Navigation MUST use an approved native stack and preserve expected visible Back and interactive back behavior, including cancellation and restored state. Tabs represent stable top-level destinations, not commands such as Arrive, Pay, or Create. Choose the destination set from the app and role; there is no universal three-tab requirement. Keep labels and selection understandable, preserve state when switching destinations, and use native adaptive navigation on iPad. Do not manufacture edge gestures or make a swipe the only way to go back. Record identity, deep links, and authorization must survive navigation.

Source: Tab bars (opens in a new tab), Layout (opens in a new tab).

HIG-006, Sheets, dismissal, and task continuity

Transient tasks MUST use appropriate native presentations with clear dismissal, correct focus restoration, keyboard accommodation, and protection against unintended loss of meaningful input. Choose presentation and detents for the content and available space; not every task is a bottom sheet. Preserve expected dismissal gestures unless preventing actual data loss requires an explicit confirmation. Jobs, invoices, profiles, and other durable records remain navigable destinations, not sheet-only dead ends. Do not stack custom overlays to avoid designing navigation.

Source: Sheets (opens in a new tab).

HIG-007, Safe areas and keyboards are live geometry

Layouts MUST respond to safe-area insets, system bars, device orientation, the available window, and keyboard changes. Primary actions and focused fields remain reachable above the home indicator and keyboard. Do not hard-code notch, tab-bar, or keyboard heights. Test keyboard presentation, dismissal, floating/split keyboard where supported, long forms, and transient presentations. Scroll the correct content region without losing field focus or drafts.

Source: Layout (opens in a new tab).

HIG-008, System text styles and Dynamic Type

iOS/iPadOS typography MUST use semantic text styles and support Dynamic Type, including accessibility sizes, without clipping essential information or hiding actions. Prefer the platform system font through system APIs. Custom fonts require equivalent scaling, weights, line metrics, and fallback proof; Inter is not mandatory on native job content. The system body style's default size is not a universal minimum for every label. Do not apply desktop 13/14px density, globally disable font scaling, cap accessibility sizes to preserve a screenshot, or use fixed-height text containers that truncate the task. Use tabular numerals where amounts require comparison. Do not bundle system font files to simulate native type.

Source: Typography (opens in a new tab), Accessibility (opens in a new tab).

HIG-009, Assistive interaction is part of the component

Each interactive component MUST expose an accurate accessible name, role, value, state, and logical focus order. Verify VoiceOver, Voice Control, Switch Control, and hardware-keyboard access as applicable to the flow. Announce meaningful asynchronous changes without flooding speech. Modal focus must not escape into obscured content. A gesture, hover, color, sound, or haptic cannot be the only path to critical work. Provide accessible alternatives for custom canvases, charts, signatures, and drag interactions. A visible label and accessible name must describe the same action.

Source: Accessibility (opens in a new tab).

HIG-010, Appearance, contrast, and noncolor meaning

Appearance MUST support System, Light, and Dark and honor applicable Increase Contrast and Reduce Transparency preferences. Use semantic native color roles/adapters rather than forcing web swatches onto system surfaces. Thorbis policy: ordinary app-owned informational text requires at least 4.5:1 contrast; meaningful custom nontext controls and indicators require at least 3:1 against adjacent colors. Record measured pairs and any legitimate not-applicable case. APCA may supplement, not replace, these mobile checks. Status, validation, and selection cannot rely on color alone. Preserve Thorbis identity without compromising legibility or system-owned accessibility behavior.

Source: Accessibility (opens in a new tab), Materials (opens in a new tab).

HIG-011, Respect system motion and Reduce Motion

Native navigation, gestures, sheets, and system controls MUST retain their platform transitions instead of being forced into Thorbis's web 120ms curve. Custom motion must explain state or continuity, be interruptible, and respect Reduce Motion. Provide a usable reduced-motion alternative; do not use movement as the sole explanation. Avoid decorative parallax, forced onboarding animation, or delayed interaction for visual theater. Record custom animation performance under HIG-018.

Source: Motion (opens in a new tab).

HIG-012, Haptics complement visible feedback

Haptics MUST be purposeful, brief, appropriate to the outcome, and paired with another understandable signal. Use supported system feedback rather than arbitrary vibration patterns. The app remains usable when haptics or sound are unavailable or disabled. Do not buzz on every row, use success feedback before confirmation, or make a haptic the only warning of a failed payment or upload.

Source: Playing haptics (opens in a new tab).

HIG-013, Native input, editing, and recovery

Inputs MUST preserve native editing, selection, paste, autofill, appropriate keyboard types, and accessible labels. Keep entered data after recoverable validation or network errors. Errors explain the problem and next step near the relevant input; a transient toast alone is insufficient. Money, phone numbers, dates, and addresses must respect locale and task semantics. Do not globally disable text selection or clipboard actions in pursuit of an app-like appearance. Form submission must not unexpectedly discard the current work.

Source: Accessibility (opens in a new tab), Layout (opens in a new tab). Draft and error-recovery requirements are Thorbis policy.

HIG-014, Permissions and private information

Permission-dependent flows MUST explain the task-specific need, use system authorization UI at the point of need, and handle denied, restricted, revoked, and unavailable states. Provide a safe alternative when possible. Do not simulate Face ID or system permission prompts, coerce consent, expose sensitive job/customer/payment information in notifications by default, or treat a permission request as authorization to perform an unrelated action. Use the separate security/privacy contract for data handling and OS APIs.

Source: Human Interface Guidelines (opens in a new tab). Permission timing and data boundaries are Thorbis policy; consult the applicable live privacy topic and platform API documentation for the actual feature.

HIG-015, Honest states and offline work

Every consequential flow MUST distinguish loading, empty, denied, disabled, error, offline, queued, syncing, and confirmed states as applicable. Thorbis policy: preserve drafts and work state across interruptions, avoid duplicate money/dispatch/message operations, and provide explicit retry or recovery. A queued action is not a confirmed success. Do not block all navigation behind a spinner or silently discard an upload when switching tabs. Reconcile local and server state before claiming completion.

Source: Accessibility (opens in a new tab). Offline durability and transaction semantics are Thorbis product requirements, not claims about HIG-specific implementation mandates.

HIG-016, iPad is adaptive, not a stretched phone

iPad layouts MUST respond to the available app window rather than device-model assumptions. Use appropriate native tabs, sidebars, split content, and presentations; a rail is not universally required. Preserve selection and drafts when columns appear or collapse. Test supported resizable/multitasking configurations, portrait/landscape, pointer, hardware keyboard, and accessibility text sizes. Do not certify iPad behavior with only a 390px browser screenshot or full-screen tablet mockup.

Source: Layout (opens in a new tab), Tab bars (opens in a new tab).

HIG-017, Symbols, language, and direction

Symbols MUST communicate the action and match supported platform capabilities. Prefer suitable system symbols for native controls, with fallbacks for the supported OS range; custom brand symbols still need semantic and accessibility proof. Preserve system labels where expected. Do not force every native control into web icon-only chrome or one outline/fill formula. Use meaningful accessible names, localized dates/numbers/plurals, long-string tests, and right-to-left layout. Mirror directional controls only when their meaning requires it, not logos or physical objects indiscriminately.

Source: SF Symbols (opens in a new tab), Typography (opens in a new tab).

HIG-018, Measured device performance

Thorbis policy: mobile releases MUST record measured launch, interaction, scrolling, transition, and memory behavior for the affected flows on representative supported physical devices, including a lower-performance supported device. Set budgets in the owning app before implementation and report actual results; do not invent a universal Apple frame-rate or launch-time mandate. Avoid main-thread work, unbounded media, unnecessary rerenders, and decorative effects that block input. Test realistic job lists, weak connections, and background/foreground transitions. Distinguish simulator observations from physical-device measurements.

Source: Motion (opens in a new tab), Layout (opens in a new tab).

HIG-019, Media and capture fit the task

Media and capture MUST use approved system integrations, bounded decoding/rendering, stable geometry, and accessible alternatives. Preserve upload progress and retry state when navigating or interrupted. Do not eagerly load full-resolution galleries into scrolling lists, autoplay disruptive audio, or make a photo the only carrier of essential text. Camera, photo-library, sharing, and denied-permission states must remain understandable. Use representative real-world media sizes in performance evidence.

Source: Accessibility (opens in a new tab), Layout (opens in a new tab). Resource and upload requirements are Thorbis policy.

HIG-020, Shared contracts, platform adapters

Implementations MUST reuse registered semantic tokens, domain contracts, permissions, identifiers, and business logic while allowing native platform adapters to own controls and presentation. Do not introduce another token namespace, an unregistered component kit, a WebView shell, or an architecture migration to satisfy a visual rule. Preserve the actual repository stack; React Native/Expo is not permission to draw identical chrome everywhere. A missing native adapter is a D-012 gap requiring an owner and tests, not a feature-local imitation. A specified component is not an adopted or tested component.

Source: Human Interface Guidelines (opens in a new tab). Architecture and adoption gates are Thorbis policy.

HIG-021, Evidence before completion

Every affected mobile change MUST include a rule-by-rule applicability matrix covering HIG-001 through HIG-022. Use pass, fail, not tested, or not applicable with reason. Each applicable pass identifies the component/screen, app build, OS/device or simulator, test method, date, and artifact. Record native manual checks separately from automated checks. Screenshots alone do not prove gestures, focus, hit areas, state recovery, or performance. A website build, linter, or this repository's contract tests cannot certify an app's native behavior. One unresolved applicable MUST failure or required untested behavior blocks mobile completion.

Source: Accessibility (opens in a new tab). Evidence format and release blocking are Thorbis policy.

HIG-022, Review, maintenance, and exceptions

A deviation MUST have a named human owner, exact rule and Apple topic, user problem, rejected alternatives, scoped implementation, compensating protections, tracking issue, expiry, and retest plan before acceptance. Agents cannot approve their own exceptions. Safety, accessibility, privacy, and recovery requirements are not waived for visual preference or speed. Reconsult applicable live guidance when behavior, supported OS versions, SDKs, or platform components change and before release. An approved scoped deviation is not blanket HIG compliance. Do not represent an advisory check as a protected-branch requirement unless repository settings actually enforce it.

Source: Human Interface Guidelines (opens in a new tab). Governance and exception handling are Thorbis policy.

Required review record

Keep the full rule wording here. Link rule IDs from specs, component contracts, implementation PRs, and release records.

App / platform / supported OS range:
Build / commit / affected screens and components:
Apple topics consulted / date:
Rule ID | applicability | result | evidence / reason
HIG-001 through HIG-022 (one row per rule)
Physical devices and simulator configurations:
Dynamic Type / VoiceOver / other applicable assistive input:
Appearance / contrast / reduced motion / reduced transparency:
Navigation / keyboard / safe areas / iPad window changes:
Offline / retries / interruptions / performance budgets and results:
Human-approved scoped deviations / tracking issue / expiry:
Unresolved failures and untested behavior:
Reviewer and release decision:

A documentation-only change can mark native runtime verification not applicable with an explicit scope statement. It cannot mark untested app behavior as passed. Redact customer data, credentials, and private documents from evidence.

Other hosts

Android retains native navigation and predictive Back where supported, device typography, native pickers, accessibility, and at least 48dp app-owned targets. Reuse the evidence discipline above with the applicable host references; do not claim Android follows Apple-specific component geometry.

Desktop retains native window controls and menus, drag regions, keyboard paths, and host accessibility. Use Command on macOS and Control on Windows where appropriate. Do not paint one operating system's chrome onto another.

Mobile web remains a browser: preserve links, history, zoom, text selection, accessible touch targets, logical layout, and scroll. Use dynamic viewport and safe-area support as appropriate. Do not disable zoom or pinch gestures, replace browser navigation with fake native chrome, or apply tiny desktop text-action targets to touch workflows.

Done

Name the app, platform, profile, pattern, native adapters, applicable HIG rules, source receipts, evidence, and unresolved gaps. One unresolved applicable MUST failure blocks completion. This contract is not evidence that an existing app has already passed it.

Applied bookmark research

Reviewed 2026-09-06. These are Thorbis applications and review exercises, not replacements for DESIGN.md, COMPONENTS.md, or the owning skill. Linear remains the operational baseline. External advice that conflicts with the constitution stays out.

These worked examples are not a claim that the product behaviors have been implemented or verified.

Transfer the intent, not the desktop gesture

Owning skill: native.

An interaction that works with a precise pointer or modifier key may be unusable for a tech holding a phone.

Preserve the record and task while adapting the visible action path to the device. Use the existing native owner for target sizing, safe areas, focus, and host behavior; no critical action relies only on hover or a hidden gesture.

Thorbis example: A field photo remains attached to the same job when the tech changes orientation or returns from another app. The visible capture action and retry path remain available without discovering a desktop shortcut.

Verify: Check one-handed use, software keyboard opening, text enlargement, orientation, focus visibility, and reduced motion on the relevant device. Keep permission refusal and return-from-interruption states in the review.

Do not import: No desktop hover contract on a phone, blocked zoom, silent clipboard access, or unverified claim that a web imitation is native behavior.

Evidence: Web Interface Guidelines (opens in a new tab); Design Engineer Principles (opens in a new tab); Devouring Details (opens in a new tab). Source access limits.

All 26 sources and review limits.