Publishing to Google Play

Publishing through Appsanic is rolling out. The one-click flow below is how it works: you connect your store account, click Publish, and Appsanic builds and uploads your app for you. While we finalise it, if it is not yet enabled on your account you can publish today by exporting your code and running EAS yourself. We will remove this note when the flow is live for everyone.

Google Play is generally faster and less theatrical than the App Store. Google's review typically clears in under 24 hours, sometimes a few hours, and the setup is more forgiving than Apple's. With Appsanic you connect your Google Play account once, then publish from the build top bar. Appsanic builds the release in the cloud and uploads it to your internal testing track for you. No Mac and no command line required.

Plan for 1-2 hours of paperwork the first time, mostly in the Play Console (the store listing, screenshots, data safety, and ratings). Publishing itself is a few clicks.

Publishing is a paid-plan capability, available on Pro and Business.

Before you start

• A Google Play Developer account: $25 USD one-time. Create one at play.google.com/console. Email verification and ID are required.
• A Google Cloud service-account key (a JSON file) so Appsanic can upload on your behalf. You create it across Play Console and Google Cloud (see Connect, below).
• An app icon (512×512 PNG, 32-bit with alpha) for the store listing. The launcher icon inside the app is separate: upload it on the Publish dialog's Your app step (a square PNG or JPEG, at least 1024×1024), or it falls back to your brand kit's app icon if the project uses one. Appsanic generates the Android adaptive icon (foreground + background) from it. A publish with no icon anywhere ships Expo's placeholder launcher icon - the dialog warns you first.
• Screenshots (see the store listing section).
• A privacy policy URL.
• A feature graphic (1024×500 PNG, required).

The Publish flow

Open your project and click Publish in the build top bar. The Publish dialog walks you through Connect, Your app, and Publish, then tracks the build on a live Status screen.

Connect

Add your Google Play account once using a revocable service-account key - never a password. The key is a JSON file that acts as a robot login, so Appsanic can upload builds for you, and you can delete it from Google's side at any time.

Two things to know before you start: the key is created in Google Cloud Console, but its access is granted in Google Play Console - two different websites, and the JSON is not downloadable from Play Console. And you must be the Play Console Owner or an Admin to grant the access.

In Google Cloud Console (console.cloud.google.com):

1. Pick or create a project at the top. Open IAM & Admin > Service Accounts and click Create service account. Give it a name like appsanic-publish and click through to Done (you can skip the optional role steps).
2. Open that service account, go to the Keys tab, then Add key > Create new key > JSON, and Create. A .json file downloads automatically. You can only download it once - save it somewhere safe and never put it in public code or Git.
3. Copy the service account's email (it ends in .iam.gserviceaccount.com) - you'll need it in a moment.
4. Search the top bar for Google Play Android Developer API, open it, and click Enable. (As of 2026 you do not need to "link" a Cloud project to your Play account - ignore older guides that mention a "Setup > API access" page; that step was removed.)

In Google Play Console (play.google.com/console):

1. Create your app's record if it doesn't exist yet: open All apps > Create app, enter the app name, pick your default language, choose App (not Game) and Free or Paid, tick the declarations, and click Create app. The record has to exist before you can grant the key access to it in the next step - and before any build can be uploaded.
2. Open Users and permissions > Invite new users and paste the service account email from step 3.
3. On the App permissions tab (not "Account permissions"), click Add app, pick your app, then tick both "View app information (read-only)" and "Release apps to testing tracks" - that pair is the minimum needed to upload to a testing track. Don't add production or tester-list permissions until you actually publish to production. Click Invite user.
4. Back in Appsanic's Connect step, upload that JSON file. Appsanic stores it securely and reads it when it uploads your build.

Permission changes can take a few minutes to take effect. If your very first publish reports a permissions error right after this, wait a little and try again. Also remember the one-time manual first upload described below - Google requires it for brand-new apps before any automated upload works.

Your app

Confirm the three values that define your app's identity:

• App name: what shows under the icon.
• Android package: the Android equivalent of a bundle ID, like com.yourname.yourappname (usually the same as your iOS bundle ID). Permanent once published.
• Version: the public version number, e.g. 1.0.0.

These map to expo.name, android.package, and expo.version in your project's app.json, but you set them here in the dialog. The step also holds your launcher icon: upload a square PNG or JPEG of at least 1024×1024, or let it fall back to your brand kit's app icon - the preview shows exactly what will ship.

Publish

Choose Google Play. Each publish targets one store, so to do iPhone as well you run a second publish for the App Store - the Connect and Your app steps are shared, so it's just another click. The dialog shows the exact credit cost before you confirm. Pricing is set server-side, so the dialog is always authoritative. As a rough guide, expect around 15 credits for Android and 30 for iPhone (both stores come to about 45 in total across the two publishes) - but trust the figure shown in the dialog over these.

Confirm to start.

What happens after you confirm

Appsanic builds the release in the cloud with EAS and uploads it for you - the .aab (the App Bundle format Google requires) goes straight to your Play internal testing track. A status screen shows progress as it moves through queued, building, submitting, and done. A build takes roughly 10-20 minutes.

First time only: for a brand-new app, Google requires the very first .aab to be uploaded by hand before its API will accept automated uploads - so expect your first publish's upload step to report exactly that. Appsanic surfaces the built .aab as a download on the build for this: open the build, click Download .aab, upload it in Play Console > Testing > Internal testing > Create release, and every publish after that is fully automatic.

Once the build lands in internal testing:

1. Install it on a real Android device from the internal testing opt-in link.
2. Confirm it doesn't crash on launch.
3. When you're happy, submit it for review and roll it out in Play Console (the store-console steps below).

Set your app's identity in detail

The same three values from the Your app step also live in app.json in your exported project, if you ever drive a build yourself:

• App name (expo.name).
• Android package (android.package) - permanent once published.
• Version (expo.version).

Complete the store listing

The store-console work is unchanged - it's still done in the Play Console, whichever way you publish.

Play Console > your app > Main store listing:

• App name: max 30 characters.
• Short description: max 80 characters. Shown above the fold on the product page.
• Full description: up to 4,000 characters. Indexed for search on Play (unlike Apple).
• App icon.
• Feature graphic (1024×500): shown at the top of your product page. Required.
• Screenshots: required for each device type. At least 2, up to 8. Sizes:

• Website URL.
• Support email.
• Privacy policy URL.

Content rating

Play Console > Policy > App content > Content rating. You answer a questionnaire about your app's content; Play generates an IARC rating (roughly analogous to Apple's age rating).

Data safety form

Play Console > Policy > App content > Data safety.

This is Google's equivalent of Apple's privacy nutrition labels. Declare:

• What data your app collects.
• How it's used.
• Whether it's shared with third parties.
• Whether data is encrypted in transit.
• Whether users can request deletion.

Play cross-checks the data safety form against the permissions declared in your manifest. Mismatches delay approval.

Target audience and ads

Play Console > Policy > App content > Target audience. Choose the age groups.

If your app has any ads, declare it in the Ads section. If you use AdMob through Appsanic, check yes.

Submit for review

Play Console > Production > Review and roll out release. Choose a rollout percentage (usually 100% for a first launch; smaller rollouts are common for updates).

Play reviews:

• First submissions: usually 1-3 days, sometimes same day.
• Updates: typically a few hours, sometimes up to 24.

Status appears in Play Console. You'll get email notifications on approval or rejection.

Common reasons for rejection

1. Metadata doesn't match the app. Your listing promises a feature the app doesn't have.
2. Permissions not justified. You requested a permission (e.g., location, contacts) with no clear reason.
3. Missing data safety declarations. Your manifest shows you access something you didn't declare.
4. Content policy. Adult content, spam, impersonation, misleading functionality, etc.
5. Payments in the wrong rail. Selling digital goods outside Play's billing. Use RevenueCat + Play Billing for digital goods.

Play's rejection emails are more detailed than Apple's. Read the specifics, fix, resubmit.

Internal testing (Play's TestFlight equivalent)

Publishing lands the build straight in the Internal testing track, so it's ready to try before you promote it to production:

1. Play Console > Testing > Internal testing > your release.
2. Add email addresses of testers (up to 100).
3. Share the opt-in link with testers.
4. They install from a special Play link.

Test on a real device with zero review time, then promote that same build to Production when you're happy.

Updates

For each new version:

1. Open the Publish dialog, go to the Your app step, and bump the version.
2. Publish again. Appsanic builds the new version (auto-incrementing the internal versionCode for you) and uploads it to internal testing.
3. In Play Console, promote the build to Production and roll out (often staged: 10%, then 50%, then 100%).

Play staged rollouts are more flexible than Apple's. You can pause or roll back immediately if you see crashes.

Over-the-Air Updates

For JavaScript-only and asset-only fixes - a copy change, a colour, a small bug - EAS Update can push the change over the air with no store re-review. Honest status: OTA through Appsanic isn't available yet - it's on the roadmap. Today the path is to export your code, set up expo-updates once in your repo, and run eas update (and eas update:rollback to revert) from there. See Over-the-Air Updates for what does and doesn't qualify and the setup steps.

Prefer to drive it yourself?

You can always export your code to GitHub and run EAS yourself from your own repo. After cloning, from the project root:

npm install -g eas-cli
eas login
eas build --platform android --profile production
eas submit --platform android

eas build builds the .aab in Expo's cloud and eas submit uploads it to your Play internal testing track using the service-account key from Connect. This is the same toolchain Appsanic runs for you behind the Publish button. (For JavaScript-only fixes, the same repo can push over-the-air updates once you set up expo-updates - see Over-the-Air Updates.)

Under the hood (for engineers)

• The key is a robot login. The Google Cloud service-account JSON authenticates uploads to the Play Developer API. It's revocable from Google's side and scoped to the testing-track permissions you granted, so it can't touch production until you explicitly add that permission.
• .aab, not .apk. Play requires the Android App Bundle format. EAS builds it 64-bit by default.
• versionCode is handled for you. With EAS's remote appVersionSource, the internal build number auto-increments on every build, so you won't hit Google's "version code already used" rejection. (If you build outside EAS, remember it must always increase.)
• App signing. Play manages your app signing key (Play App Signing). You don't manage the key yourself, and EAS uses this by default.
• Ads disclosure. Even one banner ad triggers the Ads-in-app declaration in Play's App content section. Don't forget it.

Next

You're on both stores. Read Plans and Billing to understand what you're paying us for, or Troubleshooting for what to do when things go sideways.