# Apple HIG contract for the LAYR redesign 5 September 2026 · Planning and implementation checklist Direction: refined fashion editorial, using **Cloud Dancer, Quiet Violet, and Obsidian** as the three brand pigments. Apple’s Human Interface Guidelines govern platform behavior, accessibility, and native controls; LAYR supplies the identity and content composition. Color values and digital approximations are defined in the companion proposal, not by Apple. This is a design contract for the proposed redesign. It does not certify the current app or visual board as HIG-compliant. No native build or full accessibility verification was performed for this document. Existing canonical project rules remain in effect until deliberately updated during implementation. ## 1. Navigation and platform controls - [ ] Use a native three-destination tab bar: **Home / Closet / You**. Retain labels, predictable availability, and each destination’s navigation state. **Create is a toolbar button that opens its menu or flow**, not a fourth tab that performs an action. [Apple: Tab bars](https://developer.apple.com/design/human-interface-guidelines/tab-bars) - [ ] Use standard Back and Close controls, search, menus, sheets, pickers, and switches wherever they fit the task. Keep native placement, interaction, and accessibility behavior. Give a toolbar one clearly prominent primary action on its trailing side. [Apple: Toolbars](https://developer.apple.com/design/human-interface-guidelines/toolbars) - [ ] Let native controls own their platform geometry and adapt across OS versions. Do not apply the same 14pt radius or pill shape to every toolbar, sheet, input, and content tile. Standard toolbar components use shapes that relate to the surrounding bar. [Apple: Toolbars](https://developer.apple.com/design/human-interface-guidelines/toolbars) - [ ] Keep `LAYRComponentsKit` as the shared component facade. Prefer compatible native controls behind the facade where appropriate; extend the customized component path when a branded component is justified. A facade should preserve system behavior rather than force every control into a custom visual implementation. This is LAYR’s architectural application of the guidance, not an Apple requirement to use ComponentsKit. ## 2. Color, appearance, and materials - [ ] Treat Cloud Dancer as a quiet content canvas, Quiet Violet as a restrained brand accent, and Obsidian as structural contrast. This allocation is a **LAYR design decision**. Define semantic roles for foregrounds, surfaces, selection, actions, and feedback; verify every actual pairing. Pale colors must not be used for small text or essential boundaries without sufficient contrast. - [ ] Provide custom-color variants for **light, dark, and increased contrast**. Apple requests light and dark colors even when an app ships in one appearance, because Liquid Glass can adapt locally to underlying content. Recommend following system Light/Dark appearance as part of this redesign; do not describe a complete dark theme as an unconditional HIG mandate. [Apple: Color](https://developer.apple.com/design/human-interface-guidelines/color) - [ ] Keep the three-pigment rule for **brand styling**, with explicit exceptions for native semantic behavior, real garment/photo colors, analysis data, and official marks. Preserve the native destructive role and its system-red treatment. Do not recolor Delete to Quiet Violet merely to enforce the brand palette. Add explicit labels and recovery behavior. [Apple: Buttons](https://developer.apple.com/design/human-interface-guidelines/buttons) - [ ] Use color consistently and never as the only carrier of state or meaning. Pair selection with a check or other indicator, and errors with readable explanations. Prefer monochromatic toolbar labels where colorful garments may pass beneath them. [Apple: Color](https://developer.apple.com/design/human-interface-guidelines/color) - [ ] Allow system Liquid Glass for supported navigation and controls. Keep clothing cards, recommendation content, and ordinary page surfaces outside the Liquid Glass layer. Do not build a decorative glass imitation into every card. Let system components adapt to accessibility settings and use the native appearance available on earlier supported OS versions. [Apple: Materials](https://developer.apple.com/design/human-interface-guidelines/materials) ## 3. Typography, layout, and actions - [ ] Use semantic San Francisco text styles for reading and controls. Keep Bricolage for selected editorial headings and brand moments, with equivalent Dynamic Type and Bold Text support. Layouts and meaningful icons grow with text. Avoid fixed text boxes, shrinking essential copy to fit, and excessive truncation. [Apple: Typography](https://developer.apple.com/design/human-interface-guidelines/typography) - [ ] Prefer SF Symbols for common platform actions. Custom fashion icons remain valid if recognizable, consistent, scalable, and accessibly labeled; Apple does not prohibit custom icon families. [Apple: Icons](https://developer.apple.com/design/human-interface-guidelines/icons), [Apple: SF Symbols](https://developer.apple.com/design/human-interface-guidelines/sf-symbols) - [ ] Respect system safe areas, margins, bars, keyboard space, and layout direction. Adapt to available size, supported orientations, localization, and Dynamic Type. Keep page buttons inset from physical screen edges. Reserve real space for persistent actions rather than adding guessed bottom padding. [Apple: Layout](https://developer.apple.com/design/human-interface-guidelines/layout) - [ ] Give custom buttons at least **44 × 44pt hit regions**, with separated targets and visible press feedback. Distinguish same-group alternatives through style, keeping their dimensions consistent. Present activity clearly during delayed actions and prevent duplicate submission. [Apple: Buttons](https://developer.apple.com/design/human-interface-guidelines/buttons) - [ ] Treat proposed 4pt spacing increments, 20pt content gutters, 14pt card corners, title sizes, and 56pt custom CTAs as **LAYR starting values, not Apple standards**. Native control dimensions can differ. A rendered 52pt button is not inherently an HIG violation; a mismatch between its token, frame, and hit area is a component consistency issue. Validate custom values with content and accessibility settings before locking them. ## 4. Review and verification The project currently declares an iOS 17.0 deployment target. Validate the oldest supported version and the current target OS; feature-gate newer material behavior instead of assuming it exists everywhere. - [ ] Build and capture each migrated screen family at supported compact and large iPhone sizes; include short-height layouts where supported, keyboard presentation, long content, and relevant orientations. - [ ] Test normal text through the largest accessibility sizes, Bold Text, VoiceOver reading/focus order, clear control labels, and announced loading/error changes. Use **4.5:1 for ordinary text** and **3:1 for meaningful non-text indicators** as LAYR’s conservative review targets; assess rendered states, not isolated swatches. [Apple: Accessibility](https://developer.apple.com/design/human-interface-guidelines/accessibility) - [ ] Verify light/dark and increased-contrast variants, Reduce Transparency, Reduce Motion, grayscale differentiation, and external keyboard interaction. Ensure adapting materials do not erase state or make controls unreadable. [Apple: Testing system accessibility features](https://developer.apple.com/documentation/accessibility/testing-system-accessibility-features-in-your-app) - [ ] Exercise empty, populated, loading, failed/retry, offline, permission-denied, selected, disabled, purchase-recovery, and destructive-action paths where relevant. - [ ] Confirm that tab navigation preserves context, Create remains an action, sheets dismiss predictably, and no bar or persistent action hides meaningful content. - [ ] Record screenshots, tested OS/device/text configurations, remaining limitations, and resolved defects. The HTML board demonstrates design intent; only the implemented app can establish native behavior and accessibility evidence.