Guide · the route map · for people who don’t write Swift or Kotlin
The workflow to build a mobile app with AI in 2026, without writing code: every route on one map
The question on every forum is “what is the workflow”, and the honest answer is that there are several, and three choices decide which one is yours. This page puts all of them on one map: eight stages from idea to both stores, the tool options at each stage, and where each route ends up. Each stage links the page that goes deeper.
Verified
“Without writing code” is true of every route below: in 2026 an AI agent writes the code on all of them. What differs is what the code is (a web page in a shell, a cross-platform layer, or native Swift and Kotlin), who owns it afterwards, and how much of the surrounding work (plan, architecture, tests, builds, store submission) the tool does for you versus you supervising the agent. That is what “workflow” means here: not the prompts, but the stages and who does each one.
Before any tool, three choices. They are the same three on every route, and most “which tool” threads are really arguments about them.
The three choices that decide your route
1. Where you start. An idea on paper; a web app already built in Lovable, Bolt or similar; a Figma design; an existing iOS app or a repository. Each starting point has a different first stage, and two of them (the web app, the iOS app) have import routes that skip the rest.
2. The stack, which you cannot change later. A web app in a native shell (a wrapper); a cross-platform layer such as React Native or Flutter, one codebase that looks the same on both phones and native on neither; or native, SwiftUI on iPhone and Jetpack Compose on Android, what Apple and Google build with. Switching stacks later is a rewrite, so this is decided once. Native vs cross-platform is the full argument; the short version is that AI removed the cost that used to justify not going native.
3. How long the app has to live. A demo, a prototype to test an idea, or an app with users and a roadmap. Screen count is not the metric; the question is whether you will still be adding features in six months. If yes, the route needs an architecture the agent follows and tests that run on every change, or every feature starts breaking the last one (why vibe-coded apps break on every new feature).
With those three answered, the map below reads itself.
Stage 1. Validate the idea before the first prompt
Options: a post on Threads, Reddit or LinkedIn asking what people use today and what it lacks; a short form (30 questions is a real number one founder used) sent to the people who answered; interviews with the ones who filled it in; the “five-star review” exercise, writing the review you want to receive and cutting every feature it does not mention.
Tool variation: none worth paying for. A chat model is useful for writing the questions and summarising the answers.
Produces: the one sentence the app does, and the feature you will not build. Test your app idea before you build it.
Stage 2. Write the spec
Options: a one-page PRD written with a chat model from a template (the PRD prompt); the same document generated inside the builder (Modaal’s Plan mode writes “a structured implementation plan (a feature spec) without writing code”, which you approve before any screen exists); or no spec, which is a choice, and the one that produces the folder of views.
Tool variation: any chat model for the PRD. The difference between tools is whether the plan step is enforced or optional.
Produces: the screen list, the features in order, what the first version leaves out.
Stage 3. Design the screens, or decide not to
Options: reference first, from a library of real app screens (Mobbin and its alternatives, compared), then let the agent build from the platform’s parts; a Figma file, read by the agent through Figma’s MCP server or given as a link (Figma to SwiftUI and Jetpack Compose); or a hired designer, which one solo founder on 17,000 users says was her best decision and her biggest week of copy-paste because no tool read the file at the time.
Tool variation: Figma’s MCP server connects to Claude Code, Cursor, Codex, Android Studio, Xcode (beta) and others on all seats and plans; Modaal takes Figma links in the first prompt.
Produces: a picture or a reference for every screen in the PRD.
Stage 4. Build: the stage where the routes split
This is the stage “which tool” threads are about, and the stack choice already made it. The routes, by what comes out:
Route A. Web builder, then a wrapper. Build in Lovable, Bolt, Replit, Base44 or v0; the output is a web app. To reach the stores, wrap it: Capacitor puts the web build inside a native shell and gives you the native project; a service such as Despia does the same with native features plugged in (“your web code running in the platform WebView”, in its own words) and exports the Xcode and Android Studio projects. Fastest to a store listing; still a web page inside, so Apple’s guideline 4.2 applies (“Your app should include features, content, and UI that elevate it beyond a repackaged website”), and every change in the web builder is a rebuild and retest. Lovable + Despia vs a native rebuild.
Route B. Cross-platform builders. Tools that output React Native/Expo or Flutter: one codebase, both stores, the same UI on both. Right when the team already works in that framework; the cost is a layer between you and each platform, so new iOS features and the native feel arrive late or not at all. Vibe coding Flutter covers one side; the best native app builders page sorts every builder by its own documentation, including this tier.
Route C. A general agent, native. Claude Code (or Codex, Cursor) on an empty folder, writing SwiftUI; the same agent inside Xcode’s chat, which is the same agent in a different window. The cheapest route in subscription terms and the most expensive in your time once the app is past the mock screens: you choose the architecture, write it into the project rules, tell the agent to write and run tests, research the backend, manage the secrets, and test every device state yourself. Building iOS apps with Claude Code lists what breaks; using an agent with Xcode covers the Xcode side.
Route D. Native app builders. Tools that produce native Swift for Apple platforms from a prompt, such as Rork Max (Apple-only; Android is a separate app per its docs; export on paid plans only). Right for one prompt today and a store listing tomorrow; check export terms and the Android answer before you pay.
Route E. Native, both platforms, from one project, with your own agent. Modaal: the agent you already pay for (Claude, Cursor or Codex) works inside an architecture where each feature’s logic is written once and rendered in SwiftUI on iPhone and Jetpack Compose on Android, with a plan you approve before code and tests that run on every change. The Xcode and Android Studio projects are on your disk from the first feature; no tokens are charged on top of your subscription. Right when the app has to live (choice 3) and you want both stores without two codebases. The Free plan covers one project with unlimited prompts on one platform; Pro is €9 per user per month billed annually (€15 monthly) and adds both platforms, TestFlight distribution and Git collaboration (/pricing).
Route F. Import what you already have. A web app with its code in a repository, or an existing iOS app, read by an agent and rebuilt natively feature by feature against the same backend. Web app to native and convert an iOS app to Android; both imports are rolling out to early-access users in October 2026.
Produces: on A, a store-ready shell around a web app; on B, one cross-platform codebase; on C–F, native projects in Xcode (and Android Studio) that an engineer can open.
Stage 5. Backend, once
Options: Firebase or Supabase under your own account, which every route above can talk to; a builder’s own backend, convenient on day one and the thing to ask the export question about; or none, for an app that stores nothing and logs nobody in.
Tool variation: the backend costs the same whichever tool you build in; what differs is whether it is in your account. The thing that goes wrong is the keys: pasted into the agent’s chat or committed to the repository. Vibe coding and API keys has the four rules and the one prompt to send before any backend code.
Produces: a backend you can take to any other tool, and keys that stay out of the chat.
Stage 6. Test on glass, in every state
Options: the simulator, which every route uses; a real phone in your hand, which every route needs (the sofa test: use it for ten minutes as a stranger would); TestFlight and Play testing tracks for the people you want to try it.
Tool variation: what the agent can test on its own. The default developer tools let an agent build and launch the app but not rotate, fold or pose the device, so it tests one state and reports done; Modaal gives the agent those controls and it checks each state itself. How AI agents test iPhone apps in the simulator. For a Duo-era app that is not optional: how to make an iPhone Duo app.
Produces: a list of what passed on a real phone, which becomes the next prompts.
Stage 7. Publish from your own accounts
Options: none worth varying. Apple Developer Program, $99 a year; Google Play Console, $25 once; opened in your name in week one, because review takes days and the listing (name, screenshots, privacy answers) is a product of its own. From April 2027, every iOS app or update uploaded to App Store Connect “must be built with the iOS 27 & iPadOS 27 SDK or later”.
Tool variation: some builders upload for you; the account is still yours and so is the rejection. App Store rejection reasons lists what review sends back, 4.2 first.
Produces: the app in both stores, under your name.
Stage 8. Maintain, which is where the route is judged
Options: the weekly loop (one feature per session, plan first, phone after; the vibe coding workflow); or the rebuild, when the app built on a route with no architecture reaches the point where every fix adds two bugs.
Tool variation: this is the stage that separates routes A–D from E. On a route with no enforced structure, you are the architecture and the test suite, every week. On a route with both, the agent is held to them. And on every route, code export vs lock-in lists the six things a builder can hold hostage; check them before stage 4, not at stage 8.
Produces: an app that is still cheap to change in month six.
Which route, by where you start
An idea, a demo, no users planned: Route C or D. Claude Code alone or a native builder; any structured tool is overhead for an app that will not get a seventh feature.
An idea, and the app has to live, iPhone and Android: Route E. Spec in stage 2, references in stage 3, plan before every feature.
A web app already built in Lovable and the website is the product: Route A. Wrap it; plan for 4.2.
A web app already built in Lovable and the mobile app is the product: Route F. Keep the backend, users and auth; rebuild the screens natively.
A Figma file and a designer’s standards: Route E or C, with the file read by the agent at stage 3; the plan at stage 2 is where the designer’s decisions survive.
An existing iOS app and no Android engineer: Route F. The Xcode project is the spec.
A team already working in React Native or Flutter: Route B. The framework is the team’s; the trade is known.
The six build routes, compared
| Route | What comes out | Both platforms | Code on your disk | Who holds the architecture | Best for |
|---|---|---|---|---|---|
| A. Web builder + wrapper | Web app in a native shell | Yes, same page | Depends on the builder; the wrapper exports | Nobody; it is a web page | Website is the product |
| B. Cross-platform builder | React Native or Flutter codebase | Yes, same UI | Depends on the builder | The framework | Teams already in RN or Flutter |
| C. General agent (Claude Code, Xcode chat) | Native Swift | No; Android is a second project | Yes | You | Small apps, people who will supervise |
| D. Native builder (Apple-only) | Native Swift | No; Android separate | Paid plans, check terms | The builder | One prompt to a store listing |
| E. Modaal | SwiftUI + Jetpack Compose from one project | Yes, native on each | Yes, every plan | The framework (Duet) + tests | Apps that have to live, both stores |
| F. Import (web repo or Xcode project) | Native, rebuilt from what you have | Yes | Yes | Same as E | Existing web app or iOS app |
Routes C–F produce projects an engineer can open in Xcode and Android Studio; A and B produce something else inside. Export terms for named tools are on the pages linked above, read on the dates given there.
Frequently asked questions
The one that matches three choices: where you start (idea, web app, Figma file, existing app), which stack you want (wrapper, cross-platform, or native Swift and Kotlin), and how long the app has to live. Then eight stages: validate, spec, design, build, backend, test, publish, maintain. The build stage is where the routes split; the maintain stage is where the choice is judged.
Yes, on every route on this page the agent writes the code. What you still do is decide: the spec, the stack, the backend, what the first version leaves out, and whether the result works on a real phone. On routes with no enforced structure you also supervise the architecture and the tests; on routes with both, the tool holds the agent to them.
As a prototype to test the idea, yes; many people do, and Lovable syncs the code to GitHub. If the website is the product, wrap it for the stores and plan for Apple’s guideline 4.2. If the mobile app is the product, keep the backend, users and auth and rebuild the screens natively; the Lovable app stays the web product.
Claude Code alone is the cheapest in subscription terms and the most expensive in your time once the app is past the mock screens: you choose and enforce the architecture, tell the agent to write and run tests, research the backend and manage the keys. A builder that runs on the same subscription (Modaal does) charges nothing for tokens and does that supervision for you; whether a seat is worth it depends on how long the app has to live.
To build with Xcode, which is Apple’s build system, simulator and signing tool, yes. Some builders build on their own servers so you do not; the trade is that the Xcode project is not on your disk. Modaal builds locally with the Xcode you select and the project stays on your Mac.
Three ways: a wrapper (the same web page on both), a cross-platform framework (the same UI on both, native on neither), or a structure where each feature’s logic is written once and rendered in SwiftUI on iPhone and Jetpack Compose on Android, which is how Modaal does it. Apple-only native builders produce Android as a separate app or not at all; check before you start.
Six things a builder can hold: the code, the data, the backend, the build pipeline, the store accounts and the pricing. Ask whether the project is on your disk, on which plan, in which format, and whether the backend is in your account. Then whether it produces both platforms, and whether it enforces a plan and tests or leaves them to you.
Pick the route. Write the spec. Let your agent build both platforms.
Modaal is route E: your own Claude, Cursor or Codex subscription, a plan you approve before code, native SwiftUI and Jetpack Compose from one project, on your disk. Free for one project.
Keep reading
- Vibe coding workflow for a mobile app
The weekly loop once you have picked a route.
- How to make an app: seven decisions
The decisions behind the three choices.
- Native vs cross-platform
The stack choice in full.
- iOS app development by skill level
The same routes, sorted by what you can already do.
- Code export vs no-code lock-in
The six things to check before stage 4.