How to Publish an App: The App Store and Google Play Explained

Building a native app is only half the journey; getting it in front of people means going through Apple's and Google's own publishing processes, which are genuinely different from each other and each have requirements that regularly catch first-time publishers by surprise.

You need a developer account with each platform

Before you can submit anything, you need your own developer account with Apple and, separately, with Google. Both involve an annual or one-off fee, identity verification, and if you are publishing as a company rather than an individual, documentation proving the business is who it says it is. This account belongs to you, not to whoever built the app, which matters if you ever change developers, in the same way your domain, hosting and source code should be yours.

How Apple App Store publication works

Apple reviews every app before it goes live, checking it against detailed guidelines covering functionality, content, privacy and design. This is a genuine human review process, not just an automated scan, and it typically takes somewhere from under a day to a few days, though it can take longer if there are questions or issues. Common reasons for rejection include unclear privacy disclosures, broken functionality reviewers actually test, missing information about in-app purchases or subscriptions, and design that does not follow Apple's interface guidelines closely enough.

You will also need to complete Apple's privacy "nutrition label", declaring exactly what data the app collects and why, which needs to accurately match what the app actually does. Getting this wrong, even unintentionally, is one of the more common causes of delay.

How Google Play publication works

Google Play's review process leans more heavily on automated checks alongside human review, and first submissions from a new developer account are often reviewed more thoroughly than later updates. Google requires a similar data safety declaration to Apple's, and has its own policies around permissions, content and functionality. Review times are often faster than Apple's for straightforward apps, but can extend significantly if the app requests sensitive permissions (like location or contacts) without a clearly justified reason.

What catches first-time publishers out

• A privacy notice that does not accurately describe what the app actually collects, or is missing entirely (see our guide to UK GDPR for business apps).
• Requesting device permissions (camera, location, contacts) without a clear, justified reason visible to a reviewer.
• Placeholder content, broken links, or features that do not work when a reviewer actually tests them.
• Login-required apps with no way for a reviewer to actually access the app's real functionality (both stores expect a way in, such as demo credentials).
• In-app purchases or subscriptions that are not clearly explained, or that do not follow each platform’s specific commercial rules.
• Underestimating the timeline: leaving app store submission until the last moment, when review time is genuinely outside your control.

Realistic timeline and ongoing costs

Beyond the developer account fees, submitting to both stores adds real but usually modest time to a launch: budget for review, the possibility of at least one rejection and resubmission cycle, and time to prepare the required assets (screenshots, descriptions, privacy declarations) properly rather than as an afterthought. None of this is a reason to avoid native apps where they genuinely fit; it is simply a real part of the timeline that deserves planning for, not surprise.

If you're preparing to submit an app for the first time, or your submission has been rejected and you're not sure why, it's worth getting a second pair of experienced eyes on it before resubmitting blind.