Apple asks for two pieces of information and no receipts. The work is in what you have to take apart before it will let you start, and in the handful of things that quietly stop working afterwards.
Apple's transfer form asks for two things: the recipient's Apple Account and their Team ID. There is no payment receipt to hunt down and no reference number to find. Submit it, the other side accepts, and the app moves with its reviews, ratings, App ID and Bundle ID intact.
The difficulty sits on either side of that form. Apple maintains a list of conditions that make an app ineligible, several of which take real work to clear, and a second list of things that do not survive the move. One of them cannot be recovered afterwards by anybody.
If you are moving a product between companies you are probably moving both stores. The Google Play side is a different shape of problem, built around one number from an old payment receipt. This is the Apple half.
Check this before you promise anyone a date. Apple refuses the transfer outright if any of the following is true, and some take days to resolve.
Mac apps have an extra rule: a sandboxed Mac app sharing an Application Group Container Directory with other Mac apps cannot be transferred. If the app is Mac Catalyst and not a universal purchase, the iPad app goes first and the Mac app follows.
Three things, and the first takes the longest. None of them can be done after the request is submitted.
TestFlight has to be completely torn down: all builds removed, all testers removed, and every field under Test Information cleared for every localisation. Xcode Cloud data has to be deleted from the Xcode Cloud tab in Settings. And if the app sells auto-renewable subscriptions, generate an app-specific shared secret and hand it to the receiving Account Holder before you begin, so their servers can keep validating receipts through the changeover.
Back up everything you want a record of before starting, because the app leaves your account entirely. Metadata, pricing, availability dates, sales and download history. Nominations and app bundle history in particular cannot be retrieved afterwards.
App Information, then Additional Information, then Transfer App. You may be asked for a two-factor code. Apple then checks the eligibility criteria and only lets you continue if they all pass.
Enter the recipient Account Holder's Apple Account and their Team ID, accept the agreement, and request the transfer. It then sits waiting for the other side.
As long as the recipient takes, up to 60 days. Unlike Google, Apple does not review the request. There is no queue and no approval step. The app moves the moment the other side accepts.
If nobody accepts within 60 days the request lapses and you start again. Either side can cancel while it is still waiting, under Business, then Agreements, then App Transfers. Submitting the request closes any open App Review conversations, so finish those first.
The transfer itself rarely fails. What catches people is the collateral damage, most of which surfaces days later on the first update rather than on the day the app moves.
Once an app has been transferred, new promo codes cannot be generated for it again. Not by you, and not by the new owner either. Codes already issued keep working until they expire.
This is the only part of the process with no way back, and it sits in Apple's documentation rather than appearing as a warning anywhere in the transfer flow.
Apple will not move an app with beta testing still switched on, and turning it off means more than pausing it. Every build has to be removed, every tester removed, and every field under Test Information cleared.
Test Information is per localisation, so an app shipping in six languages has six sets of fields to empty, and missing one keeps the app ineligible.
If the app shares a CloudKit container with other apps on your account, those other apps lose the ability to read or write that container once the transfer lands.
The damage is to apps that are not moving. They keep running until their next update, then quietly stop reaching data they have always had.
Keychain sharing survives the transfer itself but not the next update, because the keychain group carries the old Team ID and the new build is signed by a different one.
The visible result is that every user is signed out at once, on an update that otherwise looks routine, with no explanation in the release notes.
Reviews, ratings, the App ID, the Bundle ID, iCloud and CloudKit containers, webhooks and the app-specific shared secret all move across. These do not:
APNs certificates are a halfway case. They stay valid until they expire, and only then does the recipient need to generate new ones, which makes this the failure that arrives months later with no obvious cause. Sign in with Apple needs transfer identifiers generated for every user before the move, and Wallet passes have to be reissued with new identifiers so they are signed by the recipient's certificates.
Google gates on paperwork, Apple gates on state. The two processes fail in opposite ways, which matters when you are running both at once.
Google asks for the registration transaction ID of both accounts, a number from a $25 payment made whenever each account was created, and an otherwise perfect request will bounce if that number still carries its prefix. Then a human reviews it within two business days. Apple asks for nothing historical, reviews nothing, and instead refuses to start until the app itself is in an acceptable state.
In practice the Apple side is more work and less waiting. Plan the teardown first, run both transfers in parallel, and expect the Play side to be the one still sitting in somebody's inbox.
