Outgrowing a builder is a handover, and the hard part is the account, not the code.
You have outgrown a builder when the next thing you need is a thing the builder has no way to express. A native library with no config plugin. A second person who needs branches. A reviewer asking a question only someone reading the code can answer. If the tool wrote a real project into a repository you own, that moment is a handover and not a rewrite, because the code is already yours. What does not move on its own is the store listing, the signing identity and the release habit, and those are the three people discover last. Every command, field name and condition below comes from Expo's and Apple's own documentation, read on 16 October 2026.
What follows is what you actually own, what one command does to the project and whether you can undo it, and the conditions Apple puts on moving a listing to somebody else. One of those conditions rules out most apps that never left TestFlight.
Start hereThe short version
The repository walks out with you. The listing does not.
Three different things get confused under one word. The code, which is a React Native and Expo project in Git. The build, which is an artifact signed by a certificate tied to a developer account. And the listing, which is a record inside somebody's App Store Connect account with reviews, ratings and a download history attached to it. A builder that hands you the repository has solved the first one. The second and third are account problems, and accounts move on Apple's and Google's terms rather than yours.
So the order matters more than the decision. Get the code into a Git remote you control. Get the developer account into the name of whoever will own the app in two years. Only then argue about whether you still like the tool. Doing it the other way round is how people end up republishing as a new app and throwing away every rating they earned.
What does outgrowing a builder actually look like?
It looks like a list of small blocked tasks, not a feeling about the app. A library you need has native code and no config plugin, so no amount of prompting installs it. A second person joins and you need branches, review and a history somebody can read six months later. A release went to everyone at once and you wanted it staged. A tax or privacy question arrives and the answer has to come from someone who can read the source. Each one of those is a specific job, and three of the four are solved without leaving the tool.
Revenue is the signal people read wrong. An app that makes money has not outgrown its builder. It has earned the right to be worked on, which is a different sentence. The useful question is narrower: is the thing standing between you and the next pound of revenue a code change the tool cannot make? If you are still choosing between a subscription, a one-off price and advertising, that is app monetisation and the tool is indifferent to your answer. If you need a payment flow nobody has a template for, then adding payments is a real reason to bring somebody in.
There is one signal that is not about capability at all. Somebody else is going to own the business, or the app, or the contract. That is not a technical problem and no amount of refactoring touches it. It is a transfer, with conditions attached, and the conditions are published. It is worth knowing them before anyone shakes hands, because at least one of them cannot be fixed on the day.
Check yours
Which exit do you actually need
Tick what is true today. Most of these are solved by a command or a repository invite. Only two of them need anyone outside your team.
Nothing ticked. Then you have not outgrown the builder, you are busy, and the cheapest next step is to ship the thing you were going to rewrite.
What do you actually own when you leave?
A React Native and Expo project in a repository, which is the thing a developer would have written anyway. What you may not have is an android or an ios directory, and that absence is the single most common reason somebody concludes the code is incomplete. It is not. Expo calls the approach Continuous Native Generation: the native projects are generated only when they are needed, such as when debugging or building, from a standard template plus your app config and any custom code. Expo's documentation says those directories are automatically added to .gitignore when you create a new project. They are absent on purpose.
The practical consequence is that the thing you maintain is a definition, not a native project. Expo puts it as the developer being responsible for only maintaining the definition of their customizations. Icons, splash screens and native settings come from one config value rather than two platform projects. The upside is upgrades: Expo says that with prebuild, upgrading is much closer to upgrading a pure JavaScript application. The downside is honest and also documented. Making a change directly in native code is quicker than modularising and automating it, and not every library has a config plugin yet.
Two words have stopped meaning anything, and knowing that saves an argument with your first contractor. Expo's prebuild page opens by saying the managed and bare workflow concepts are deprecated, and that all Expo projects now use Continuous Native Generation. It redirects anyone asking about ejecting from Expo to that same page. So if a developer says the app has to be ejected before they can start, they are describing a workflow the current documentation does not contain. There is a command, it is called prebuild, and it is not a door that locks behind you.
Expo documentation, prebuild, read 16 October 2026, page last updated 25 September 2026
What changes the first time you run prebuild?
Three things, and only one of them changes how anybody works. Running npx expo prebuild creates the android and ios directories for running your React code. It also edits package.json in two places: the dependencies field, and the scripts field, where the expo start scripts for android and ios are replaced by expo run:android and expo run:ios. Expo calls that scripts change the only side effect that alters how a developer works, and says all other changes can be left in place and committed to git to minimise the diff when running prebuild again.
Then the part that decides whether any of this is reversible. Expo says the system is fully optional and that you can stop using it at any time. Re-running prebuild without the clean option layers changes on top of the existing files. With the clean option it deletes any existing native directories before generating them again, which is why the documentation calls that the safest way to use the command, and why it warns you about uncommitted changes in your git repository first. Deleting the generated directories is a normal thing to do, not a rescue. The documentation does not spell out how to undo the package.json edits, so write them down before you run it.
The one-way part is hand editing, and Expo is blunt about it. If you modify the generated directories manually then you risk losing your changes the next time you run prebuild with the clean option. For a project that already manages its native code by hand, the documentation says not to run prebuild at all, because it may overwrite those customizations. So the commitment is not the command itself. It is the first manual change inside ios or android, after which somebody has to decide whether the config or the native directories are the source of truth. That decision is the real fork, and it is worth making deliberately rather than discovering it in a merge conflict.
Expo documentation, prebuild side effects and the clean option, read 16 October 2026
How do you hand the app and the listing to someone else?
The code is the easy half. Add the person to the repository and they have the history. The listing is the half with rules on it, and Apple publishes them as app transfer criteria. The one that catches builder users first: the app must have at least one version that was released to the App Store. An app that only ever went to TestFlight cannot be transferred, however willing both sides are. If the plan is to hand the whole thing over, ship it publicly before you start the paperwork.
The rest of the list is mostly timing. The app cannot sit in a state Apple is working on, which rules out Processing for Distribution, Waiting for Review, In Review, Accepted, Pending Developer Release and Pending Apple Release. It cannot currently be available for pre-order in any country or region. Both accounts have to be clear of any pending or changing state, and both parties must have accepted the latest version of their paid and free agreements. Apple Arcade apps cannot be transferred at all. Read the list on the day, because a week-old answer about your own app status is not one.
One condition is worth checking before anybody signs anything. In-App Purchase product IDs on the app cannot be the same as product IDs on any apps in the recipient's account. Agencies walk into this, because a studio shipping ten client apps that all use a product ID of pro_monthly can only ever receive one of them. Rename yours first. Apple also expects In-App Purchase products to be in a settled status rather than mid review.
Then the dull part that actually protects you, because the first release after a handover is the one that breaks. Agree how builds go out before anyone needs to ship urgently, and use a phased release so a bad build reaches a slice of your users rather than all of them. Agree who holds the signing identity, in writing, with a name on it. And be straight about the running cost: what it costs to publish an app does not fall to zero because somebody else is now doing the work. The developer programme fees and the tooling follow the app.
App Store Connect Help, app transfer criteria, read 16 October 2026
Five ways out, and what each one costs you
Four of these five need nobody's permission. Only the transfer involves another party, and only the republish throws away work you already paid for. Pick the cheapest row that solves the blocked task rather than the most final one.
| The route | Listing survives | Code history survives | Who has to agree |
|---|---|---|---|
| Add a developer to the repository | Yes | Yes | Nobody outside your team |
| Run prebuild and commit the native directories | Yes | Yes | Nobody, and Expo says you can stop at any time |
| Push the code to a repository you host | Yes | Only if you push the whole history | Nobody outside your team |
| Transfer the app to another Apple account | Yes | Yes | Both Account Holders, and the app must meet Apple's criteria |
| Publish again as a brand new app | No | Yes | Nobody, and every rating stays behind |
Transfer row conditions from App Store Connect Help, app transfer criteria, read 16 October 2026
Where this leaves a project a builder generated
Newly is an AI app builder. You describe an app in plain English and it writes a real React Native and Expo project you own, with two-way GitHub sync, so there is no export step and nothing to unlock later. It uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK. It is $25 a month and there is no free tier.
The thing it deliberately does not do is submit to the App Store on your behalf, and on this page that detail is the useful one. App Store Review Guideline 4.2.6 says apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content. So the developer account is yours from the first build, the listing is created under your name, and there is no transfer to arrange later because the app was never in somebody else's account. The expensive version of outgrowing a tool is the one where the listing belongs to the vendor.
The honest limit: owning the repository does not make the handover free. Somebody still has to read the code, learn the config, take the pager and own the next release. A generated project is not self-explanatory just because it is standard. What you avoid is the version of this story where the code sits inside a tool, the only export is a zip of screens, and the exit is a rewrite paid for twice.
Questions people ask when they outgrow a builder
When the next thing you need is a thing the builder has no way to express. The signals are specific and dull: a library with native code and no config plugin, a second person who needs branches and a readable history, a release you could not stage or roll back, a compliance question that only someone reading the code can answer. App size and revenue are not signals. An app that makes money has earned the right to be worked on, which is a different sentence from an app that has outgrown its tools.
Start in a repository you already own
The cheapest way to handle outgrowing a tool is to pick one you can walk away from on day one. Your own Git remote, your own developer account, your own listing. Then the handover is an invite rather than a negotiation.
Start building