“Vibe coding” usually describes asking an AI to turn an idea into software and steering the result through conversation. For a Swift app, the useful version still includes reading changes, compiling, testing behavior and checking the interface. A fluent completion message is not an acceptance test.

Start with an observable promise

“Make a beautiful to-do app” leaves important decisions unstated. Does a task survive a restart? Can the user undo deletion? Does an empty search explain what happened? The agent can fill these gaps, but its choices may not be yours.

Try this smaller brief:

Create a local task list with a title and completion state.
An empty title cannot be saved.
Tasks survive terminating and reopening the app.
Searching never deletes stored tasks.
Support larger text and meaningful accessibility labels.
Before editing, identify the existing scheme and storage design.

Each sentence gives you something to inspect. The purpose is not to find magic wording; it is to make disagreement visible before a large implementation exists.

The development loop

The evidence loop
  1. 1Describe behavior
  2. 2Inspect proposed change
  3. 3Build and exercise
  4. 4Accept or return failure

The decision in this diagram is based on evidence. When a test fails, return the actual failure to the agent with the acceptance criterion it violated. When a build cannot run, stop at “implementation written, build unverified.” Do not silently turn that into “finished.”

Divide responsibility deliberately

Participant Useful work What it cannot establish alone
Developer Choose behavior, inspect tradeoffs, accept changes That a plausible implementation actually runs
Coding agent Inspect source, propose edits, invoke available tools That an unexecuted check passed
Swift compiler Check the program against a selected toolchain That search or persistence matches the brief
Tests and simulator Exercise selected behavior and presentation That every device and every input works

For your first feature, retain a checkpoint before the edit. Ask for one change, review the diff, and run the relevant check. If the agent also rewrites navigation or adds a networking dependency, ask how those changes relate to the requested feature. A small diff makes both review and rollback easier.

Exercise: turn an adjective into a check

Take “fast, accessible search” and split it into independent questions. What data set will you test? What does no match look like? Can VoiceOver identify the search field? Does clearing the query restore the list? Avoid inventing a performance number until you have a measurement method and a representative device.

Write those answers in your brief. Ask the agent to identify missing decisions without editing any files. Then pick one transition to implement. You now have a useful collaboration boundary instead of an unlimited “build everything” instruction.

What this lesson establishes

This is an orientation lesson, not an app-generation benchmark. It makes no claim about reduced cost, universal correctness or a client finishing an app unattended. The project's verification contract explains how to distinguish inspected code from executed results.

What to do next

Next: What you need before an AI can build you an iOS app: Mac, Xcode, Apple ID, simulator