Practical experience of preparing a separate build for each store, and the mistakes that actually get apps rejected.
Publishing to one store is a known quantity. Publishing to three at once is a different problem, because each store imposes its own services for ads and payments, and because what one store accepts another may reject for reasons that have nothing to do with the quality of your app.
What follows is the distilled experience of shipping several apps to Google Play, Huawei AppGallery and Amazon Appstore.
Rule one: three projects, not one
The natural temptation is to build a single project with three flavours. In practice, keeping the projects separate is far calmer over time: each store requires different libraries, different ProGuard rules and sometimes different SDK versions, and merging them into one project makes every update to one a risk to the others.
Share the logic — the game or feature layer itself — and separate what belongs to the store: ads, payments, services.
Google Play: it's the deadlines that catch you
What trips developers up here isn't review rejection so much as time-based requirements:
- Target API level: Play raises the floor every year. Updating
targetSdkisn't optional; after the deadline you simply can't ship updates. - Billing library version: Google requires periodic upgrades to recent Play Billing versions, and method signatures change between major releases, so old code breaks.
- The AD_ID permission: if a previously published release carries the permission and your new build doesn't, Play may object. Check every active release, not just the latest one.
- The Data Safety form: it has to match what your app actually does. An inaccurate declaration is a common cause of suspension.
Huawei AppGallery: HMS integration isn't optional
The classic rejection here reads "HMS not integrated". It happens when you upload a build that depends on Google services, because modern Huawei devices don't ship with them at all.
What you actually need:
- Replace Google ads with HMS Ads and Play billing with HMS IAP.
- Place
agconnect-services.jsonat the correct path inside the module. - Add the HMS metadata entries to
AndroidManifest.xml. - Extend your ProGuard rules to protect HMS classes from obfuscation in release builds — a silent cause of crashes that only appear in the final build.
One more practical note: if your app relies on WebView, some engine versions on Huawei devices are less tolerant of modern CSS features. Test on a real device, not only an emulator.
Amazon Appstore: simpler, if you swap two layers
Amazon is usually the calmest of the three in review, but it mandates its own payment system (Amazon IAP) and disallows certain ad networks. In practice that means swapping the ad layer for a supported network and the payment layer for Amazon's API, leaving the rest of the app untouched.
A side benefit: your app runs on Fire tablets, a small market but a far less crowded one.
What is worth unifying across the three builds
- An abstraction layer for ads and payments: one interface in your code with three implementations behind it. This alone saves days on every update.
- A central test flag: a single variable that switches between test and production ad unit IDs. Forgetting to flip it back is a common route to a suspended account.
- One privacy policy published on the web: all three stores ask for a public URL that works.
- Store assets: screenshots, descriptions and icons at each store's dimensions, kept in one organised folder.
A practical publishing order
Start with Google Play because it's the strictest; if your app passes there you've solved most compliance problems. Then move to AppGallery, where the work concentrates on swapping services, and finish with Amazon, which usually needs the least change.
Expect review cycles from a few hours to a few days depending on the store and the season — never schedule anything that depends on approval landing on a specific day.
Written for the Store of Apps blog. Corrections and feedback: contact@storeofapps.com.