Finishing development feels like the finish line, but there is one more gate before real users can download your app: store review. Apple and Google both check apps before publishing them, and both expect a fair amount of paperwork alongside the build. Preparing it calmly, well before launch day, is the difference between a smooth release and a week of back-and-forth emails.
Start with the accounts, not the app
Developer accounts take time to set up, especially for companies. Both stores may ask for verification of your organisation, and Apple often requires a D-U-N-S number for business accounts. Open these accounts early, and make sure they are owned by your business rather than by an individual developer or agency. You want the keys to your own storefront.
Decide who on your team will have admin access and who only needs to upload builds or view reports. Both consoles support roles, so nobody needs to share passwords.
Build the store listing in parallel
Reviewers and users both judge your app partly by its listing. Prepare these assets while development is still running:
- App name and subtitle or short description
- A full description written for people, not search engines
- Screenshots for each required device size, showing real screens
- An app icon that meets each store's size and shape rules
- A privacy policy hosted on a public web page
- A support URL or contact email that actually gets answered
- Category, age rating questionnaire answers and keywords where relevant
Screenshots must reflect what the app genuinely does. Mock-ups of features that are not in the build are a common reason for pushback.
Get the privacy paperwork right
Both stores now ask you to declare what data your app collects and why. Apple calls this the privacy nutrition label; Google Play calls it the Data safety section. Before filling them in, list every SDK in your app, including analytics, crash reporting, advertising and login providers, and check what each one collects. Your declaration must cover third-party code too, not just your own.
If your app asks for permissions such as camera, location or contacts, write clear purpose strings explaining why. A vague line like "needed for app functionality" is far weaker than "used to scan the barcode on your delivery note".
Give reviewers a way in
If any part of your app sits behind a login, reviewers need working credentials. Create a dedicated demo account with realistic sample data, and put the details in the review notes. If the app depends on hardware, a location or a business relationship the reviewer cannot reproduce, explain it plainly and consider a short screen recording.
Check that the demo account will still work on the day of review. Expired passwords and wiped test databases cause more rejections than you would expect.
Test the release build, not the debug build
The version you submit should be the one you have actually tested. Before uploading, run through this list:
- Install the signed release build on real phones, old and new
- Test sign-up, login, password reset and logout
- Try every in-app purchase or subscription in the sandbox environment
- Turn off Wi-Fi and see how the app behaves without a connection
- Remove placeholder text, test buttons and links to unfinished screens
- Confirm account deletion works if users can create accounts
Use the stores' own testing tracks too. TestFlight on iOS and internal or closed testing on Google Play let your team and a few friendly users try the exact build that will go live.
Plan the release timing
Review times vary, so do not schedule a launch event for the morning after you submit. Both stores let you hold an approved build and release it manually, which gives you control over the date. For updates, consider a phased or staged rollout so a small share of users get the new version first.
FAQ
Do Apple and Google review apps in the same way?
No. Apple's review tends to involve more human checking of design and behaviour, while Google relies heavily on automated checks plus policy enforcement. Prepare for the stricter of the two and you will usually satisfy both.
Can I submit while the backend is still changing?
You can, but the reviewer must see a stable app. If your server goes down or an API changes during review, the app may be rejected for crashing. Freeze the backend for the review window.
Who should own the developer accounts?
Your business should. An agency can be invited with the right role, but ownership should stay with you so you never lose access to your app or its reviews.
Next step
Store submission is part of every mobile app project we deliver, from listings to review notes. If your launch is coming up and you want a second pair of eyes, get in touch with Export Apps.