App handover checklist: the code, accounts and data you should own when the build ends

Why I plan the handover on day one

A handover is easy when there is nothing to move. That is the whole trick.

I ask clients to open every account first, in the company's name, and invite me: store accounts, server, database, domain, email and SMS providers. At the end, handover means two things. I give you the last pieces that only exist on my machine, and you remove my access.

The opposite pattern is common. The developer creates everything under their own logins to save time, and the app quietly becomes theirs. If you have not opened your store accounts yet, my guide to setting up Apple and Google developer accounts for a UAE company covers the paperwork. Who owns the code itself is set by your contract. I am not a lawyer and this is not legal advice, so have the ownership clause read before you sign.

The checklist I go through at handover

Go through this list with your developer, and tick each line only when you have logged in yourself. Seeing a screenshot does not count.

Android signing keys: the line people skip

Android apps are signed before users get them. Keys matter.

Google's Play App Signing splits this into two keys. Google holds the app signing key, which signs what users download. You hold the upload key, which signs the bundle you upload. New apps are enrolled by default. If the upload key is lost, you are not locked out: the account can request an upload key reset from the Play app signing page. A signing key you manage yourself, outside Play App Signing, cannot be reset if lost.

So I hand over the upload keystore file, its passwords and the key alias, and I check the app shows Play App Signing as active. On iOS I create the signing certificates inside your developer account, never mine, so nothing of mine needs retiring later.

When the app already lives in someone else's account

If your app was published under another developer's account, both stores can move it to yours, but each has conditions.

Apple calls this an app transfer. The current Account Holder starts it and the receiving Account Holder accepts it. The app keeps its bundle ID, ratings and reviews, and users keep getting updates. Sales data from before the transfer stays with the old account.

• Apple: at least one version released on the App Store, and nothing waiting for review, in review or pending release.
• Apple: both accounts have accepted the latest agreements, and no in-app purchase product ID clashes with one in your account.
• Apple: TestFlight builds and testers removed first.
• Google: both accounts active, with each account's registration transaction ID in the request.
• Google: the old account requests, the new owner approves, and support says it responds within two business days.
• Google: users, ratings, reviews, subscriptions and the listing move; earnings reports and test groups do not.

What handover looks like on my packages

The checklist is the same whatever you buy. The length changes. Launch ($999) connects to APIs you already have, so the handover is mostly the repository, the store accounts and the signing key. Growth ($1,699) adds your own Node.js backend and PostgreSQL database, which brings hosting, database access and backups onto the list. Scale ($2,500) adds a full admin dashboard, integrations and push notifications, so the third-party services row gets longer.

Hosting and third-party fees are not in the package price. You pay those providers directly, from your own accounts, which is the point. Then you remove my access. In App Store Connect an Account Holder or Admin deletes my user, which Apple says can take up to 10 minutes to apply. In Play Console you can set an expiry date on my access when you first invite me.