Uwarp

Rork — native apps from a prompt, and the second credit balance that trips people up

Chat your way to a real SwiftUI, Kotlin and web app, then publish to the App Store. What the free design-only plan leaves out and how the two credit balances work.

  • AI App Builder
  • Native Mobile Apps
  • SwiftUI
  • Kotlin
  • App Store Publishing
Publisher
Rork
Type
AI App Builder
Pricing
Freemium
Reviewed
19 September 2026
Official site

Quick verdict

Use when

  • You want a real installable app on the App Store or Google Play, not a website in a wrapper
  • You can describe what the app should do but do not want to write Swift or Kotlin from scratch
  • You want the underlying code to be editable, so a developer can take it further without starting again
  • You are building something small and concrete — a utility, a simple social app, an internal tool — rather than a platform
  • You would rather pay for store submission to be automated than learn how to produce signed builds yourself
  • You are comfortable with the idea that the app you ship may have an ongoing running cost

Skip when

  • You need a website or web app rather than something that installs on a phone
  • You have no budget at all: the free plan explores designs and cannot build or publish anything
  • Your product is a large or unusual system — complex data models, custom infrastructure, deep integrations — where generated code becomes a liability
  • You want an open-source or self-hosted pipeline, or you are unwilling to have your project live on a vendor platform
  • Your app is mostly AI features, and you do not want a per-use cloud balance funding the parts your users trigger
  • You need an app for a platform other than iPhone, Android or the web, or an app whose distribution is outside the two major stores

Try instead

If your output is a web app rather than something that installs, or the constraint is the back end, those live here too.

Rork vs Lovable vs FlutterFlow vs Replit

The question that separates these four is not which one is smarter but what you want to end up holding. Lovable is the reference point for prompt-to-app and it produces web applications: you describe a product, it builds a working React app you can deploy to a URL, and it is very good at that job. If your users will open a browser, that is the shortest path and this page is not for you. FlutterFlow is a visual builder for mobile: you assemble screens on a canvas, it generates Flutter, and it publishes to both stores. It gives you more deliberate control over layout and behaviour than a chat interface does, at the cost of working inside a builder rather than a conversation, and it asks you to learn Flutter concepts if you go deep. Replit is a different animal again — an AI-assisted development environment with hosting attached, which will happily build a web app and gives you a terminal, databases and deployment, and expects more of you in return. Rork takes the position that the output should be a genuine native binary: it writes SwiftUI for iPhone and Kotlin with Compose for Android, so what you get is the same class of app a mobile team would ship, with store submission automated through a build service. That is the whole bet, and it is worth being precise about what it costs. You are not getting a codebase you direct at a file level; you are iterating through an agent, and the deeper your requirements the more often you have to describe rather than edit — which is why the editor for the underlying code matters. You are also accepting two separate cost structures, since the subscription pays for building while the app your users run can draw on a separate balance. And you should discount most published coverage of this product before you read it: a great deal of it describes the builder as a React Native and Expo tool, which the vendor has since moved away from, so reviews written more than a few months ago are describing a different generator. Compare on what you end up holding — a URL, a Flutter project, a development environment, or a native app in the stores — because that choice is upstream of every feature list.

Tap a dimension to focus

Pricing

Roughly even
  • RorkThis page
    • A free tier that is design-only, plus paid subscription tiers that unlock build mode
    • Credits are the unit of everything, priced roughly as one request to design, build or edit the app
    • Free-tier allowance is capped per day and is larger in major markets than elsewhere, which makes the free plan effectively regional
    • A second, separate balance covers AI and cloud features that a finished app consumes at runtime, including on behalf of its own users
    • Credits do not roll over; paid plans reset on the purchase anniversary and the free plan at the start of the calendar month
    • Some actions cost more than one credit because device builds and cloud simulator sessions rent real machines
  • Lovable
    • A free tier with a daily allowance that resets, enough to evaluate rather than to run a product on
    • Paid tiers are subscriptions that scale the monthly allowance, with higher tiers adding collaboration and more usage
    • Credit consumption is per prompt and per edit, so a heavy iteration session is the cost driver
    • Deployment is included in the hosting the platform provides rather than billed as separate infrastructure
  • FlutterFlow
    • A free tier for exploring the builder with a limited allowance
    • Paid tiers are per-seat subscriptions that scale both usage and collaboration features
    • Because it generates a Flutter project you own, the cost of running the app afterwards sits outside this platform entirely
    • Store submission is not automated for you, so the cost of shipping is your time rather than a fee
  • Replit
    • A free tier with limited agent usage and public projects
    • Paid subscriptions scale the agent allowance and add private projects and more compute
    • Hosting and databases are billed on top of the subscription as the app runs
    • Because you get a terminal, you can bring your own services, which makes the true cost harder to predict than a fixed plan
  1. Rork — official site
  2. Rork — plans and subscriptions
  3. Rork — build credits vs cloud credits
  4. Lovable — official site
  5. FlutterFlow — official site
  6. Replit — official site

Preview of Rork - not the live app. Confirm details on the official site.

Does this overview help you decide?

—

(—)

Learn more

Details below the decision summary—features, workflow, and scope notes.

What is Rork?

Chat your way to a real SwiftUI, Kotlin and web app, then publish to the App Store. What the free design-only plan leaves out and how the two credit balances work.

What it costs

A free design-only tier, two paid subscription tiers that scale a monthly credit allowance, and a separate balance that your finished app spends when it runs.
Free tier
Yes
Pricing summary
There are two things to understand before comparing tiers, and the second one is the one that surprises people. The first is that the free tier is not a small version of the product — it is a different mode. Free explores designs: you describe an app and get proposed screens, and there is no build mode, no working preview and no publishing. You can look at what the product would make for you, and you cannot ship it. That is a fair way to sell, but it means "free plan" here should be read as a trial of the design step rather than as a route to a finished app. The second thing is the credit split. One balance, the build credits included with your subscription, pays for prompting the agent: designing, building and editing. The other is a separate balance that your finished app draws on at runtime when it uses the vendor’s AI and cloud features — including on behalf of your own users once the app is live. Those are billed and topped up independently. It means the monthly plan is the cost of building the app, not the cost of running it, and an app with AI features has a usage cost that scales with your users rather than with your prompts. Read that as good or bad depending on what you are shipping: a static utility may never touch the second balance, while an AI-first product is paying per interaction forever. Two mechanical details matter as well. Credits do not roll over, and the two balances reset on different schedules — paid plans on the anniversary of your purchase, the free plan at the start of the calendar month. And some actions consume more than one credit, because producing an iOS build or running a cloud simulator rents a real machine and is charged on top of the message that started it. The vendor also publishes several ways to earn credits without paying, including one tied to your app’s revenue through a payments integration, which is unusual enough to be worth knowing about. Tier names, allowances and per-action costs in this category move quickly, so confirm the current numbers on the official pricing and billing documentation before you commit.

Reviewed on 19 September 2026 · Rork — plans and subscriptions

What Rork includes

The capabilities as the product documents them, read against what each one is for in a real build.

  • Native output rather than a wrapped website

    It writes SwiftUI for iPhone and Kotlin with Compose for Android, the same languages a mobile team would use, producing a binary the stores accept as an app. That matters more than it sounds: wrapping a website is the usual shortcut, and it is the pattern store review rejects most often, so genuinely native output is the difference between shipping and being rejected. Web apps are a separate, deliberate output in React, published to your own address rather than a store.

  • One project can hold both mobile platforms

    You do not have to choose iOS or Android at the start. A single project can carry both, and you can ask for the second platform later, at which point the agent rebuilds the screens and flows in it. For a solo builder that removes the sequencing problem where you ship one platform, learn what you got wrong, and then have to port everything.

  • A simulator in the browser and a build on your own phone

    You can test without installing anything: run the app in the browser simulator, or scan a code and open it on a real device to see how it actually behaves. Testing on hardware matters more for mobile than for web, because touch targets, scrolling and performance all change once it is in your hand. Some of those actions consume more than one credit, which is the honest cost of renting the machine that runs them.

  • Store submission handled end to end

    Publishing automates the build, the signing certificates and the upload to both store consoles, which is normally the step where non-developers give up. You still need your own Apple and Google developer accounts, and the review process is still between you and the platform, but the mechanics that require a build machine are removed. On the entry paid tier this is what makes a portfolio of small apps realistic rather than a single project.

  • Dev mode, and the code is yours

    On paid plans the underlying code is editable, and the project can be exported so a developer can work on it outside the platform. This is the honest answer to "what happens when I outgrow this": you hand over a real codebase rather than rebuilding from nothing. A developer who has never used the platform can pick it up, which is a meaningfully different position from a tool that keeps the artifact locked inside itself.

  • A community library you can remix

    There is an explore surface of apps other people have built, and the onboarding actively suggests starting from someone else’s project rather than a blank prompt. That is the same instinct as starting from a template, and it is a legitimate way to get past the first screen — most people cannot describe an interface precisely until they have seen one. The trade is the usual one: a remix carries someone else’s structure, and structure is harder to change than styling.

  • AI and cloud features your finished app can call

    A built app can use the vendor’s AI and cloud services at runtime rather than only the developer integrating providers directly. It is the feature that makes an AI-first app plausible without a back end, and it is also the source of the second cost balance, because whatever your users trigger is billed as usage. The trade is explicit and worth understanding before you design around it.

  • Routes to credits that are not the subscription

    The vendor documents several ways to earn credits without paying, including one tied to your app revenue through a payments integration, contributions to the community, writing up your experience, and running events. A revenue-linked credit grant is unusual in this category and worth knowing about if you are building something that already makes money, because it scales with success rather than with a fixed plan.

How to get something shipped instead of something impressive

The loop that works, and the five places prompt-built apps go wrong.

  1. Start with one function, not one app

    The most common failure is describing a product on the first prompt — accounts, feeds, messaging, payments — and then spending the rest of the budget correcting the result. Describe a single thing the app does, get it working, then add the next. The agent can only hold a coherent picture if you keep the initial scope small enough to be coherent, and every correction after a bad first prompt costs credits.

  2. Test on a real phone before you iterate further

    The browser simulator is convenient and it lies slightly, because it does not reproduce real touch behaviour, real performance or real screen sizes. Open the build on your own device early, while there is still budget to change the design. An interface that felt fine in the preview and is wrong in the hand is far more expensive to fix after ten more prompts have been built on top of it.

  3. Decide who owns the code before you need to

    If there is any possibility that you will hire a developer or outgrow the platform, decide now that the project lives in version control and that the code is the source of truth — then export and sync it early rather than at the end. Discovering halfway through a build that the thing you have been iterating on is not the thing you can hand over is an avoidable and expensive surprise.

  4. Understand which balance you are spending and why

    Building the app spends your subscription credits; running it can spend a separate balance whenever the live app calls the vendor’s AI or cloud services. Those are different curves with different audiences — one scales with your iteration, the other with your users — and confusing them is how a project looks affordable while you are building it and expensive once it has an audience. Design the AI features with that split in mind rather than discovering it after launch.

  5. Accept that you are describing, not editing

    The interface is a conversation, and precision has to be expressed in words. For conceptual changes that is efficient and often better than editing by hand. For narrow changes — exact spacing, a specific animation curve, a particular query — it is slower than opening the code would be, and sometimes it never quite lands. Knowing which kind of change you are making tells you whether to keep prompting or to switch to dev mode.

  6. Budget the store side as a real step

    Automated submission removes the build machinery, not the review. You still need developer accounts with the platforms, still need the app to satisfy their policies, and still need to wait. Plan for the listing, the screenshots, the privacy declarations and the possibility of a rejection — and treat the first submission as a milestone in its own right rather than a formality after the build.

Who Rork is for

The builders and situations this product actually maps onto.

  • Founders who want something installed, not a URL

    The clearest fit: someone with a concrete product idea whose users will expect an app in a store, and who does not want to recruit a mobile team to find out whether the idea is worth building. Native output plus automated submission means the distance between the idea and a real install is measured in hours, which is the whole point of the category.

  • Developers prototyping a mobile interface quickly

    A developer who can read Swift or Kotlin but does not want to hand-build a prototype gets a scaffold they can then take over in dev mode and export. It is faster than starting from a blank project and the output is a real codebase rather than a mockup, which is the difference between something that can be demonstrated on a device and something that has to be imagined.

  • Small teams shipping several narrow apps

    The economics suit a portfolio approach — a handful of focused utilities rather than one large system — because both platform paths, submission and hosting are covered by the same plan and the same conversation. That is also where the per-app cloud balance becomes predictable, since a narrow app with no AI features may never draw on it.

  • People who tried a web builder and hit the store wall

    A recurring journey in this category ends with a fine web app that cannot be accepted into the App Store because it is a wrapper around a website. Arriving here is usually the result of that rejection, and the honest answer is that the output is genuinely different rather than that the platform is stricter.

  • Builders who want the AI features handled for them

    The runtime cloud features mean an app can have AI behaviour without the builder standing up their own inference, keys and billing. That removes real work, and it is worth choosing deliberately: the convenience and the ongoing per-use cost are the same decision, and someone who would rather control their own provider should plan to integrate it directly instead.

When Rork is the right pick

The interesting thing about this category is that all of its tools can be described as "build an app without a team", and almost none of them produce the same artefact. One produces a deployed website. One produces a project you continue to own and host. One produces a development environment. The question worth answering first is not which is cleverer but what you want to be holding at the end, because that choice decides everything downstream. This product answers it with a native binary: SwiftUI for iPhone, Kotlin with Compose for Android, compiled and submitted to the stores using your own developer accounts. The reason that matters is not purity. It is that Apple rejects app-shaped websites on a regular basis, and a genuine native build does not have that problem — a distinction that has become more consequential as store review has tightened. Where it is genuinely strong is the distance between an idea and something installed on a phone. There is a simulator in the browser, a build you can put on your own device without a development environment, and a submission process that handles signing and upload. For a founder with an idea and no mobile team, that is most of the hard part. Where it is weak is depth. You are iterating by describing, not by editing, so requirements that are specific rather than conceptual — a particular data model, an unusual integration, a piece of performance work — get progressively harder to land, and that is the point at which you either open the code yourself or hire someone who will. It is also worth being clear about the shape of the cost: the subscription buys the building, and a live app can spend a second balance at runtime, so an AI-heavy product carries a usage cost that grows with its audience. And if your product belongs in a browser, ignore all of this and use a web builder, because a native app would be the wrong answer to the right question. If what you want is something a person can install from the store, built by describing it, with the code still yours to open — that is exactly the case this tool was built for.

Product and platform notes

What it is, what it will not do, and the facts worth verifying at the source.
Native mobile and React web are two deliberate outputs
The mobile path produces SwiftUI for iPhone and Kotlin with Compose for Android. The web path produces a React app published to your own address. They are not the same product with a different skin, and choosing the wrong one at the start means the work does not transfer — a native app is the answer when the product belongs on a phone, and a web app is the answer when it belongs in a browser.
Published coverage of the technology is largely out of date
This is the single most important thing to verify before trusting a review. Much of what is written about this product describes the paid tier as a React Native and Expo builder and the top tier as a separate Swift tool. The vendor’s current documentation states that new projects are Swift, Kotlin or web, and that it no longer creates Expo projects at all — existing ones still build, publish and export. Any review older than a few months is likely describing a generator that no longer exists, which makes it useless for a buying decision.
Two balances, and only one of them is the subscription
Build credits are the monthly allowance your plan includes and they pay for designing, building and editing the app. Cloud credits are a separate balance that a finished app spends at runtime on the vendor’s AI and cloud features, including on behalf of its own users. They are billed and topped up separately. A static app may never use the second; an AI-first app pays for it in proportion to its popularity, which is a materially different cost shape from a flat subscription.
Credits do not roll over and some actions cost more than one
Paid plans reset on the monthly anniversary of the purchase and the free plan resets at the start of the calendar month, with unused credits expiring either way. Device builds and cloud simulator sessions are charged on top of the message that started them, because they rent real hardware. Both facts mean the same plan can feel very different depending on whether you iterate in bursts or steadily.
Shipping depends on your own store accounts
The platform automates the build, signing and upload, but the developer accounts with Apple and Google are yours, along with their fees and their policies. Automated submission does not mean bypassing review: the app still has to satisfy the platform’s rules, and the native output is an advantage there rather than a guarantee. Budget the listing work as part of shipping rather than as an afterthought.
What it does not do
It does not build or publish anything on the free tier, which is design-only. It does not produce a wrapped website where a native app is needed, and it does not target platforms beyond iPhone, Android and the web on current plans. It does not give you pixel-level control through the interface, and it does not stop being a hosted platform — the project lives on the vendor’s systems while you build it, even though the code can be exported. It also does not remove the ongoing running cost of an app that uses the runtime AI services.

Frequently Asked Questions

Quick answers about this tool—open a question to read more.