I was picking an in-app purchase product ID for a new app one evening when I stopped typing. Should this ID live in my individual account, when I might move to an organization later?
The short answer is that you can move an app. It just isn't "any time, as-is." The app has to be in a certain state, and several features need to be cleared before you start.
As an indie developer who has kept several apps running for years, I had assumed the account type was something I could sort out later. That evening I came close to paying for the assumption. What follows comes from reading Apple's pages one by one. An app built in Rork ends up in your own Apple account too, so the same question reaches you sooner or later.
The conditions sit on the app and on both accounts
These come from Apple's app transfer criteria. I've listed the ones people hit first.
| Condition (paraphrased) | Where people trip |
|---|---|
| Both accounts have accepted the latest paid and free app agreements | The new organization account exists, but one agreement is still unaccepted |
| The app has at least one version released to the App Store | Trying to move it before the first review passes |
| The app is not in a status such as Waiting for Review, In Review or Pending Developer Release | Starting the transfer right after submitting an update |
| The app is not available for pre-order anywhere | A pre-order was opened early for a new release |
| In-app purchase product IDs don't match any on the recipient's apps | A test app reuses the same product ID |
The last row was the one that made my stomach drop. If you treat product IDs as something to tidy later, the transfer stops there.
I also found no page that describes switching an account's type from individual to organization. So everything below assumes you move the app to another account.
Five things to clear before you start
Apple's transfer overview lists notes per feature. These five are the ones that create real work for an app with purchases, notifications and sign-in.
1. TestFlight. Apple says to turn TestFlight off for all beta versions before you begin. Remove builds and testers, and clear the test information for every localization.
2. The shared secret for auto-renewable subscriptions. The app must use an app-specific shared secret. Generate one before you start, and generate another after the recipient accepts, so people outside the new owner lose access to the old one.
3. Sign in with Apple. You need to generate a transfer identifier for each user. If the app is grouped with others, ungroup it first.
4. Push notifications and keychain sharing. The recipient's APNs certificates stay valid until they expire, after which a new certificate or key is needed. Keychain sharing keeps working only until the app is updated, and users log in once more.
5. iCloud (CloudKit) and Apple Pay. The CloudKit container moves to the recipient. If other apps share that container, those apps lose the ability to read and write it. The Apple Pay merchant ID does not move with the app.
If you use Xcode Cloud, its data has to be removed first. And because the app leaves your account once the transfer completes, Apple advises backing up everything about it beforehand.
What carries over, and what doesn't
Reviews and ratings carry over, and so does the Bundle ID. The app can stay available for download during the move, so users keep receiving updates.
The Bundle ID, though, cannot be changed once a build has been uploaded. I wrote about that in why to fix your app ID before the first release, and transfer is the sequel to it.
What does not carry over includes the Apple Pay merchant ID, Game Center matchmaking configuration and Wallet pass identifiers. For an app that only has purchases and sign-in, the weight falls on items 2 and 3.
Where I draw the line between starting solo and starting as an organization
With an individual enrollment, the seller name on the App Store is your own name. With an organization, it is the organization's name. But an organization needs a D-U-N-S number, a legal entity that can enter into contracts, and a public, working website. DBAs and trade names are not accepted, as the enrollment page states.
So if you can live with your legal name as the seller, starting as an individual is fine. If you already know a team will run the app, or you want clients to see an organization name, an organization account is easier from day one. The enrollment steps themselves are covered in the Apple-side steps you do yourself.
Being able to move an app and it being light to move are different things. The transfer happens once, but the clearing work adds up with every feature you've turned on.
One thing to do next
In App Store Connect, write down for each of your apps which of these it uses: TestFlight, purchases, Sign in with Apple, push notifications, iCloud. Five lines are enough.
The emptier that sheet is, the lighter moving day will be. I'd like to fill in those five lines first for every new app from now on.