AppForShareCreate a free account

Upload the .aab you already have. Testers get an APK.

Free and up, own signing key on Pro and Team

A phone cannot install an Android App Bundle. Until now that meant a second build just for testers, or a trip through Google Play internal testing. Now you upload the .aab and AppForShare turns it into one universal APK with Google's bundletool, ready to install from the link and the QR code.

The APK is signed with a test key we make for your account, so every test build updates the one before it. On Pro and Team you can add a keystore of your own instead, so the APKs carry the same signature as the other builds you sign with it.

Example

app-release.aab

  • Turned intoUniversal APK, 38 MB
  • Signed withYour account key
  • Store readinessReady
  • Install linkappforshare.io/i/...

Made for

  • Flutter and React Native teams whose release build is flutter build appbundle or ./gradlew bundleRelease
  • CI pipelines that only produce the .aab for Google Play
  • Agencies that receive an .aab from a client and need it on a tester's phone today

What it ends

  • Keeping a second assembleRelease build only for testers
  • Running bundletool by hand and passing the APK around
  • Waiting for Play internal testing just to try a fix

How it works

  1. Step 1

    Sign in and upload the .aab

    Drop it on the dashboard, or send it from the CLI, GitHub Action, Fastlane or the MCP server. A free account is enough.

  2. Step 2

    We make the APK

    bundletool builds one universal APK from the bundle and signs it with your account's key. The app name, version, icon and store readiness check work as for any APK.

  3. Step 3

    Testers install it

    They open the link or scan the QR code on the phone. The install page tells them when to uninstall the Play version first.

Which key signs the APK

The test key: made for your workspace on its first .aab upload and kept encrypted with Google Cloud KMS. Builds signed with it update each other on a tester's phone, but Android will not install them over the app from Google Play, because the key is different. Testers who have the Play version uninstall it first.

Your own key (Pro and Team): an Admin adds a keystore with its alias and passwords in Settings. We check it opens and holds a signing key, encrypt it with Google Cloud KMS and never show it again. APKs made with it update any build signed with the same key. Remove it at any time and new uploads go back to the test key.

About the Google Play version: most apps use Play App Signing, where Google signs what Play installs with a key only Google holds. An APK signed with your upload key is then still a different signer, so testers uninstall the Play version first either way. Only if you hold the key your Play app is signed with (your app signing key) does the APK install over it.

What testers get

One universal APK that carries every screen density, language and CPU type from the bundle, so it runs on any supported phone. It is larger than the split APKs Google Play sends to a single device. The .aab itself is not kept after the APK is made.

Good to know

Questions

Is my upload keystore safe with you?
It is encrypted with a key held in Google Cloud KMS, opened only to sign APKs made from your own .aab uploads, never shown again, and deleted at once when you remove it. If you prefer not to share it, keep using the test key.
Why does the APK not install over my Play app?
Android only updates an app signed with the same key. With Play App Signing, Google signs Play installs with its own key, so a test APK needs the Play version uninstalled first, whether it is signed with the test key or your upload key. Only your app signing key, if you hold it, avoids that.
Does it work from CI?
Yes. The CLI, GitHub Action, Fastlane plugin and the MCP server upload an .aab the same way as an .apk.

Read next

Try it on your own app

Free account in a minute. Pro starts with a 7 day free trial.

More features