You designed the app. Now ship it.

You have probably tried one — Locofy, Builder.io, one of the plugins. They all share a shape: select frames, press convert, receive code.

The complaint is always the same, and it is structural rather than a quality problem any of them can fix. A one-shot conversion gives you output, not a project. The code mirrors your layer structure instead of an app's architecture, there is no navigation model, no state, no data layer — and the first time you change the design, you convert again and lose whatever anyone fixed by hand. It is a demo generator wearing a shipping tool's clothes.

The honest way to say it: converting the pixels was never the hard part. The hard part is everything around the pixels — the project the screens live in, the navigation between them, what happens when the list is empty or the network is not there. That is precisely the part converters skip, because it cannot be read out of a Figma file.

Modaal starts from the opposite end. It builds the app — architecture, navigation, state — and uses your Figma design as the source of truth for what the screens should look like, pulled through Figma's MCP as design context and screenshots rather than as layers to transliterate.

You describe the product in plain language — the screens, the flows, what matters. With Plan on, the first prompt becomes a PRD and a scaffolded project before anything is drawn.

Then you point the agent at your Figma file and work screen by screen. This is where it stops resembling a converter: the agent can see the app it is building. Modaal gives it "a live connection to the iOS simulator — screenshots, console logs, UI hierarchy, and the ability to tap, scroll, and switch tabs." When a screen does not match, you say so the way you would to a developer — except the round-trip is minutes.

And you can critique in a designer's vocabulary rather than a programmer's. Modaal's docs ship prompts built for exactly this. One, verbatim:

"I don't love this screen but can't name why. Give me 4 dials I can react to — like warmer/cooler, airier/denser, quieter/louder type, softer/sharper shapes — and show me what pushing each one would do."

That is a design review, not a coding session. It is also, frankly, a better feedback loop than most designers get from a contracted developer.

If you have a design system, bring it. If you do not, the documented workflow builds one with the agent in stages — direction, two north-star screens, then a freeze that writes every decision into two files: design-system.md for the reasoning and DesignTokens.swift for the values.

Those files then do the job a design system is supposed to do and mostly does not: they are enforceable. The tokens file is the single source the app draws from, and the docs include audit prompts to keep it that way — checking for hardcoded values that crept in, tap targets under size, and contrast in both modes. One of them, verbatim:

"Run an accessibility contrast check on this screen. Check every text element against its background, in both light and dark mode, and tell me whether each one passes WCAG AA."

Design drift — the gap between the system you specified and what actually shipped — is the thing you currently police by eye, in review, forever. Here it is a prompt.

A real iOS app. Native SwiftUI, in a standard Xcode project, on your own disk — "there is no export step; the project is a standard Xcode project on your own disk from the first build."

That matters to you for one specific reason: the handoff you are dreading works in both directions. If the project grows into something that needs engineers, you hand them an ordinary Swift codebase they can open, audit and extend — not a tool's proprietary output they will insist on rewriting. Your work survives the transition. That is the failure mode of every no-code tool you have been warned about, and it does not apply here.

TestFlight and App Store upload run from Modaal, with automatic device registration. The parts Apple insists a human does — the Developer Program at $99 a year, store metadata, screenshots for the listing — are still yours, and given who you are, the listing screenshots were always going to be yours.

You need a Mac. Modaal builds through Xcode, which is macOS-only — Xcode 26 or newer and roughly 50 GB of free disk. If you are on Windows, a browser-based tool like Superapp is the better fit and we say so in our own comparison.

The design tooling is iOS-first today. The design-system workflow and the audit prompts in the docs are written for SwiftUI and iOS. Android exists — Duet shares each feature's logic and renders it natively in Jetpack Compose, in open beta with general availability in September 2026 — but the design-side documentation has not caught up with it yet, and we would rather tell you that than have you find out.

"Builds the screens to match" means match, not replicate. The agent works from your design context and screenshots and iterates with you; it does not claim pixel-identical transliteration of every frame, and you should be suspicious of any tool that does.

You will see code. You will not write it, but it is on your disk and the agent will mention it. If that is disqualifying, a no-code builder is the honest recommendation — with the ownership trade-off above.