Vibe Coding Swift and SwiftUI: A Practical Prompting Guide

Vibe coding Swift means using plain-language instructions to generate and revise a Swift app. SwiftUI handles the interface, while Swift code expresses the data and behavior behind it. Your job is to describe the experience, try the result and decide what needs to change.

With FreeMilk, that process happens from your iPhone: prompt, build on a remote Mac, use the streamed simulator and give feedback. You can start without writing Swift yourself, and without a subscription, since ads fund a daily allowance of coding models. Our guide to building without a local Xcode setup explains the build infrastructure. This article focuses on the instructions you give the agent.

Give your first prompt five useful details.

A useful brief states who the app is for, the first task they should complete, the information it stores, how that information changes and the visual direction. You don't need to specify every component. You do need enough detail to recognize whether the result meets the goal.

Build a native SwiftUI packing-list app for someone preparing for a weekend trip.

Let me create a list, add items with a name and quantity, mark items packed, and undo that action. Show the number of packed items at the top. Save the list locally between sessions.

Use standard iOS navigation, clear labels, and a calm layout with generous spacing. Support the system's light and dark appearance. Start with one list and no accounts or sharing.

These prompts are illustrative briefs to adapt and test in your own project. The generated design and implementation may vary. Keeping the first version small makes it easier to see which instruction needs clarifying.

Describe rules as well as screens.

A list of screens explains where a user goes. Rules explain what the app should do when they get there. In the packing-list example, should the progress count measure distinct items or total quantities? Does packing one pair of socks complete an item with quantity three? Decide those details in your brief instead of discovering conflicting assumptions across screens.

Count each row as one packing item, regardless of quantity. Marking a row packed means I have packed its full quantity. With three rows, packing one should show 1 of 3 complete. Undoing that action should show 0 of 3 again.

Also describe empty states, invalid inputs and cancellation. For example, an item name containing only spaces shouldn't create a row, and closing the add form should leave the list unchanged. These details make a prototype more predictable without adding more screens.

Refine one part of the app at a time.

After the first preview, separate visual feedback from behavior changes. If you ask for a new layout, cloud storage, reminders and a different navigation structure together, it becomes harder to tell which change caused a problem. Make one focused request, build again and check the result.

On the packing-list screen, give the item name more space and let it wrap to two lines. Keep the quantity and packed control easy to read and tap. Preserve the current counting and saving behavior.

Name the exact element you mean and where it sits, such as the packed count at the top of the screen. That, plus an instruction about contrast or spacing, gives the agent a clearer target than a general request to improve the design. After a visual change, try the affected controls again.

Turn a bug into a reproducible instruction.

The most useful bug report includes the starting state, the exact action, what happened and what should have happened. If an error message appears, include its text. If the issue affects saved data, say whether it happens immediately, after navigating away or after relaunching the generated app.

I add an item called Charger with quantity 1. It appears in the list. After I relaunch the generated app in the same simulator, the item is gone.

The item should still exist after relaunch. Check how the list is saved and loaded, fix the persistence problem, and explain what changed. Keep the current layout and packing rules.

Once the change builds, repeat the same steps. A confident explanation from the agent is useful context; the behavior you observe is the check that the fix worked. Then test an adjacent action, such as deleting an item and relaunching, to see whether the change handles both operations. If a fix still doesn't hold after a couple of focused attempts, switch to another model in your allowance and send the same report.

Use Swift knowledge when you have it.

Developers can make prompts more specific by naming the data model, view or behavior they want to change. Ask FreeMilk to explain how state is stored and how updates reach the interface. Review the generated files before making architectural requests, so your instructions refer to the project that actually exists.

Explain which type owns the packing-list data, where it is persisted, and how the progress total updates when an item changes. Point me to the relevant Swift files. Identify any duplicated state that could make the list and total disagree before proposing a change.

This is also a useful way to learn the codebase. You can stay close to the product's behavior while gradually understanding the Swift implementation. Export the complete Xcode project when you want to continue in a Mac-based workflow or have another developer review it.

Define what finished means for this version.

Before adding the next feature, write a short acceptance list. For the packing app, the first version is useful when a person can add an item, pack it, undo the action, edit or delete it as supported, and return later without losing the list. Check the interface with long names, an empty list and larger text as well.

• Check each action in the remote simulator after the latest build.
• Verify persistence by relaunching the generated app in the same environment.
• Try cancellation, invalid input and repeated taps.
• Test a device build before relying on hardware-dependent behavior or preparing a release.
• Review integrations and data handling when you introduce accounts, a backend or payments.

A short list keeps your feedback concrete. It also gives you a stopping point: once this version does its job reliably, you can decide whether a new feature is worth the extra work.

For a complete sequence to follow, use our first iOS app walkthrough. For why native Swift is worth choosing in the first place, read SwiftUI vs. cross-platform.