Why the official route matters
Getting an app into a major store is less a single step than a short chain of them. Each link exists for a reason: the store wants to know who you are, what the app does, what data it touches, and whether it behaves the way you say it does. For people who use apps, this chain is part of why official app stores are the safer source. For people who build them, knowing the chain in advance prevents most last-minute surprises.
The details differ between the Apple App Store and Google Play, and both change their processes from time to time. Treat what follows as the general shape, and always check each store’s current developer documentation for exact requirements, fees and deadlines.
Step 1: Set up a developer account
Both major stores require a developer account before you can publish. Typically this means verifying an identity, agreeing to the store’s developer terms, and paying a fee (the amount and whether it recurs varies by store, so check). Organizations may be asked for additional verification, and some account types face extra requirements before an app can go live. Do this early, because verification can take longer than expected.
Step 2: Prepare a release build
The build you submit is not the same as the one you test day to day. It is typically signed with a key that proves the app comes from you, and it is built in a release configuration rather than a debug one. Keep your signing keys safe and backed up; losing them can make future updates difficult or impossible on some platforms.
Before building, run through your testing. Good app testing tools and a round of beta testing with real users usually catch problems that a developer on a fast personal phone will miss. It also helps to check older device testing results, since not everyone has a recent phone.
Step 3: Gather the listing material
The store listing is what people see before they install. You will typically need:
- An app name and a short description
- A longer description
- Screenshots (sometimes video) in the required sizes
- An icon
- A category and contact details
- A link to your privacy policy
Writing these honestly is its own task, covered in the articles on writing a store listing that is honest and clear and on screenshots and icons. The short version is that the listing should describe what the app really does, and the images should show the real app.
Step 4: Answer the questions about data, content and audience
Stores ask developers to declare things up front. Expect questions about what personal data the app collects, whether it shares data with third parties, which permissions it requests, and who the app is for. Your answers should match what the app actually does, including anything done by third-party code you included. If the app is aimed at or likely to attract children, extra rules usually apply, and the app will receive an entry in the store’s age ratings system based on your answers about content.
A clear privacy policy is generally required, and it needs to match your declarations. If you have not written one before, learning privacy policy basics from the reader’s side helps you see what people expect to find.
Step 5: Submit for review
Once the build and listing are uploaded, you submit for review. Reviewers, with the help of automated checks, look at whether the app works, whether it matches its description, and whether it follows the store’s rules on things like payments, content and data use. Review can take anywhere from hours to several days, and it can take longer for a first submission. Understanding store review guidelines before you submit is the best way to avoid a rejection.
If the app is rejected, the message usually points to the guideline involved. Read it calmly, fix the issue or reply with clarification, and resubmit. Rejections are common, even for experienced developers, and are rarely personal.
Step 6: Choose how to release
After approval, you often get a choice: release immediately, release on a date, or roll out gradually to a percentage of users. A gradual rollout is a sensible default for updates because it limits the damage if something goes wrong. For a first release, some developers also use a limited audience or test track first, to confirm that the store version behaves like the one they tested.
Step 7: Look after the app once it is live
Publishing is the beginning of the work, not the end. After launch you will likely need to:
- Watch crash reports and fix what they reveal
- Read and answer user feedback, including negative review replies that are polite and useful
- Ship app updates that fix problems without breaking things
- Keep up with platform compatibility as operating systems change
- Measure basic usage in a way that respects people’s privacy
- Number versions and write release notes that people will actually read
- Decide, eventually, whether the app should be retired
Each of those has its own article in this cluster. If you plan to promote the app, building an app landing page and thinking about app marketing can start before the store listing goes live, so that there is somewhere to send people on release day.
A realistic expectation
Passing review does not guarantee that anyone will find or use your app. Stores hold very large numbers of apps, and many categories are crowded. Plan for the possibility of slow early growth, and treat the first versions as a way to learn. A modest, well-maintained app with an honest listing is a reasonable goal for a first release.