iOS design

1. Bound the review or design to the requested interaction and supported OS range. For code changes, inspect the framework, SDK, and deployment target; check API availability separately from visual guidance.
2. Load only the references triggered by that interaction:

• Layout, tabs, drill-down, or search: layout and navigation.
• Controls, gestures, presentations, or loading/error states: controls and feedback.
• Materials, colors, symbols, or animation: appearance.
• Text, controls, navigation, focus, or accessible media: accessibility.
• Protected resources, sign-in, or account creation: permissions and accounts.
• Onboarding, launch, widgets, notifications, sharing, or background transitions: entry points and lifecycle.

3. For behavior newer than the source refresh, or an implementation symbol not covered here, fetch its Apple page with sosumi fetch <Apple URL> and verify the supported OS and API availability.
4. Check the failure conditions for the affected interaction: small viewports for layout, enlarged text and focus for text/navigation, keyboard occlusion for editing, assistive activation for controls, appearance settings for custom rendering, and restored context for lifecycle changes. For an artifact review, cite the code or visible behavior supporting each finding; for a design, specify the expected outcome in each applicable condition. For a running implementation, exercise those conditions and record results; label unavailable runtime checks untested. Finish when every affected interaction has a supported decision or a finding with its trigger, user impact, and correction.