10x — a macOS builder that turns a prompt into a SwiftUI iOS app you can open in Xcode

• 10x

  This page

  PricingRoughly even

  • A limited free credit allowance, then paid subscription plans that refresh a fixed monthly allowance
  • One-time credit packs that do not expire until spent, for a single app or a trial without a recurring charge
  • Credits are consumed per AI generation — the planning step and every build turn — with image generation billed on its own line
  • Unused subscription credits do not roll into the next period; pack credits stay on the balance

• Rork

  PricingRoughly even

  • A free tier that explores designs only, plus paid subscription tiers that unlock building
  • Build credits pay for prompting the agent; a separate balance covers runtime AI and cloud features
  • Credits reset each period rather than rolling over

• FlutterFlow

  PricingRoughly even

  • A free tier for exploring the builder with a limited allowance
  • Per-seat subscription tiers scale usage and collaboration
  • Running the generated Flutter project afterwards sits outside this platform
  • Store submission is your own time rather than a fee

• Lovable

  PricingRoughly even

  • A free tier with a daily allowance that resets, then subscription tiers
  • Credits are consumed per prompt and per edit, so heavy iteration is the cost driver
  • Hosting for the deployed app is included in the platform

1. 10x — official site
2. 10x — documentation
3. 10x — plans and credits
4. 10x — public repository and licence
5. Rork — official site
6. FlutterFlow — official site
7. Lovable — official site

Free tier

Yes

Pricing summary

This product bills by credits rather than by seats or projects, and the balance is spent by generating rather than by sitting in the app. Every AI run draws on it: the planning step that researches your idea and sketches the app, and each build turn that writes or edits SwiftUI. Image generation shows up as its own line item in the usage panel, and a handful of operations are marked free. You top the balance up in one of two ways, and the difference matters more than it first appears. A subscription plan refreshes a fixed allowance each billing period, which suits steady use across several projects. A one-time credit pack is a purchase that stays on the balance until you spend it, which suits a single app you build once or a trial without taking on a recurring charge. Unused subscription credits do not carry into the next period, while pack credits persist, so it is worth reading the usage panel to see how the two are split before buying more. How quickly credits move depends on the model selected and on the size of the request: longer prompts, bigger generated codebases and more detailed answers all cost more tokens and therefore more credits. The one thing to check before you plan around a free build is the free tier itself. The billing documentation describes a free plan tier with a limited credit allowance, while the official homepage FAQ tells visitors to choose a paid plan to start building. That is the vendor disagreeing with itself, and it is worth confirming for your own account rather than assuming either answer. Payments are processed through Stripe, and cancelling a subscription happens in the Stripe customer portal rather than inside the app. There are no per-seat or per-project charges to model here, so the only variable is how much you generate. Tier names, allowances and per-generation costs change, so confirm the current numbers on the official plans and credits page before you commit.

Reviewed on 23 September 2026 · 10x — plans and credits

• Planning and building as two separate passes

  Plan mode researches the idea, asks clarifying questions and produces a project plan; Build mode then writes SwiftUI using file tools against the real filesystem. The split is the most useful thing about the product, because most generated apps fail at the requirements stage rather than the coding stage. Answering a short plan before any code exists is cheaper than correcting code you did not want.

• Native SwiftUI output rather than a wrapped website

  Generated apps compile to Swift with SwiftUI, so the result behaves like a real iOS app instead of a web view in a shell. That distinction matters at review time: Apple rejects app-shaped websites regularly, and a genuine native build does not have that problem. It also means the code you end up with is the same class of code an iOS team would write.

• A live iOS Simulator preview with automatic error repair

  The app is compiled and launched on an iPhone Simulator, with a screenshot captured back into the builder so you can see the result without switching windows. Build errors are fed back to the AI to fix. Named screenshots let you keep a record of a working state, which is more useful than it sounds once you are thirty revisions in.

• A file explorer over the generated project

  A VS Code-style sidebar lists every Swift file the AI has written, with syntax-highlighted source you can read at any time. It is the difference between trusting the output and knowing what it contains, and it tells you early whether the structure is something you want to keep.

• Open in Xcode and continue by hand

  The generated project opens in Xcode, where you can run it on a real device, change build settings, add capabilities, or edit the code directly. This is the escape hatch that keeps the tool honest: what you have at the end is a normal Xcode project, not a platform-locked artefact, and a developer who has never used the builder can carry it forward.

• A Supabase backend and an environment panel

  Linking a Supabase project adds real authentication, a Postgres database and Edge Functions without you writing the client plumbing, and an environment panel holds API keys and credentials so the AI can reference them when it generates networking code. Keeping secrets there rather than in the prompt is both safer and less error-prone.

• Attachments as reference material

  Images, screenshots and text files can be attached to a prompt, so a rough mockup or a written spec can shape the build instead of being described in prose. For interface work especially, showing the AI a screen is faster and far more accurate than describing spacing in words.

• A public repository and an eval harness

  The builder application is published as source under a noncommercial licence, and the repository ships an eval harness with benchmark apps you can run from the command line. That is unusual at this stage of a product and it gives a technical buyer something concrete to inspect rather than a demo video.

1. 1

   Install Xcode and a Simulator runtime before you install the builder

   The app cannot preview anything without a working Xcode installation and at least one iPhone Simulator runtime, and on first launch it runs a system check that will not let you past until both are present. Open Xcode once so it finishes its own first-run setup, and download a Simulator runtime from the Platforms pane. Doing this first turns a blocked first session into a five-minute formality.

2. 2

   Spend your effort on the plan, not the prompt

   Plan mode exists to surface what you have not decided yet — the data model, the screens, the edge cases. Answer its questions properly rather than skipping to code. A vague plan produces an app that compiles and does not do what you meant, and every later correction costs credits on top of the build you are now throwing away.

3. 3

   Describe one screen before you describe a product

   The most common failure is opening with accounts, feeds and payments in a single prompt. Ask for one screen that does one thing, look at it on the Simulator, and only then describe the next. A generated codebase you can hold in your head is a codebase you can steer; a large one you cannot is one you will fight.

4. 4

   Check the Simulator, then check a real device

   The Simulator is faithful enough to build against and optimistic enough to mislead you about touch targets, scrolling and performance. Put a build on your own phone early, while there is still budget to change the design, rather than after another twenty iterations have been layered on top of a layout that does not work in the hand.

5. 5

   Keep the project in version control from the first working screen

   The generated project is a folder of Swift files, which means it can be committed like any other code. Committing after each working state gives you the one thing a chat interface does not: a way back to the version that worked. It also makes the handover to a developer trivial when you reach that point.

6. 6

   Budget for iteration rather than for one perfect prompt

   Credits are spent per generation, and building an app is inherently iterative, so the honest mental model is a running cost per project rather than a single charge. Plan a first pass, expect corrections, and keep an eye on the usage panel so the balance does not decide when your project stops.

• iOS developers who want a working first pass

  Someone who can read Swift gets a scaffold of real SwiftUI in an Xcode project, and from there the work is ordinary iOS development rather than fighting a generator. That is the fastest legitimate use of the tool: let it produce the structure and the boilerplate, then take over in Xcode for the parts that need judgement.

• Design engineers who work on a Mac

  If you think in interfaces and can read code without writing it all day, describing a screen and immediately seeing it on a Simulator closes a loop that normally needs a mobile developer. The style and audience choices in the onboarding wizard make the first pass closer to your intent than a blank-buffer start would be.

• Indie builders testing a phone-first idea

  For a single focused app — a utility, a tracker, a small tool — the cost of finding out whether the idea works is a Mac, Xcode and a credit balance, rather than a mobile team. The narrow scope is the point: this suits the app you can describe in a paragraph, not the platform you intend to grow for years.

• Teams already running Supabase

  Because linking a Supabase project wires up auth, a Postgres database and Edge Functions, a team that already works on that stack skips the back-end plumbing entirely. Connecting an existing project is a smaller step than standing up a new backend for a prototype.

• People who want to read the code, not just run it

  The file explorer and the Xcode handoff are the features that matter if you intend to own the result. Anyone who would rather inspect a generated file than trust a preview will find this arrangement more comfortable than a platform where the artefact only exists inside the product.

A macOS application, distributed outside the Mac App Store

The builder is a native Mac app requiring macOS 14 or later, shipped as a signed, notarised DMG on two channels: stable and beta. It updates itself through Sparkle, so you install once and reinstall only when switching channels. There is no web version and no Windows or Linux build, which is the first constraint to check against your setup.

Xcode 16 and an iOS Simulator runtime are hard requirements

The app uses Xcode build and simulator tooling to compile generated code and display a live preview, and it will not get past its own system check without them. At least one iPhone Simulator runtime is needed as well, and a recent runtime version rather than whatever shipped years ago. Treat this as a prerequisite of the product, not an optional extra.

iOS and SwiftUI only

The output is native iOS. There is no Android target, no web target and no cross-platform project, so a product that has to exist on more than one platform cannot be served by this tool alone. For a phone-first iOS idea that is a strength — there is only one platform to get right — and for anything broader it is a hard stop.

Two artefacts under different licences

The builder application is published as source in a public repository under a noncommercial licence, which lets you read it, self-build it and audit how it behaves. The hosted product is a commercial service billed by credits. Those are separate things, and the repository ships with placeholder configuration for its API endpoint, backend and update feed, so a self-build is a project in itself rather than a supported alternative to subscribing.

How the generation actually runs

The agent loop that plans and writes files runs in the client: it calls a model through a thin vendor proxy, parses the tool calls, executes the file operations against your local filesystem and repeats until the task is done. Projects, messages and the file tree persist locally under your developer library, with Supabase used for authentication. The practical reading is a local build and a remote model.

The marketing site and the documentation describe different scopes

The documentation covers the builder core: install, plan and build modes, Simulator preview, the file explorer, Xcode handoff, Supabase and environment variables. The marketing site adds a wider commercial story, including App Store submission handled up to review, automatic generation of store assets, marketing content, and integrations beyond Supabase. Those are plan-dependent features rather than the same product described twice, so verify what the tier you are considering actually includes before buying for a feature you saw on a landing page.

What it does not do

It does not produce Android or web apps. It is not a visual drag-and-drop builder — the interface is a conversation, and the fallback for anything the AI gets wrong is editing the Swift. It is not a replacement for Xcode or for iOS knowledge once the requirements get specific. It does not offer a browser-only or no-install path, and it is not a team environment with shared cloud projects and browser collaboration. Finally, it does not carry an existing large codebase: the workflow starts from a new project.