Turn Continue into a productive SwiftUI pair programmer. A step-by-step guide to using chat, autocomplete, and context to draft, refactor, and test SwiftUI code.
This guide shows how to use Continue's chat and autocomplete together to move faster on SwiftUI features. The goal is a repeatable workflow, not a single one-off trick.
We assume you already installed Continue in VS Code and connected a model. If not, set that up first, then come back.
The running example is a simple SwiftUI screen: a list view backed by a view model. The techniques apply to any SwiftUI feature you are building.
Throughout, remember the division of labor. Continue drafts and explains code in the editor, and Xcode compiles and previews it. Keep both open.
Open the Continue chat panel and describe the SwiftUI view you want in plain language. Be specific about the data it displays and the layout you expect.
Include your constraints in the prompt. State your minimum iOS version and mention any design system or existing components the view should match.
Review the generated code before pasting it in. Treat it as a first draft that reflects your prompt, not a guaranteed-correct answer.
Paste the view into your Swift file and immediately note anything that looks off. You will refine it with autocomplete and follow-up chat in the next steps.
Once the skeleton exists, autocomplete shines for the small stuff. As you type property names, modifiers, and bindings, accept inline suggestions with Tab where they match your intent.
Autocomplete is best at local, predictable code. Completing a ForEach body, a modifier chain, or a computed property is where it saves the most keystrokes.
Stay in control of acceptance. Read each suggestion rather than accepting on reflex, since a plausible-looking modifier can still be wrong for your target.
Use autocomplete to keep momentum inside a file, and reserve chat for questions that need broader reasoning across your view and its model.
Quality depends on context. Before asking chat to modify your view, highlight the exact code involved so the model sees precisely what you mean.
Use Continue's context features to reference related files, such as the view model that feeds your list. Connecting the view to its data source produces far more coherent edits.
When behavior depends on state, describe that state. The model cannot run your app, so tell it what the loading, empty, and error cases should look like.
Good context selection is a skill worth practicing. A few seconds spent highlighting the right lines routinely beats a long paragraph of description.
SwiftUI views drift toward being too large, and Continue is handy for tidying them. Select a bloated view and ask chat to extract subviews for readability.
You can also ask it to convert imperative patterns into more idiomatic SwiftUI, or to pull repeated modifiers into a reusable view modifier. Describe the outcome you want clearly.
Apply refactors incrementally. Make one focused change, verify it builds, then move to the next, rather than accepting a sweeping rewrite in one go.
Always diff the result against your original. You remain the reviewer, and small AI-introduced behavior changes are easiest to catch when the change set is small.
Ask Continue to draft unit tests for your view model logic. Provide the exact type and the behavior you want covered, including edge cases.
For UI, request SwiftUI previews that exercise different states. Previews for loading, empty, populated, and error states make your view far easier to iterate on.
Treat generated tests as scaffolding. Read them, confirm they assert the right things, and delete any that only restate the implementation without adding value.
Remember that tests only prove something when they actually run. You will execute them in Xcode, which is where the SwiftUI preview canvas and the test runner live.
Switch to Xcode to build the feature and open the SwiftUI preview canvas. This is the moment of truth, since Continue cannot compile or render your view.
Resolve any compiler errors. AI-generated SwiftUI sometimes references APIs that do not match your deployment target, and Xcode is where those mismatches surface.
Run your tests in Xcode and inspect the results. Passing tests here — not in chat — are what tell you the logic behaves.
Interact with the preview or run on a simulator to confirm the real behavior. Only after it works in Xcode should you consider the feature done.
AI-generated SwiftUI carries a few predictable failure modes, and knowing them speeds up your review. The most frequent is an API that does not match your deployment target, since the model has no view of your minimum iOS version.
Another is subtle state handling. A generated view may compile yet mishandle the loading, empty, or error case, so exercise each state in the preview rather than trusting a single happy-path render.
Watch also for retain cycles and concurrency issues in the surrounding code. A view that looks correct can still capture self strongly in a closure or touch the UI off the main actor, and only careful review or a build will surface that.
Treat every generated block as a draft that you own. The fastest SwiftUI workflow is not blind acceptance but a quick, disciplined read followed by a build in Xcode.
The single habit that most improves SwiftUI results is disciplined selection. Before you ask chat for a change, highlight exactly the view or function in question so the model is not guessing which code you mean.
Pair that selection with a concrete instruction. Saying what state should render, which iOS version you target, and which components to reuse turns a vague request into a specific, checkable task.
Short, focused prompts also make review easier. When you ask for one change at a time, the resulting diff is small enough to read fully before you accept it.
Over a few sessions this becomes second nature. Developers who consistently feed Continue precise context spend far less time correcting generic answers and more time shipping the feature.
The productive pattern is a tight loop: draft in chat, fill in with autocomplete, refactor, then verify in Xcode. Repeating it makes each SwiftUI feature faster than the last.
Lean on chat for reasoning and structure, and on autocomplete for local speed. Knowing which tool fits which moment is most of the skill.
Keep prompts and context sharp. The developers who get the most from Continue are the ones who feed it precise selections and clear constraints.
And keep ownership of correctness. Continue is an excellent SwiftUI accelerator, but your review and your Xcode build are what ship a working screen.
It can be, depending on the model you connect and how much context you provide. Strong models with well-selected context produce useful SwiftUI drafts, but you should always verify the output by building in Xcode.
Use chat for reasoning, generating new views, refactors, and explanations. Use autocomplete for fast local completions inside a file, like modifier chains and property bodies.
The model cannot see your Xcode deployment target and may reference APIs from a different iOS version. Always state your minimum iOS version in prompts and confirm the code compiles in Xcode.
No. Continue writes the code, but SwiftUI previews, simulators, and test runs happen in Xcode. Keep both tools open and verify there.
Highlight the exact code you are asking about, reference related files as context, and state your constraints clearly. Precise context is the biggest lever on output quality.