Switching app builders without losing your installs

By Abdalla Kamesh · Published October 1, 2026 · 5 min read

Most people asking this question are asking the wrong one. “How do I migrate my app?” assumes the app is a thing that moves. It is not — the app is a binary, and a new builder produces a new binary.

What actually matters is whether you can ship the new binary as an update to the existing listing, because the listing is where your reviews, your ranking history and your installed users live.

That is entirely a question of who owns the developer account.

The good case: the app is under your own accounts

If your current app was published under your Apple Developer account and your Google Play account, this is straightforward:

Your listing stays.
Your reviews and rating stay.
Your installed users get an update, not a new app to find and install.
Your app’s URL, its history and its search presence stay.

The new builder produces a build with the same bundle identifier, you upload it as a new version to the same app record, and it goes through review as an update. Your customers open the app one day and it is different.

This is one of the practical reasons to insist on your own developer accounts from the beginning — beyond the fact that Apple’s Guideline 4.2.6 effectively requires it.

The hard case: the app is under the vendor’s account

If your current app lives in a vendor’s account, you have three options and none of them is free.

1. Request an app transfer. Both platforms support transferring an app between accounts, with conditions. This is the outcome you want — it preserves the listing, the reviews and the installed base. It requires your vendor’s active cooperation, and it is a process rather than a button. Ask early and get a commitment in writing.

2. Publish a new app and migrate customers. You keep nothing: new listing, zero reviews, and every existing user has to find and install a different app. You would communicate it by email and push from the old app while you still can. This is a genuine setback, and it is worth paying to avoid.

3. Stay. Sometimes the honest answer. If the transfer is refused and a fresh listing would cost you more than the vendor’s shortcomings, staying is rational.

Find out which case you are in before you evaluate anyone. It changes the cost of switching by a wide margin.

The bundle identifier question

Ask the new builder one specific thing: can you build with my existing bundle identifier?

The bundle id is the app’s identity to both platforms. Same id, uploaded to the same app record, in the same account = an update. Different id = a different app, no matter how identical it looks.

Any builder that requires its own naming scheme for bundle ids is a builder that cannot update your existing app. That is a disqualifying answer if you have an install base worth keeping.

What does not transfer, whatever happens

Be clear-eyed about this list, because it is where the actual work is:

Your design. Themes, layouts, banners — you rebuild these in the new tool. A few hours, not a project.
Push notification subscriptions. Notification tokens are tied to the app’s push configuration. Depending on how both vendors are set up, some or all of your opted-in audience may need to grant permission again on the new build. Ask both vendors about this explicitly — it is the most valuable thing you own and the least discussed part of a switch.
In-app analytics history. Your new tool starts from zero. Export what you can from the old one first.
Vendor-specific configuration. Segments, campaign history, saved audiences.

What does transfer, because it never belonged to the vendor: your store. Products, orders, customers, prices, stock — all of that is in WooCommerce, and any competent builder connects to it in minutes. The catalog is not a migration problem.

The order of operations

Establish who owns the accounts. Look at App Store Connect and Play Console yourself; do not take a sales answer.
If the vendor owns them, request a transfer in writing before you commit to anything else.
Ask the new builder about your bundle identifier.
Ask both vendors about push subscriptions surviving the change.
Export your analytics history from the old tool.
Build and test on the new tool — connect your real store, check your three weirdest products, verify a variable product’s swatches and stock. A trial is enough for all of this. The buyer’s checklist.
Ship it as an update, at a quiet time. Not before a campaign, not on a Friday.
Watch reviews for a week. A visual change to an app people use daily gets commented on, and replying well is cheap.
Keep the old subscription running until the new build is live and stable. Overlapping a month is worth it.
Then cancel, and read the cancellation terms first.

Step 10 has a trap. At least one vendor in this category describes deactivating the app if the subscription lapses. If that is your current vendor, cancelling before the new build is live and adopted could switch off your customers’ app. Sequence carefully.

What to tell your customers

Very little, and only after it is live. A store app’s users do not need a change log. If the redesign is significant, one push notification the day after — “the app got a refresh; tap to see” — is enough, and it earns you a session.

What they do need is for nothing to break: same login, same order history, same addresses. Since all three live in your WooCommerce store rather than in the app, they survive the switch — which is worth verifying on day one with a real customer account.

The uncomfortable conclusion

The cost of switching builders is almost entirely determined by a decision made when you picked the first one. If your app is under your own accounts with your own bundle id, switching is an afternoon plus a review cycle. If it is not, switching may mean starting your listing over.

Which is the argument for insisting on your own accounts even when a vendor offers to take the work off your hands: it is not about this year’s convenience, it is about next year’s options.

Related reading