ios-native-review

iOS native review

Use this skill after a PRD, spec, or implementation plan that contains iOS-specific UI surfaces — before implementation begins. It is NOT a bug hunt, NOT a cross-platform polish review. It is a targeted check that the artifact, if shipped as written, will read as a native iOS app to an experienced iPhone/iPad user — on the level of Things, Bear, Overcast, Streaks, Carrot Weather, Lookup — and not as an Android-port or web-app wrapper.

Every finding cites a specific Apple Human Interface Guidelines page on developer.apple.com. The model fetches HIG pages during review rather than relying on training-data recall, so verdicts are grounded in the current published guidelines.

Invoke with: /superpowers-gstack:ios-native-review

When to invoke

Automatically after completing:

• A PRD, spec, or design document for an iOS or iPadOS app or feature
• An implementation plan that touches iOS UI surfaces
• Output from writing-specs, writing-plans, plan-design-review, plan-eng-review, or any planning skill — when iOS signals are present (see Phase 0)

Run once before implementation. Re-run after substantial spec/plan revisions affecting UI surfaces.

Relationship to pitfall-verification and quality-review

This skill is complementary, not overlapping, with the two existing review skills. Run all three sequentially on a fresh artifact for an iOS app:

| Skill | Lens | Question | |-------|------|----------| | pitfall-verification | Correctness | "Will this work?" (bugs, security, contracts, edge cases) | | quality-review | Perceived quality | "Will this feel good?" (silent failures, loading, empty/error states, polish — cross-platform) | | ios-native-review | Apple-native conformance | "Is this iOS-native?" (HIG-citation-grounded, iOS-specific) |

Recommended flow on a fresh artifact for an iOS app:

1. pitfall-verification → fix bugs
2. quality-review → fix feel
3. ios-native-review → fix native-conformance gaps
4. Hand off to writing-plans / implementation

ios-native-review does not replace quality-review. The latter has 13 platform-independent categories (silent failures, empty states, multi-tenancy, AI output, sort order, etc.) that are still worth running on iOS projects. Modest overlap on two categories (quality-review's keyboard / animations) is acceptable: that skill checks generic conventions, this skill checks Apple-iOS-specific values.

Relationship to macos-native-review and swiftui-design-consultation

For iOS + macOS multi-target projects: run ios-native-review AND macos-native-review both. They're complementary, not redundant — most HIG categories overlap in name but diverge in detail (sheets work differently, navigation is fundamentally different, modal presentation rules differ).

/superpowers-gstack:swiftui-design-consultation is the upstream design-system step for SwiftUI projects. It produces a DESIGN.md + Swift Package starter; for iOS projects it auto-chains into this skill on the DESIGN.md and mcp__swiftui-rag__review_macos_hig (which despite its name contains many platform-agnostic HIG rules) on each generated .swift file.

Sequence

1. Phase 0 — iOS signal detection (~30 seconds). Scan the artifact for iOS signals. If none found, return N/A and exit. If macOS-only, return N/A with sibling-skill note. Otherwise proceed.
2. Walk the 13 categories. For each: question → risk surface → verify against HIG page (WebFetch) → cite → report N/A | HANDLED | NOT HANDLED — proposed fix.
3. Produce the verdict in the output format below.

Phase 0 — iOS signal detection

Scan the artifact for any of these signals:

• .swift files referenced in scope with iOS-flavored types
• Imports: SwiftUI, UIKit, Combine (in Apple context)
• Type references: UIViewController, UINavigationController, UITabBarController, UIView, UIApplication, UIScene, WindowGroup (in iOS App context), TabView, NavigationStack, NavigationSplitView
• Explicit text: "iOS app", "iPhone app", "iPad app", "iPadOS", "iOS-native", "UIKit", "SwiftUI for iOS"
• Build target: .xcodeproj with iOS deployment target, Package.swift with .iOS(.v…) platform, Info.plist with UIApplicationSceneManifest

Decision:

• No signals found: return N/A — no iOS surfaces detected, skill not applicable and exit. Do not proceed.
• Multi-target (iOS + macOS): proceed. iOS surfaces are relevant. Run macos-native-review in parallel.
• macOS-only signals: return N/A — macOS-only project. Use /superpowers-gstack:macos-native-review instead.
• iOS signals present: proceed.

Phase 0 is the safety net for false positives. Without it, the skill would flag "missing tab bar" for a watchOS app or a Linux CLI tool.

Category-default HIG URL table

Output this table at the top of every review. Each finding cites either the default URL or a more specific sub-page.

| # | Category | Default HIG URL | |---|----------|------------------| | 1 | Vocabulary | (cross-referenced per-component — cites the HIG page of the component containing the offending text) | | 2 | Controls & touch targets | https://developer.apple.com/design/human-interface-guidelines/buttons | | 3 | Navigation paradigm (tab bar, navigation stack, split view) | https://developer.apple.com/design/human-interface-guidelines/tab-bars, https://developer.apple.com/design/human-interface-guidelines/navigation-bars | | 4 | Modal presentation (sheets, full-screen, popovers) | https://developer.apple.com/design/human-interface-guidelines/sheets, https://developer.apple.com/design/human-interface-guidelines/popovers, https://developer.apple.com/design/human-interface-guidelines/alerts | | 5 | Gestures | https://developer.apple.com/design/human-interface-guidelines/gestures | | 6 | System surfaces (safe area, Dynamic Island, status bar) | https://developer.apple.com/design/human-interface-guidelines/layout, https://developer.apple.com/design/human-interface-guidelines/live-activities | | 7 | Keyboard handling | https://developer.apple.com/design/human-interface-guidelines/onscreen-keyboards | | 8 | Haptics | https://developer.apple.com/design/human-interface-guidelines/playing-haptics | | 9 | Semantic colors & dark mode | https://developer.apple.com/design/human-interface-guidelines/color, https://developer.apple.com/design/human-interface-guidelines/dark-mode | | 10 | Animation timing | https://developer.apple.com/design/human-interface-guidelines/motion | | 11 | Privileged operations & permission prompts | https://developer.apple.com/design/human-interface-guidelines/privacy, https://developer.apple.com/design/human-interface-guidelines/onboarding | | 12 | Accessibility | https://developer.apple.com/design/human-interface-guidelines/accessibility | | 13 | App lifecycle & state restoration | https://developer.apple.com/design/human-interface-guidelines/launching, https://developer.apple.com/design/human-interface-guidelines/multitasking |

URLs verified at skill creation (spot-checked /buttons for touch-target guidance — JSON endpoint returned canonical 44×44 pt quote). If a URL 404s during review, see "Fallback when developer.apple.com unreachable" below.

The 13 categories

For each category: state the question, locate the risk surface in the artifact, verify by WebFetching the HIG page, and report N/A | HANDLED | NOT HANDLED — proposed fix with citation.

1. Vocabulary

Does copy use Apple-canonical verbs and noun choices for iOS? Apple uses Done / Cancel / Save / Delete / Add, not custom verbs. iOS says "Tab bar", not "Bottom Navigation"; "Sheet", not "Bottom Sheet" (Material term); "Navigation bar", not "App bar". Toolbar items are placed in the Toolbar modifier, not in custom-built bottom bars. Vocabulary mismatches signal "this app is an Android port".

Risk surfaces: every user-facing string in the spec (button labels, tab titles, navigation titles, sheet titles, alert copy, empt