Why a checklist
Getting an app into the stores is rarely blocked by code. It is blocked by a missing privacy answer, a screenshot in the wrong size, or a reviewer who could not log in. None of it is difficult. All of it is easy to forget the week of launch.
This is the list we work through on every release.
1. Accounts and ownership
- Create the developer accounts in your company's name, not an agency's and not a founder's personal account. Whoever owns the account owns the app.
- Start early. Company verification on both platforms can take longer than you expect.
- Add your developers as team members rather than sharing a login.
2. The store listing
- App name, subtitle and short description — written for a person skimming search results
- Full description, with the first two lines carrying the point
- Screenshots for every required device size, showing the app in use rather than marketing slides
- An app icon that is legible at small sizes
- Category, age rating and content declarations
- A support URL and a privacy policy URL that actually load
3. Privacy and data
Both stores now ask you to declare what data the app collects and why.
- List every piece of data collected, including by third-party SDKs — analytics and crash reporting count
- Ask for permissions (camera, location, notifications) at the moment they are needed, with a clear reason, not all at once on first launch
- Make sure the app still works if a permission is refused
- If users can create an account, they must be able to delete it from inside the app
4. Technical checks
- Test the release build, not the development build, on real devices
- Test on an older, slower phone and on the smallest supported screen
- Check behaviour with no connection and with a poor one
- Confirm deep links, push notifications and in-app purchases work in the production configuration
- Remove test accounts, placeholder text and debug menus
- Bump the version and build numbers
5. What reviewers trip over
- They could not sign in. If the app needs an account, give the reviewer working demo credentials in the review notes.
- Something looked unfinished. Empty screens, "lorem ipsum" and broken links are common rejection reasons.
- Payments went around the store. Digital goods generally have to use the platform's own purchase system. Check the current rules for your category before you build the paywall.
- The description promised something the app does not do.
6. After approval
- Release to a small percentage of users first where the store allows a staged rollout
- Watch crash reports and reviews closely for the first days
- Keep a fix ready to submit — the second review is usually quicker than the first
One last thing
Allow time. Review is normally quick, but a rejection means fixing, resubmitting and waiting again. We plan store submission as its own milestone in every mobile app development project rather than something squeezed into launch day — and with React Native, one release process covers both stores.
Working on something like this? See how we approach mobile app development.