Can Adalo update an app built on another platform?

The intended outcome

A go-or-no-go migration plan that protects the existing store listing and separates store continuity from the work of rebuilding the app and moving its data.

Requirements

• Owner or admin access to the current Apple and Google developer accounts
• The live iOS Bundle ID and Android package name
• The current Android version code and app-signing details
• A list of user accounts, data, files, purchases, notifications, deep links, and integrations that must continue working
• A named owner for the migration, testing, store releases, and launch support
• Written confirmation from Adalo Support for the store replacement path

What still needs checking?

• The source thread is still unresolved, so the first action is to confirm the existing store identifiers and ask Adalo Support before committing to a rebuild.
• Google requires the same package name and signing identity for an Android update, plus a higher version code.
• Apple does not let a published app change its Bundle ID; the new build must match the existing App Store Connect record.

The short version

You may be able to keep the same App Store and Google Play listings, but you cannot treat the old project as an Adalo file. The safe plan is: confirm the identifiers, get Support approval, rebuild, move the data, and test a real store update.

What can stay the same

If the store accepts the new build as the same app, the public listing, reviews, download link, and update path can stay in place. Existing users receive an update instead of finding a second app.

That continuity depends on permanent identifiers and signing rules. It is not created by reusing the app name or icon.

What does not move automatically

The old screens, code, user accounts, records, uploaded files, subscriptions, analytics, push setup, and third-party integrations do not move just because the store listing stays the same. Inventory each part and give it a migration or reconnection plan.

When a migration partner makes sense

For a small app with a simple database, the owner may be able to rebuild and test the move directly. Larger apps need someone to coordinate the Adalo rebuild, data mapping, account continuity, integrations, store credentials, test groups, launch timing, and rollback plan.

A bridge company such as Rehost can own that wider migration and work with Adalo Support on the store-specific parts. This is optional, not an Adalo requirement, but it can reduce the risk of treating a live-app replacement like a simple republish.

Android has a Support checkpoint

Google requires the same package name, a higher version code, and the accepted signing identity. Adalo's current publishing guide says a maker whose first Adalo build will update an app created on another platform should contact Adalo Support for help.

Do that before the rebuild becomes expensive. Share the Play listing, package name, current version code, and Play App Signing details so Support can tell you what path is available.

iOS has a permanent Bundle ID

Apple says a published app's Bundle ID cannot be changed. Adalo's iOS build form also asks for the Bundle ID and the Apple account that owns the app.

Adalo's current setup guide states a specific Bundle ID format for successful TestFlight builds. If the live app uses a different permanent ID, pause and ask Support whether it is compatible before rebuilding.

The safest order

Confirm store feasibility first. Then rebuild the smallest complete journey, connect or migrate real data, and send store-based test builds. Only schedule the public replacement after both platforms install the new build as an update and the critical user paths pass.

Common failure modes

Screenshot evidence

These captures document what Adalo currently publishes and what builders are reporting. They support the written guidance, but they are not a substitute for an end-to-end test in your own app.