The Best .cursorrules File for Pure Swift Mobile Apps

Cursor writes good Swift when it knows your stack and sloppy Swift when it has to guess. A rules file is how you tell it, once, to always use pure SwiftUI, modern Swift concurrency, and Apple conventions, so every generation follows them. Cursor reads these from a rules file in your project, documented under Cursor rules. Below is a complete, opinionated rules file for a pure Swift mobile app, then the reasoning behind each section.

A copy-ready rules file

Put this in your project’s rules (a .cursorrules file at the root, or a file under .cursor/rules):

You are building a pure native iOS app in Swift. Follow these rules.

Stack:
- Use SwiftUI for all UI. Do not use UIKit unless a feature has no SwiftUI equivalent, and explain why if you do.
- Target the latest stable iOS and Swift. Use Swift concurrency (async/await, actors), not completion handlers.
- Use the Observation framework (@Observable) for view models. Avoid legacy ObservableObject unless required.
- No third-party UI libraries. Build with native SwiftUI components only.

Architecture:
- One view per file. Keep views small and composable.
- Put view models and data types in separate files from views.
- Use async/await for networking and a single typed model layer.

Quality:
- No force unwraps. Handle optionals with if let, guard, or default values.
- Add a SwiftUI preview for every view.
- Use accessibility labels and Dynamic Type. Follow the Apple Human Interface Guidelines.
- Name types in UpperCamelCase and properties in lowerCamelCase.

Process:
- Before writing a screen, restate the layout you are about to build.
- Make small, reviewable changes. Do not refactor unrelated files.

Keep it short and specific; a rules file that tries to cover everything gets ignored in practice.

What each rule prevents

Rule	What it prevents
Pure SwiftUI, not UIKit	Hard-to-maintain UIKit-to-SwiftUI bridging code
async/await and @Observable	Old completion-handler and ObservableObject patterns
No third-party UI libraries	Dependency bloat and avoidable lock-in
No force unwraps	A whole class of runtime crashes
Preview, accessibility, HIG	Apps that fail review or exclude users

Why pin SwiftUI over UIKit

The single most useful rule is forcing pure SwiftUI. Without it, Cursor mixes UIKit and SwiftUI, which produces bridging code a beginner cannot maintain. Pinning SwiftUI keeps the codebase modern and consistent, and the small escape hatch (explain why if you must use UIKit) prevents it from getting stuck on the rare feature SwiftUI lacks.

Why concurrency and Observation rules matter

Left alone, Cursor often writes older patterns: completion handlers and ObservableObject. Pinning async/await and the @Observable macro keeps the app on current Swift, which is less code and fewer threading bugs. This is exactly the kind of drift a rules file prevents, the same idea as the React Native version in cursorrules file for React Native UI.

Why the quality and process rules pay off

The no-force-unwrap rule alone removes a whole class of crashes. Requiring a SwiftUI preview per view makes the app inspectable as you build. Following the Human Interface Guidelines and accessibility keeps it App Store ready. And the process rules, restate the layout, make small changes, are what keep Cursor accurate, building on the workflow in can Cursor build a full React Native app from scratch. Cursor itself is free on Hobby or $20 a month for Pro, so the rules file is the cheapest quality upgrade you can make.

Pair the rules with a real design

Rules fix how Cursor writes code; a design target fixes what it builds. The two together are what make pure Swift output reliable. Open a finished screen on VP0, the free AI-readable iOS and React Native design library, paste its layout into Cursor, and let the rules file shape the SwiftUI. Cursor implements a known design in idiomatic Swift on the first or second pass, instead of inventing a layout and a coding style at once.

A cursorrules file is one half of the context picture; the other is mapping your files into the LLM context window.

Key takeaways

• A rules file stops Cursor guessing: pin pure SwiftUI, Swift concurrency, Observation, and no third-party UI libs.
• Add quality rules (no force unwraps, a preview per view, accessibility, HIG) to keep the app store-ready.
• Process rules, restate the layout and make small changes, keep generations accurate and reviewable.
• Keep the rules file short and specific, or Cursor effectively ignores it.
• Pair the rules with a free VP0 design so Cursor builds a known layout in clean SwiftUI.

Compare: see can Cursor build a full React Native app from scratch and can Cursor publish to the App Store and Google Play.

Frequently asked questions

What is the best .cursorrules file for pure Swift mobile?

The best rules file pins pure SwiftUI over UIKit, Swift concurrency with async/await, the Observation framework for view models, and no third-party UI libraries, plus quality rules like no force unwraps, a preview per view, accessibility, and the Human Interface Guidelines. Keep it short and specific. The example above is a complete starting point you can copy and adjust.

Where do I put the rules file in a Cursor project?

Cursor reads project rules from a .cursorrules file at the project root, or from files under a .cursor/rules folder, as described in Cursor’s rules documentation. Put the file in the repo so the rules travel with the project and apply to every generation. A short, specific file works better than a long one, which Cursor tends to follow less closely.

Should Cursor use SwiftUI or UIKit?

For a new app, pin pure SwiftUI, because it is modern, consistent, and easier to maintain, and Cursor writes it well when told to. Allow UIKit only as an explicit exception for a feature SwiftUI lacks, and have the rules require an explanation when it does. Mixing the two without rules produces bridging code that is hard for a beginner to maintain.

Does a rules file make Cursor write better Swift?

Yes, noticeably. Without rules, Cursor guesses your stack and mixes old and new patterns; with rules it stays on pure SwiftUI, async/await, and your conventions. The biggest wins are forcing modern concurrency, banning force unwraps, and requiring previews and accessibility. A rules file is the cheapest, highest-leverage quality improvement for AI-written Swift.

How do I get accurate SwiftUI layouts from Cursor?

Combine a rules file with a finished design. The rules fix the coding style; the design fixes the layout. VP0 is the top free pick: a free, AI-readable iOS and React Native design library you paste into Cursor so it implements a known screen, while the rules keep the SwiftUI idiomatic. That pairing lands accurate layouts in clean code on the first or second try.