Short answer
To publish an MIT App Inventor app on Google Play, back up your keystore, set VersionCode and VersionName on Screen1, build an Android App Bundle and upload it to a closed testing track. New personal accounts then need at least 12 testers opted in for 14 days in a row before applying for production.
To publish an MIT App Inventor app on Google Play with a new personal developer account, build an Android App Bundle (.aab) in App Inventor, upload it to a closed testing track in Play Console, and keep at least 12 testers opted in for 14 days in a row before you apply for production. Before any of that, export a backup of your App Inventor keystore.
App Inventor makes building the app easy, but the Play side is the same for everyone, and a few App Inventor details trip people up: the keystore, the version code and signing errors on upload. Here's the whole path in order.
Step 1: back up your App Inventor keystore first
MIT's publishing page explains that every build is signed with a private key associated with your App Inventor account, and the same key signs every new version. The App Inventor server creates and stores it for you, so most people never think about it.
Export it anyway. In the designer, the Projects menu has an Export Keystore option. Save the file somewhere safe, outside your computer too. MIT is blunt about this: if the keystore is lost or deleted, neither you nor MIT can recover it. Without it, you may not be able to ship updates under the same signing key.
While you're there, also export your project as an .aia file from My Projects. It's your source code backup.
Step 2: set VersionCode and VersionName on Screen1
Every app on Google Play needs a version code and a version name. In App Inventor you set both in the Properties panel of Screen1. VersionCode is a whole number that starts at 1. VersionName is the label users see, such as 1.0.
Raise VersionCode by one every time you upload a new build, including builds for your closed test. If you forget, Play Console rejects the upload because that version code has already been used.
Step 3: build an AAB, not an APK
Google Play requires new apps to be uploaded as Android App Bundles, so choose the Android App Bundle (.aab) option when you build in App Inventor, not the .apk option. The APK is still handy for installing on your own phone.
Older guides, including MIT's own publishing page, only describe building an APK, which is why so many App Inventor users get confused at this step.
Fixing App Inventor signing errors on upload
The most common upload problems in App Inventor's community forum are key errors, such as "Your Android App Bundle was signed with the wrong key" or "Use a valid app signing key to continue". They usually mean the bundle was signed with a different keystore than the one Play Console expects.
For a brand-new app that has never been published, community volunteers report a fix that often works: export and back up the current keystore, delete the keystore in App Inventor, reload the browser, build the AAB again so a new keystore is generated, and upload that. For an app that's already live, don't delete anything. You need the original keystore, so restore it with Import Keystore. These are community fixes, not official MIT instructions, so keep your backup before trying them.
Step 4: set up the closed test and your 12 testers
In Play Console, create your app, fill in the store listing and the required forms such as Data safety and content rating, then go to closed testing, create a track and upload your AAB. Add your testers by email list or Google Group, and share the opt-in link with them.
Google's rule for personal accounts created after November 13, 2023 is at least 12 testers opted in to your closed test for the last 14 days continuously. The clock only counts days when 12 or more are opted in, so aim for 15 to 20 testers in case someone drops out.
Opting in is the requirement, but Google also asks about tester engagement when you apply for production. Testers who actually open the app and send feedback give you better answers for that form. App Inventor forum users have quoted refusals saying testers were not engaged, followed by a request for another 14 days of testing.
Step 5: apply for production
When 14 days are done, apply for production access from the Dashboard. Google asks about your test, what feedback you got and how you fixed it. If you shipped fixes during the test, mention them, and remember the higher VersionCode on each build.
If you don't have 12 people who will stay for 14 days, PeerPlay is a free way to swap tests with other Android developers, and testers open your app daily from the app so each test day is recorded. Paid VIP packages are there if you'd rather skip the swaps.
Top comments (1)
Really useful walkthrough, especially putting the keystore export first. Here at TestMyApps we see App Inventor builds hit a few extra snags during the closed test itself, so a few additions:
Accept Play App Signing when Play Console offers it on the first upload. Google then holds the app signing key and your App Inventor keystore becomes the upload key. If that keystore is ever lost, an upload key can be reset through Play Console support, which is far less painful than losing the only signing key.
Plan at least one update during the 14 days. Every new AAB needs a higher VersionCode on Screen1, and a new build goes through review before testers get it, so ship it early in the window rather than on day 13.
Test the opt-in link on a phone that isn't yours. App Inventor apps often ask for permissions like location or storage at startup, and if a tester gets stuck on that screen they quietly stop opening the app. Engagement is exactly what Google asks about later.
Keep a short dated log of what testers reported and what you changed. The production access form asks about that, and real examples make the answers easy to write.
And if someone drops out, add the replacement the same day. The window only counts while 12 or more stay opted in, so waiting costs you days.