When the sale of an app starts to become real, the thing that stops you cold usually isn't the price negotiation. It's the handover. App Store Connect has an official feature called app transfer, but if you don't know exactly what moves with the app and what doesn't, you can end up with push notifications silently dying under the new owner, or every user getting logged out after the first post-transfer update.
I run several apps as an indie developer. None of them are for sale right now, but I wanted to know what a handover would actually involve if that day ever came, so I sat down with Apple's official documentation and mapped it out. The result works equally well as a checklist for the other side of the table — the day you buy an app instead of selling one.
If your question is what an app is worth and where to list it, that's covered in Selling Your Rork App — How to Turn an EXIT into Real Revenue on Flippa and Acquire.com. This piece picks up where that one ends: the work waiting for you after the deal is agreed.
Can Your App Be Transferred at All?
Before anything else, check whether the app meets Apple's eligibility rules. The full list lives in App transfer criteria (Apple Developer); here are the ones most likely to matter for an indie developer.
| Requirement | Where people get caught |
|---|---|
| At least one version has been released on the App Store | An app still in development or review can't use this mechanism |
| The app isn't available for pre-order | You can't transfer mid pre-launch campaign |
| No version sits in a state like Waiting for Review, In Review, or Pending Developer Release | A pending submission blocks the transfer from starting |
| In-app purchase product IDs don't collide with any IDs in the recipient's account | Generic, reused product IDs are the classic trap |
| Both parties have accepted the latest paid and free agreements | An ignored agreement update stalls everything |
| The app isn't part of Apple Arcade | Arcade titles can't be transferred at all |
The in-app purchase rule deserves a closer look. If you have a habit of using generic product IDs like pro_upgrade across apps, the transfer fails the moment the buyer's account already contains the same ID. Since doing this exercise, I prefix every product ID with something unique to the app. Even for apps I never intend to sell, it's a small insurance policy that keeps future options open.
What Carries Over — Your Ratings and Reviews Survive
The single most important fact about app transfer: ratings and reviews move with the app. The listing never goes offline, and existing users keep receiving updates without doing anything. The Bundle ID moves too — it can't be changed anyway once a build has been uploaded.
| Carries over | Notes |
|---|---|
| Ratings and reviews | Retained during and after the transfer |
| Distribution to existing users | Downloads and updates continue uninterrupted |
| Bundle ID | Moves as-is; it was immutable to begin with |
| iCloud containers and key-value storage | Transfers together with the user data inside |
| Auto-renewable subscription base | Revenue starts flowing to the new owner |
| Sign in with Apple Service ID | Remove the association before transfer if you want to keep it |
| Webhook configuration | Delete before transfer if you don't want it handed over |
Seen from the buyer's side, this means you can purchase stars and reviews as an asset. Rebuilding the same rating from zero has a real cost, which is why an app with a healthy review history is often worth more than its code. From the seller's side, note the webhook line: forget to clean it up and the buyer's App Store events will keep arriving at your server long after the handover. Put it on the pre-transfer inventory list.
What Gets Rebuilt — Things You Delete Before, Things They Recreate After
Most of the infrastructure behind the app does not move. It helps to split this into two buckets: what the seller deletes before initiating, and what the buyer recreates afterwards.
| Item | Who handles it, and when |
|---|---|
| TestFlight builds and testers | Seller removes every build and tester before initiating, and clears the test information fields for each localization |
| Xcode Cloud data | Seller removes it before the transfer |
| APNs certificates and keys | Certificates stay valid until they expire (one year from issue); after that the buyer's team issues new credentials and updates the push servers |
| Apple Pay merchant ID | Doesn't transfer; the buyer creates a new one when submitting an update |
| Game Center groups and matchmaking | The app drops out of its group, and matchmaking rules must be recreated on the buyer's side |
| Featuring nominations | Not transferable; document them and hand the notes over directly |
Emptying TestFlight is more work than it sounds. If you run an external beta, you'll want to warn testers ahead of time, which turns this into a multi-day sequencing exercise. I've written up the full tester workflow in Beta Testing Your Rork App with TestFlight: from Internal Testers to Public Launch if you need the details to plan backwards from.
The Three Places Users Actually Feel It
The transfer itself is invisible to users. The first update shipped by the new owner is where things surface, in three specific places.
First, the keychain. Keychain sharing groups are prefixed with the team's Team ID, so the moment the buyer rebuilds the app under their team, tokens stored under the old group become unreadable. Apple's documentation is explicit that users must re-login once after the update. If your app requires an account, agree with the buyer on an in-app notice before that update ships.
Second, receipt validation for auto-renewable subscriptions. Before initiating the transfer, the seller generates an app-specific shared secret and hands it to the buyer, who uses it to keep server-side validation running. Once the transfer completes, the buyer regenerates the secret so the previous owner loses access. Hand over, switch over, then rotate — the order matters.
Third, Wallet passes. Passes that receive updates from your app or web service must be reissued under new identifiers after the transfer, and the old ones stop working. Apple recommends telling users inside the app that their existing pass will go inactive and pointing them to the new one.
If the app uses Sign in with Apple, there's an extra migration step: you generate a transfer identifier for each user in your database through Apple's REST endpoint, and the buyer maps those to user IDs under their team. Skip this and every "Sign in with Apple" user is orphaned — write it into the purchase agreement as an explicit work item.
With a Rork App, Half the Handover Lives Outside Apple
Everything so far sits inside Apple's world. But for an app built and operated with Rork, roughly half the assets you're handing over live somewhere else entirely.
| Asset | Practical point |
|---|---|
| The Rork project and generated code | Confirm up front whether the project can be reassigned and how the code exports |
| Expo / EAS configuration | Move build and update-delivery permissions by account or per project |
| Backend (workers, databases) | Hand over deploy rights along with a documented list of environment variables |
| AdMob and other ad IDs | There's no mechanism for moving an app between ad accounts, so the standard play is new IDs on the buyer's side plus an update that swaps them in |
| The privacy policy page | If it lives on your domain, cancelling that domain breaks the buyer's review compliance |
| The support email address | Have the buyer update the support contact shown on the App Store listing |
Ad IDs are the item most often overlooked relative to how directly they touch revenue. While the ID-swapping update is in review, ad income is still flowing somewhere — decide in the contract which side it belongs to, and the handover stays friendly.
The privacy policy's location matters for the same reason. If it sits under your personal domain, that page's survival becomes the lifeline of someone else's app after the sale. The review requirements themselves are covered in Privacy Policy Templates for Rork Apps: A Practical Guide for App Store Submission in 2026 — but planning for a possible handover has changed how I think about where that page should live in the first place.
Even If You Never Sell, Being Transferable Is an Asset
You don't need a buyer on the horizon for this checklist to be worth running. How you name product IDs, where your app leans on the keychain, where the policy page lives — these are all design decisions that get more expensive to change the longer you wait.
As a next step, pick one of your apps and walk it through the six criteria in the first table. It takes about 15 minutes, and it shows you precisely how far your app is from being ready to hand over. Thinking through the day you might let an app go has a way of tightening up the way you run it today — that was the quiet takeaway from this whole exercise. Thank you for reading along.