Swift prompts for SwiftUI, concurrency and testing

The best Swift prompts tell the model your Swift version, language mode and minimum OS version, then paste the real code and the real compiler output and ask for one specific change. Below are 12 Swift prompts for ChatGPT, Claude, Claude Code and Codex covering SwiftUI screens, Observation, Swift 6 concurrency, idiomatic Swift and Swift Testing.

For general jobs such as explaining code or writing a commit message, see the coding prompts. If you also ship on Android, the Kotlin prompts cover the same ground for Jetpack Compose and coroutines.

How to use these prompts

Copy a prompt, replace each blank in double braces, or keep the default after the colon. {{min_os:iOS 17}} means the model should assume iOS 17 unless you change it.

Three habits make the answers better:

• Give versions. Swift 6.4 was released on 15 September 2026. The language mode is separate from the toolchain: a target can use the 6.4 compiler in Swift 5 mode. The minimum OS decides which SwiftUI APIs exist.
• Paste compiler output, not a summary. Swift concurrency diagnostics name the exact type and isolation boundary. The model needs that text.
• Ask for one change at a time. A prompt that asks for a new screen, a migration and tests at once usually gets all three half done.

In an agent, let it run swift build and swift test itself and report the results.

How do you build SwiftUI views with AI?

1. Build a SwiftUI screen from a description

For a first version of a screen. Asking for small subviews and previews keeps the result easy to change.

Build a SwiftUI screen for {{feature:a settings screen with a profile header and toggles}}.

Target: {{min_os:iOS 17}}, Swift {{swift_version:6.4}}.

- Split it into small views, each under about 40 lines.
- Keep state as low in the tree as possible and say which view owns each piece of state.
- Use the system font styles and semantic colors so Dynamic Type and Dark Mode work.
- Give every interactive element an accessibility label if its text is not enough.
- Add a #Preview for the screen with sample data.

Do not add third-party packages. After the code, list any assumption you made about data or navigation.

2. Migrate ObservableObject to @Observable

For apps that now target iOS 17 or later. Apple's migration guide says Observation is available starting with iOS 17, iPadOS 17, macOS 14, tvOS 17 and watchOS 10, and that you can migrate one model type at a time.

Migrate this SwiftUI code from ObservableObject to the Observation framework (@Observable).

Minimum OS: {{min_os:iOS 17}}.

Follow Apple's migration steps:
- Replace ObservableObject conformance with the @Observable macro and remove @Published.
- Replace @StateObject with @State, and @EnvironmentObject with @Environment.
- Remove @ObservedObject where the view only reads properties; use @Bindable where the view needs bindings.
- Mark properties that should not trigger updates with @ObservationIgnored.

Migrate only {{scope:the Library model and the views that use it}}. List every view whose update behavior might change, since Observation only updates a view when a property its body reads changes.

{{code}}

3. Find why a view updates too often or loses state

For a list that stutters, a text field that resets or a sheet that forgets its data. These usually come from state owned by the wrong view.

This SwiftUI view {{symptom:resets its text field when the parent refreshes}}.

{{code}}

Explain which view owns each piece of state and when SwiftUI recreates it. Check for: state created in an init, an object stored in a plain property instead of @State, unstable identity in ForEach, and views whose identity changes because of if/else branches.

Give the smallest fix and explain why it works. Do not restructure unrelated views.

How do you get Swift concurrency right?

4. Fix Swift 6 data-race errors

For compiler errors after turning on the Swift 6 language mode. The Swift migration guide says that by default, Swift 6 enables full data race safety checking.

After switching to the Swift 6 language mode, I get these errors:

{{compiler_errors}}

Relevant code:
{{code}}

For each error:
1. Explain in plain language which value crosses which isolation boundary (main actor, another actor, a nonisolated context).
2. Propose a fix, preferring in this order: keep the work on one actor, make the type Sendable for real (immutable or a value type), use an actor, then anything else.
3. Do not use @unchecked Sendable or nonisolated(unsafe) unless you explain why the code is actually safe.

Show the changed code only for the lines that change.

5. Plan a Swift 6 language mode migration

For a package or app with many modules. The migration guide shows you can keep individual targets on Swift 5 with .swiftLanguageMode(.v5) and enable complete checking as warnings first with -strict-concurrency=complete.

Plan a migration of this project to the Swift 6 language mode.

Package.swift or target list:
{{manifest}}

Warning counts per target with -strict-concurrency=complete (if I have them):
{{warning_counts:not measured yet}}

Give me:
1. The order to migrate targets, starting with leaf modules that have the fewest dependents.
2. For each target, the exact setting to use while it stays on Swift 5 and the setting once it moves to Swift 6.
3. The patterns you expect to cause the most warnings in this code and a fix strategy for each.
4. A checklist I can run per target before switching it.

6. Convert completion handlers to async/await

For older networking or database code built on callbacks.

Convert this callback-based Swift code to async/await.

{{code}}

- Keep a thin completion-handler wrapper only if {{callers:other modules still call the old API}}.
- Use withCheckedThrowingContinuation only where the underlying API has no async version, and make sure every path resumes exactly once.
- Support task cancellation: check Task.isCancelled or call try Task.checkCancellation() in loops and before expensive work.
- Say which functions should run on the main actor and which should not.

List any behavior change, such as callbacks that previously fired on a background queue.

How do you write idiomatic Swift with AI?

7. Review Swift code for idioms

For code ported from Objective-C, Java or Kotlin, or written in a hurry.

Review this Swift code for idiomatic style, targeting Swift {{swift_version:6.4}}.

Check: force unwraps and force casts that can fail, optionals handled with if let, guard let or ?? instead of nested checks, value types (struct, enum) where reference semantics are not needed, protocol-oriented design over class inheritance, access control (private by default), and naming that follows the Swift API Design Guidelines.

For each issue, show before and after with one sentence on why. Do not change public API names unless I agree.

{{code}}

8. Model errors and states with enums

For code that passes around optional fields and Bool flags that can contradict each other, like isLoading true with an error set.

This Swift code tracks {{feature:a network request}} with several optional properties and Bool flags:

{{code}}

Redesign it with enums so impossible states cannot be represented:
- An enum for the view state (for example idle, loading, loaded with data, failed with error).
- An Error enum for the failures callers need to tell apart: {{cases:offline, unauthorized, server error}}.

Show the new types, the updated code, and how a SwiftUI view switches over the state. Explain any case you added or merged.

How do you test Swift code with AI?

9. Write Swift Testing tests

For new tests. Apple's Swift Testing docs list features such as parameterized test functions, tags, and running tests in parallel in-process.

Write tests for this Swift code using Swift Testing (import Testing), not XCTest.

{{code}}

- Use @Test functions grouped in a struct, with readable display names.
- Use #expect for checks and try #require when a later check depends on a value existing.
- Use a parameterized @Test with arguments for the input cases instead of copy-pasted tests.
- Cover the normal case, boundaries, invalid input and every thrown error.
- Test async functions with async test functions, not expectations and waits.

Say which tests are safe to run in parallel and why.

10. Migrate XCTest tests to Swift Testing

For an existing XCTest suite. Apple's migration article says a single source file can contain both kinds of tests, so this can happen one file at a time.

Migrate these XCTest tests to Swift Testing.

{{code}}

- Replace XCTestCase subclasses with structs and test methods with @Test functions.
- Replace setUp with init and tearDown with deinit only where the type allows it; otherwise explain the alternative.
- Map each XCTAssert call to #expect or #require and keep the same meaning.
- Keep tests that need XCTest-only features (such as UI tests or performance tests) in XCTest and say why.

Change nothing about what each test checks.

How do you debug and polish a Swift app?

11. Diagnose a crash from a crash report

For a crash you have a symbolicated report for but cannot reproduce.

My {{platform:iOS}} app crashes in production. Symbolicated crash report (crashing thread and exception info):

{{crash_report}}

Code for the frames from my app:
{{code}}

1. Explain what the exception type and the top frames mean.
2. List the most likely causes in this code, most likely first, such as a force unwrap, an out-of-range index, or UI work off the main thread.
3. For each cause, the change that would prevent it and a test or log line that would confirm it.

Do not guess at frames you cannot see.

12. Review a SwiftUI view for accessibility

For a screen before release. Run the result past VoiceOver yourself; the model cannot hear what it reads aloud.

Review this SwiftUI view for accessibility.

{{code}}

Check:
- Every control has a meaningful label for VoiceOver, and decorative images are hidden from it.
- Related elements are combined so VoiceOver reads them as one item where that makes sense.
- Text uses Dynamic Type styles and the layout still works at the largest accessibility sizes.
- Tap targets are large enough and nothing relies on color alone.

For each issue, give the fix as a code change and say how to verify it on a device.

What should you check before you accept the answer?

AI-written Swift tends to go wrong in the same few places:

• API availability. Check that every SwiftUI API in the answer exists on your minimum OS. Models often reach for APIs newer than your deployment target.
• Silenced concurrency errors. Search the diff for @unchecked Sendable, nonisolated(unsafe) and @preconcurrency. Each one needs a written reason.
• Force unwraps. Search for ! after optionals and as! casts that the original code did not have.
• Real builds. Build and run the tests yourself, or have an agent run swift build and swift test and paste the output.

For deeper SwiftUI rules inside an agent, the SwiftUI Pro skill and the SwiftUI Expert skill give Claude Code or Codex guidance it applies on every task, and the Swift Concurrency Pro skill does the same for actors and Sendable.

How do you keep your best Swift prompts?

Once a prompt becomes a habit, turn it into a skill so an agent uses it without being asked. The data-race fix and the Observation migration prompts are good first candidates. Paste one into the free SKILL.md generator, which runs in the browser with no sign-up, and it becomes a valid SKILL.md.

To keep prompts like these in one place, save them in Kipt. Your library is stored as Markdown in a private GitHub repo you own, each blank stays fillable when you copy a prompt, and Cmd+K finds any prompt by name or tag. If you build the same app with Flutter, see the Flutter prompts.