TL;DR: Shipping a mobile app is not finished when the code works. Apple and Google both review your app before anyone can download it, and each release after that goes through the same gate. Most delays come from a short list of predictable causes: developer accounts set up late or in the wrong name, privacy and data disclosures that do not match what the app actually does, payment flows that ignore store rules, missing demo access for reviewers, and apps that feel thin or templated. Plan the release as part of the build, not as a step after it, and budget for at least one rejection-and-resubmit cycle on a first launch.
Teams often treat "submit to the stores" as a single afternoon at the end of a project. In practice it is a small project of its own, with paperwork, policy decisions and a review queue you do not control. This guide is for founders and product owners who want to know what that process involves before their launch date depends on it.
Why the stores are a separate step from the build
On the web, you deploy and your users have the new version. On mobile, two companies sit between you and your users. Apple reviews every iOS submission, including updates. Google reviews Android submissions too, and new developer accounts face extra requirements before an app can go public.
That has three consequences for planning:
- Launch dates carry uncertainty you cannot engineer away. Review is often quick, but it is not guaranteed, and a rejection restarts the clock.
- Some product decisions are really policy decisions. How you charge, how users sign in, what data you collect and how users delete their accounts are all subject to store rules.
- Fixes are slower than on the web. A bug in a released mobile app stays on phones until a fix passes review and users update. That changes how carefully you release, which we come back to below.
If you are still choosing how to build the app, native vs cross-platform app development covers the technical side. The store process applies either way.
Set up the accounts early, in the right name
Before anything can be submitted, you need an Apple Developer Program membership and a Google Play developer account. Two things matter more than people expect.
Whose name the accounts are in. The account holder is the legal publisher of the app. If a freelancer or agency publishes under their own account, moving the app later is possible but tedious, and in the meantime they control your listing, your reviews and your release button. Register the accounts under your company and invite the development team as members with the access they need. We treat this as non-negotiable on client work, and it is one of the first items in software ownership and handover.
How long verification takes. Organization accounts require identity and business verification, which can take days and sometimes needs documents you have to dig up. Google also asks new personal accounts to run a closed test with real testers for a set period before the app can be published to everyone. Neither of these can be rushed at the end, so start them in the first weeks of the project.
The store listing is product work
The listing is what users see before they install, and reviewers check that it matches the app. Expect to prepare:
- An app name, subtitle and description that describe what the app actually does.
- Screenshots for the required device sizes, and optionally a preview video.
- A privacy policy URL and a support contact.
- An age rating questionnaire.
- Category, keywords and, if you sell anything, pricing and in-app product details.
Screenshots and copy are not decoration. They are the first thing a potential user evaluates, so they deserve the same thought as the onboarding flow. That connects directly to the distribution planning we describe in launching a software product.
Privacy disclosures have to match the app
Both stores ask you to declare what data your app collects, why, and whether it is linked to the user or used for tracking. Apple calls these privacy labels; Google has a data safety section. Reviewers and, increasingly, automated checks compare these declarations against what the app and its third-party libraries really do.
The common mistakes:
- Forgetting the libraries. Analytics, crash reporting, advertising and attribution tools all collect data. Your declaration has to cover them, not just your own code.
- Vague permission prompts. When the app asks for the microphone, camera, location or contacts, the explanation must say exactly why. An app like LectureNotes AI, which records lectures to summarize them, needs a clear and honest reason for microphone access, and it should ask at the moment it is needed rather than on first launch.
- No way to delete an account. If users can create an account in the app, the stores expect them to be able to start deleting it from inside the app too.
Getting this right is not only about passing review. It is also how you avoid surprising users, which matters most when the app handles anything personal.
Payments: know the rules before you design pricing
If your app sells digital goods or features used inside the app, such as subscriptions, premium tiers, credits or virtual items, the stores generally require you to use their in-app purchase systems, and they take a commission. Physical goods and real-world services, like a ride or a delivery, typically use your own payment provider instead. The exact rules on linking to outside payment pages have been changing by region because of regulation and court rulings, so check the current guidelines for your markets rather than relying on what another app did a year ago.
This affects your business model, not just your code:
- Price for the commission. If a subscription is sold in-app, your margin is lower than on the web.
- Keep entitlements consistent. A user who subscribes on the web and logs in on iPhone should get what they paid for, and the system that tracks that needs to be designed, not improvised.
- Games live inside these rules. For mobile games like Lumber Doge or Snatch A Hat, where a store of characters or collectible hats is part of the loop, every unlockable sold for money runs through the platform's in-app purchase system.
We go deeper on pricing structure in SaaS pricing and packaging and on game stores in in-game economy design.
Why apps get rejected, and how to avoid it
Most rejections fall into a handful of patterns.
Reviewers cannot get in
If your app needs a login, an invite code or a specific account type, give the reviewer a working demo account and clear notes. A reviewer stuck at a sign-in screen will reject the app rather than guess.
The app feels unfinished or thin
Placeholder text, broken links, features that say "coming soon", or an app that is little more than a website in a wrapper all invite rejection. The stores want an app to do something that justifies being an app.
It looks like a template
Apps that closely resemble many others, or that are lightly reskinned versions of a shared codebase, can be rejected as spam. This catches agencies that publish the same product for many clients under separate listings, so plan for one well-built listing or genuinely distinct apps.
User-generated content without safety tools
If users can post content or contact each other, the stores expect ways to report content, block users and moderate what appears. For an app like Covoisino, a ride-sharing app built to make hitchhiking safer with QR verification, safety features are the product, and they also happen to be what reviewers look for.
Sign-in and AI content rules
If you offer third-party social login, check what alternatives the store requires you to offer as well. If the app generates content with AI, as Lifemaxxing AI does with personalized plans, think about how the app handles inappropriate requests and how output is framed, especially around health or wellbeing. We cover the engineering side of this in adding AI to an existing product.
When a rejection does happen, the message usually cites a specific guideline. Read it carefully, fix the actual issue, and reply through the review system if you believe the reviewer misunderstood something. Arguing without changing anything rarely works.
Testing before the public sees it
Both platforms have built-in beta channels: TestFlight on iOS and internal, closed and open testing tracks on Google Play. Use them properly:
- Internal testing for your own team on every build.
- A closed beta with real users from your target audience, on their own devices, before launch.
- A release checklist that covers the store-specific items above alongside the functional tests.
Real devices matter. Older phones, small screens, poor connections and system settings like larger text all expose problems a simulator will not. We explain how this fits into a wider quality process in software testing and QA.
Releasing updates without breaking things
Once you are live, every update goes through review again, and you cannot instantly pull a bad version off users' phones. A few habits keep this manageable:
- Staged rollouts. Both stores let you release an update to a percentage of users first, so a crash shows up in a small group before it reaches everyone.
- Remote feature switches. Ship new features turned off and switch them on from your server, so a problem can be disabled without a new submission.
- Crash reporting from day one. You want to see a problem in your dashboard before you see it in a one-star review.
- Backward-compatible servers. Some users will run old versions for months. Your backend has to keep serving them until you decide to require an update.
- Watch platform updates. New iOS and Android versions, and new store requirements, arrive every year. Budget time for them, the same way XR apps need upkeep when headset software changes, as we describe in XR app maintenance.
How long to plan for
For a first launch, plan in weeks, not days, for the store side alone: account verification, listing preparation, any required closed testing, review itself and at least one resubmission. Most of this runs in parallel with development if it starts early. Building faster with AI coding agents, as we do in our ship-in-days playbook, shortens the build, but it does not shorten someone else's verification queue, which is exactly why the store work should start on day one. For budgeting the whole project, see what an MVP costs and, for games, game development cost.
Questions to ask your development team
- Whose name will the developer accounts be in, and when will we register them?
- Who prepares the store listing, screenshots and privacy disclosures?
- Which third-party libraries collect data, and how is that reflected in our declarations?
- Does our pricing need in-app purchases, and how does that affect our margin?
- What do reviewers need to access the app, and who writes the review notes?
- How will we beta test, with whom and on which devices?
- How do updates roll out, and how do we switch off a broken feature?
- What happens when a new OS version or store rule lands after launch?
The bottom line
The app stores are a gate every mobile product has to pass, at launch and with every update after it. The rules are knowable, and most rejections are avoidable with accounts in the right name, honest disclosures, payment flows designed around store policy and a reviewer who can actually get in. Treat the release as part of the product, start the paperwork early, and launch day stops being a surprise.
Planning a mobile app and want the launch to go to plan? Book a demo and we will walk through the build and the store process together. See our work: LectureNotes AI, Lifemaxxing AI, Covoisino, Fyuel, ARCortex and more.