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:
pitfall-verification→ fix bugsquality-review→ fix feelios-native-review→ fix native-conformance gaps- 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
- Phase 0 — iOS signal detection (~30 seconds). Scan the artifact for iOS signals. If none found, return
N/Aand exit. If macOS-only, returnN/Awith sibling-skill note. Otherwise proceed. - Walk the 13 categories. For each: question → risk surface → verify against HIG page (WebFetch) → cite → report
N/A | HANDLED | NOT HANDLED — proposed fix. - Produce the verdict in the output format below.
Phase 0 — iOS signal detection
Scan the artifact for any of these signals:
.swiftfiles 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:
.xcodeprojwith iOS deployment target,Package.swiftwith.iOS(.v…)platform, Info.plist withUIApplicationSceneManifest
Decision:
- No signals found: return
N/A — no iOS surfaces detected, skill not applicableand 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.
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