Publishing Under Another Account

Apple

1. The client enrolls in the Apple Developer Program as an organization (needs a D-U-N-S number; allow 1–2 weeks).

2. The client invites our maintainer account to their team in App Store Connect, with the Admin role, or App Manager with Access to Certificates, Identifiers & Profiles.

3. In their team, create:

   • a team App Store Connect API key

   • an Apple Distribution certificate (.p12)

   • an APNs auth key (.p8) for their Firebase project

4. On the app branch, set DEVELOPMENT_TEAM in project.pbxproj to their team ID, and use bundle IDs registered in their team.

5. In the app's GitHub environment <client>.<app>, add environment secrets that override the repository ones: ASC_KEY_ID, ASC_ISSUER_ID, ASC_KEY_P8, IOS_DIST_CERT_P12_BASE64, IOS_DIST_CERT_PASSWORD. The Fastfile reads the team from the project, so nothing else changes.

6. The deep-link file apple-app-site-association must list <THEIR_TEAM_ID>.<bundle>.

Google Play

1. The client creates a Play Console developer account as an organization (D-U-N-S number and identity verification). A personal account would bring the "12 testers for 14 days" closed-test rule for new apps.

2. The client invites our maintainer account under Users and permissions, at least with the app permissions to manage releases and the store listing.

3. Create a Play service account in their Google Cloud project, or invite our shared github-actions-play service account into their Play Console. Either works. Inviting ours keeps one key, while theirs keeps them in control.

4. If the key is theirs, set PLAY_SERVICE_ACCOUNT_JSON as an environment secret on <client>.<app>.

5. The Android upload key can stay in our shared keystore, since the upload key is ours to choose with Play App Signing. If they require their own key, give the app its own ANDROID_KEYSTORE_BASE64/ANDROID_KEYSTORE_PASSWORD environment secrets.

Firebase

The Firebase project can live in their Google Cloud organization as well. Grant our CI and fcm-proxy service accounts the roles described in Setting Up a New App and Push proxy.

Apple: App Transfer

• In App Store Connect: App Information → Transfer App. The recipient's Account Holder accepts. Ratings and reviews move with it; TestFlight builds and testers don't.

• Requirements: at least one approved version, no pending version in review, and the recipient must have accepted the latest agreements. Some capabilities (for example App Groups and iCloud containers) block transfer.

• Afterwards: switch the app branch to their team (DEVELOPMENT_TEAM), register the App IDs' capabilities in their team, update the environment secrets as in option A, upload a new APNs key from their team to Firebase, and update apple-app-site-association.

• Test push on a device right after switching APNs keys.

Google Play: app transfer

• Use Play Console's app transfer flow (Help Center: "Transfer apps to a different developer account"). It needs details of both accounts; follow the current form.

• The app signing key moves with the app under Play App Signing. Users get updates seamlessly.

• Afterwards: invite our service account in the new account (or use theirs, as in option A), and check the assetlinks.json SHA-256, which stays the same because the signing key moves with the app.