We publish apps to the Play Store and App Store for our own products — Spices Info, Plog, Hangman Hero and others — and for clients. The code is rarely what delays a launch. What delays it is a missing privacy URL, a screenshot in the wrong size, or a developer account that takes a week to verify.
This is the checklist we run for every first release. Store rules change often, so treat it as a map and check each console for the current requirement before you submit.
1. Set up the accounts early — in the right name
Create the developer accounts before development finishes, not after. Verification can take days.
- Google Play Console. A one-time registration fee. Decide whether the account is personal or an organisation: for a business, register as an organisation so the listing shows your company name, and have your D-U-N-S number and business documents ready.
- Apple Developer Program. An annual membership. Organisations also need a D-U-N-S number, and the legal entity name must match exactly.
Register the accounts in the client's name, not the agency's. The app is a business asset; it should live in the business's account from day one.
2. Plan the testing track
Google requires newer personal developer accounts to run a closed test with a minimum number of opted-in testers for a continuous period before production access is granted. Organisation accounts have fewer hurdles, but a closed test is good practice either way.
On iOS, TestFlight handles internal and external testing. External testers require a lightweight beta review.
Our rule: at least a week of real use by people outside the team before the public release. It's where you find the login bug that only happens on one phone brand.
3. Privacy and data forms
Both stores ask you to declare what data the app collects and why. Do this carefully; mistakes can get an update rejected months later.
- Privacy policy URL hosted on your website, specific to the app.
- Google Play Data safety form and Apple's App Privacy details — list every data type, including what your analytics and crash-reporting SDKs collect.
- Account deletion. If users can create an account, both stores require a way to delete it — from inside the app, and on Google Play also via a web link.
- Permissions. Ask only for what you use, when you use it, with a clear reason on screen.
4. The store listing
The listing is marketing. Treat it with the same care as a landing page.
| Item | What we prepare |
|---|---|
| App name | Short, searchable, matches the brand |
| Short description | One line on the benefit (Play Store) |
| Full description | Features in plain language, no keyword stuffing |
| Screenshots | Phone sizes for both stores; tablet if supported |
| Feature graphic | Required on Google Play |
| App icon | Tested on light and dark backgrounds |
| Category and contact | Correct category, support email, website |
Write screenshots as a story: the first two images should explain what the app does without the description. Localise the listing if your users search in Tamil, Hindi or another language.
5. Technical checks before you build the release
- Target API level. Google Play requires new apps and updates to target a recent Android API level. Check the current requirement before your release build.
- Signing. Use Play App Signing and store the upload key safely — losing it is painful.
- Version numbers. Build numbers must always increase. Decide the scheme on day one.
- App size and performance. Test on a mid-range Android phone on a slow network, not only on the latest flagship.
- Crash reporting and analytics configured for the release build, with consent where needed.
6. Review: what gets apps rejected
Most rejections we've seen fall into a handful of buckets:
- A login wall with no demo account provided to the reviewer.
- Placeholder content or broken links in the app.
- Permissions requested without a clear purpose.
- Missing account deletion.
- Payments for digital goods outside the store's billing system where the rules require in-app purchase.
Give reviewers a working demo account and short notes on how to reach key features. It saves days.
7. Launch day and after
- Roll out gradually on Google Play (staged rollout) and watch crash rates before going to 100%.
- Reply to early reviews — quickly and politely.
- Schedule the first update within a few weeks. Your first real users will find things your testers didn't.
A realistic timeline
| Week | What happens |
|---|---|
| Before build ends | Developer accounts created and verified in the business's name |
| Week 1 | Internal testing, privacy policy published, data forms drafted |
| Week 2 | Closed testing with real users; listing copy and screenshots prepared |
| Week 3 | Fixes from testing, reviewer notes, submission to both stores |
| Launch | Staged rollout, crash monitoring, first replies to reviews |
Review times vary from hours to days, and a rejection adds a round trip. Leave slack before any launch date you've announced.
The short version
- Accounts in the business's name, created early.
- A real testing period with real users.
- Privacy policy, data forms and account deletion done properly.
- A listing that explains the app in two screenshots.
- A reviewer demo account.
We handle all of this as part of our mobile apps and Shopify Store Studio projects. If you have an app that's built but not yet live, tell us where it's stuck.
Leave a Reply