Connecting your Apple and Google accounts

There are four credentials, and they look alike two by two

Two traps come from that. The Play Console service account is not the Firebase one: one publishes the app, the other sends notifications, and both are similar-looking .json files. And the In-App Purchase key is not the App Store Connect key: Apple issues them separately, both are .p8 files with a BEGIN PRIVATE KEY block, and they are indistinguishable from the outside. That is why the platform checks the purchase key with Apple when you save it, instead of looking at its shape.

Google Play

1. Create the app in the console, with the exact identifier

In the Play Console, Create app. The package name has to be exactly the identifier the Mobile app tab shows (there is a copy button next to it).

Google's API does not create the app. If the package is not there, the submission fails with Package not found, and the package name cannot be renamed afterwards.

2. Create the service account

The service account is the robot user that submits versions. It is created in Google Cloud and authorised in the Play Console. Google no longer requires linking the Cloud project to the Play Console to use the API, so the path is direct:

1. in the Google Cloud Console, create (or pick) a project;
2. enable the Google Play Android Developer API in it;
3. under APIs & Services → Credentials → Create credentials → Service account, create the account. No role is needed here: the permission that matters is the Play Console one, in the next step;
4. on the account, Keys → Add key → Create new key → JSON. The file downloads immediately, and that is the file you upload to the platform.

Keep that .json like a password: whoever has the file can publish in your Play Console.

3. Grant the permission in the Play Console

This is the most frequently forgotten step, and the symptom misleads: the file is accepted here and the submission is refused there.

In the Play Console, Users and permissions → Invite new user, use the service account's e-mail (something like name@project.iam.gserviceaccount.com), add the app under the per-app permissions tab and tick:

• Release apps to testing tracks;
• Release to production, exclude devices, and use Play App Signing, if you are going to publish to production.

Invite. The service account shows up in the list like any other user.

4. The SHA-256 fingerprint (optional)

It only makes your website's links open inside the app. It is under Setup → App integrity → App signing. Use the one from the app signing key certificate, not the upload key: using the upload key is the classic mistake, the value looks right and link verification never passes.

Apple

1. The App Store Connect key

In App Store Connect, under Users and Access → Integrations → App Store Connect API → Team Keys, click Generate API Key. Name it and pick the role.

The role has to be Admin. App Manager cannot create the signing certificate, and that failure only shows up at the end of the build, after 20 minutes of compiling, in a message about a certificate that does not say "wrong role".

When you generate it, Apple lets you download the .p8 file once. If you lose it there is no recovery: revoke the key and generate another. From the same screen you get the other two fields: the Key ID (ten characters, on the key's row) and the Issuer ID (a UUID, written above the list, the same for all your keys).

Swapping Issuer ID for Key ID is the most common mistake, because both come from the same screen.

2. The Team ID

At developer.apple.com → Membership, top right, next to the team name. Ten characters. Without it the build cannot authenticate to sign, and it fails in the cloud with an error about a certificate.

3. Keep the identifier

The same identifier from the Brand step. It is how Apple recognises that a new version is the same app, and it does not change after the first publication.

Android notifications: the two Firebase files

Android delivers notifications through Firebase Cloud Messaging, which requires a Firebase project of your own. Two different files from the same project, and they only work together:

Create the Android app inside the Firebase project with the same identifier as the app. If the two files come from different projects, sending the notification fails with a sender error that does not say so in those words.

iOS does not use Firebase. There, delivery goes through Apple with the credential the platform already creates in your account. Without these two files, push works on the iPhone and not on Android.

The In-App Purchase key

Only needed if you are going to sell a subscription or a purchase inside the app on iOS. Under Users and Access → Integrations → In-App Purchase, click Generate In-App Purchase Key. It also downloads once, and the required role is Account Holder or Admin.

The guide Selling subscriptions inside the app covers the rest of the path.

What the platform cannot verify for you

Connecting the account is half the work. The other half happens inside the store's console, and from outside there is no way to see whether it was done: whether the app exists in the Play Console, whether the service account got its permission, whether the key has the Admin role.

That is why the screen lists those requirements without blocking the button. It would rather let you try and fail with a clear message than pretend it knows something it does not.

Official links

• Play Console: add users and manage permissions
• Google Play Developer API: getting started
• App Store Connect API: get started
• Apple: generate keys for In-App Purchases
• Expo: service account key for FCM V1