The app is finished and tested; the team wants to go live. But there’s one more step between the build and the user that many underestimate: publication. It’s not just a matter of pressing a button, but involves two separate hurdles. First, the app must pass Apple’s App Store Review and Google Play’s review without being rejected. And after that, it actually has to be found, which is where App Store Optimisation (ASO) comes in.
This article covers both hurdles in the order in which they occur: first, how to avoid a rejection during the review process, then the basics of ASO for visibility afterwards. This post does not cover post-launch marketing campaigns or the technical details of the individual platform SDKs. The focus is on the submission and discoverability process itself.
What actually happens during the review
Both stores review every submission before it goes live. Apple relies more on manual checks, whilst Google relies more on automated processes; both now use AI-supported review steps. This is not a mere formality. Apple’s own App Store Transparency Report for 2024 shows around 7.8 million submissions reviewed, of which approximately 1.9 million were rejected. That is roughly a quarter. Most of these rejections are avoidable, as they stem from a manageable number of recurring reasons.
Timeframes are also part of managing expectations. Apple’s review process took an average of around 24 hours in 2023/24. By 2026, the timeframe had widened due to a sharp rise in the number of submissions: current figures typically cite 24 to 72 hours for new apps, and in some cases several days. Updates usually go through the review process faster than initial submissions. So do not plan the release for the exact day the press release is issued.
Google Play uses a similar technical review process, but has an additional hurdle for new developer accounts that often takes people by surprise: Anyone who created their account as a private individual after 13 November 2023 must conduct a closed test with at least 12 testers over 14 consecutive days before the app is released to the public. This figure was originally 20 and was reduced to 12 on 11 December 2024. The rule does not apply to organisational accounts, which is a good reason not to publish a business app via a private account. Important for planning: these 14 days are a strict lead time. It cannot be shortened, and without it, the app will not even enter the production track. Anyone who does not start the test in good time before the desired launch date will have to postpone the launch.
The most common reasons for rejection (and how to avoid them)
Apple categorises rejections according to its App Review Guidelines. Four of these cover the vast majority of cases.
App completeness: no crashes, no placeholders, a demo version
By far the most common reason for rejection, listed by Apple under Guideline 2.1. The app crashes, a core function is broken, a feature is visibly unfinished, or placeholder content such as ‘Lorem ipsum’ and test images are still present. Added to this is a pitfall that sounds trivial but nevertheless reliably leads to rejection: if the app requires a login, a working demo account must be provided in the review notes. If this is missing, the reviewer is presented with a login screen, cannot access the app and will reject it without ever having seen the rest of the app. Therefore, before submitting, click through the app on a real, freshly installed device – not just in the simulator – and enter the login details in the ‘App Review Information’ field.
Correct metadata: Screenshots must show the actual app
Screenshots, the preview video and the description must reflect the app’s current state (Guideline 2.3). Submissions will be rejected if the screenshots promise features that do not exist in the app, or no longer exist, or if the preview material is taken from an older version. This may sound trivial, but it’s a recurring issue because store assets are often created early on and not updated until launch. The order must be correct: the screenshots must be taken from the build that is submitted, not the other way round.
More than a website: the minimal functionality problem
An app that, at its core, merely displays a website within a frame – a so-called ‘web view wrapper’ with no significant native functionality – will be rejected under Guideline 4.3. Apple expects standalone added value compared to the mobile website: push notifications, offline capability, device functions such as the camera or location, and native navigation. Anyone who is unsure about this should clarify the scope of functionality with app development before the first build, rather than having to redesign the app after it has been rejected. The choice of technology plays a key role early on: cross-platform frameworks such as React Native or Flutter generate genuine native components, whereas a simple web container does not.
Data protection: labels, manifest, consent
The area that has seen the most stringent tightening between 2024 and 2026 (Guideline 5.1). Three things must be correct:
- The app privacy information (“Privacy Labels”) in the store must honestly and comprehensively list what data is collected and how it is used.
- An accessible privacy policy as a URL is mandatory for both stores.
- Since 1 May 2024, Apple has required a Privacy Manifest (
PrivacyInfo.xcprivacy). This declares the use of certain “Required Reason APIs” and also applies to integrated third-party SDKs. If it is missing, this does not result in rejection during the review process, but rather prevents the submission from proceeding at all: App Store Connect rejects the submission as soon as it is uploaded. Your app will not even enter the review process.
Anyone using tracking or personalised advertising also needs Apple’s App Tracking Transparency (ATT) consent framework. Passing data on to third parties, such as AI services, without clear disclosure and consent is a sure-fire reason for rejection.
A fifth, less common point of review is the Human Interface Guidelines: an app that does not adhere to platform conventions, breaks on large or small displays, or has unclear navigation will be flagged in the design section. This happens less frequently than the four points above, but often enough to keep an eye on it.
Google Play: its own mandatory fields
Google is less likely to reject apps on the grounds of minimal functionality, but checks mandatory information rigorously. The following must be provided prior to publication:
- The Data Safety Form, Google’s equivalent to Apple’s Privacy Labels. This is mandatory for every published app – i.e. for the closed, open and production tracks; only purely internal test tracks are exempt. The information provided must correspond to the app’s actual data behaviour.
- A privacy policy as a URL.
- The content rating via the questionnaire and a target audience declaration regarding the age group, which is scrutinised more strictly as soon as children are part of the target audience.
There is no hidden keyword field as with Apple; the reason why this matters for visibility is explained in the ASO section below. If the 12-tester rule described above also applies, publication is not a day-to-day process but requires a two-week lead time.
Pre-submission checklist
A short list that’s worth going through before every submission, deliberately kept brief:
- Clicked through the app after a fresh installation on a real device; no crashes, no broken core functions.
- Demo access (if login is required) provided in the review notes.
- Screenshots and previews are taken from the submitted build.
- Privacy policy URL accessible; privacy labels and data safety form completed and correct.
- Privacy Manifest present (iOS), third-party SDKs checked.
- Native added value beyond a simple website is evident.
- For a new Google personal account: the 12-tester test has been running for at least 14 days.
ASO Basics: after the review comes being found
A published app is not yet a visible app. ASO involves working to ensure the app appears in the stores for the right search queries and encouraging visitors to the product page to install it. It breaks down into two tasks.
Visibility determines which search terms the app appears for. The metadata fields are key here. The most important and heavily weighted are Title and Subtitle: the title combines the brand name with one or two strong keywords, whilst the subtitle conveys the benefits plus additional terms. Apple also offers a hidden keyword field with 100 characters in App Store Connect, which is not visible to users but is relevant for search. A peculiarity that beginners often overlook: Apple counts each keyword only once. Duplicating terms across the title, subtitle and keyword field therefore wastes space; it’s better to spread them out. This field does not exist on Google Play. Instead, Google indexes the visible description text, which is why the relevant terms naturally belong in the description there. It makes sense to have a core set of around 20 to 40 keywords that the app should consistently target, with a focus on more specific long-tail queries that are less competitive.
Conversion is the second task: anyone landing on the product page makes a decision within seconds. This is achieved through the icon, screenshots, preview video and reviews. The first three screenshots bear the brunt of the load, as they appear directly in the search results. They should showcase the core benefits, not start a feature tour from scratch. Reviews and their quantity have a dual effect: as a trust signal for the user and as a ranking factor for the app store.
ASO is not a one-off setup. The fields are fine-tuned with every version, keywords are tested, and screenshots are compared against variants. To get started, however, all it takes is the discipline to carefully craft the title, subtitle and the first three screenshots, rather than simply ticking them off as mandatory fields.
Classification
Back to the team that wanted to go live. There’s no single button to press between “ready” and “live” – instead, there are two separate sets of rules, which also change regularly. The reasons for rejection are manageable and avoidable if you’re aware of them before the first upload; visibility is a craft, not a matter of chance. Anyone publishing a single app once simply works through the checklist. Anyone who publishes regularly or maintains multiple apps incorporates the review and ASO steps firmly into the release process, ideally early enough that the choice of technology supports rather than jeopardises subsequent approval. If this decision is still pending, it’s worth consulting the comparison of cross-platform frameworks before the first build, as that is precisely where it becomes clear whether the end result will be genuine native components or merely a web container.
