What this prompt does
This prompt generates a modern SwiftUI app template for [app_purpose] targeting iOS [ios_version]+. It uses MVVM with the @Observable macro, SwiftData models for [data_models], a typed NavigationStack, an async/await networking layer with [api_client], an authentication flow ([auth_type]), custom UI components ([components]), accessibility with Dynamic Type and VoiceOver, a widget extension for [widget_purpose], App Store screenshot automation via snapshot tests, and [monetization] setup. It also asks for the Xcode project structure, SwiftLint configuration, and a TestFlight CI/CD pipeline.
The structure works because it starts from current SwiftUI idioms instead of legacy patterns. The @Observable macro paired with SwiftData and typed navigation keeps the view layer thin and testable, while async/await makes the networking readable. Baking accessibility and [monetization] in from the start matters because Dynamic Type, VoiceOver, and StoreKit are all painful to retrofit late in an App Store push.
When to use it
- You're starting a native iOS app and want a clean, modern SwiftUI foundation.
- You want SwiftData and the @Observable macro instead of older Core Data and ObservableObject patterns.
- You need typed navigation rather than string-based or stringly-typed routing.
- You're shipping to the App Store and want accessibility and monetization in place early.
- You want a widget and automated screenshot tests from the first build.
- You're setting a team standard for how new iOS projects are structured.
Example output
Expect an Xcode project skeleton: SwiftData model definitions for your [data_models], view-models using @Observable, a NavigationStack with typed destinations, an async/await networking layer over [api_client], an auth flow for [auth_type], the custom [components] stubbed out, a widget extension, SwiftLint config, and a TestFlight CI/CD pipeline. Accessibility support and [monetization] scaffolding are wired into the relevant views rather than bolted on.
Pro tips
- Set
[ios_version]honestly — SwiftData and @Observable need iOS 17+, so don't target older versions and expect these APIs to work. - Define
[data_models]up front; SwiftData schema choices ripple through the view-models, so naming the real entities saves rework. - Match
[auth_type]to your audience — Sign in with Apple is often required if you offer any third-party login on iOS. - Keep accessibility in scope even on a tight timeline; Dynamic Type and VoiceOver are far cheaper to build in than to retrofit before review.
- Specify
[monetization]early (StoreKit 2 subscriptions, for instance) so paywall and entitlement logic shapes the architecture instead of being grafted on. - Use the snapshot-based screenshot automation to keep App Store assets current as the UI changes, rather than recapturing by hand each release.
