When the Store Says No: A UK Pre-Submission Checklist for 2026 Rejections

App Store and Google Play review is not a UK regulator, but it increasingly reflects UK rules. That is where teams get caught. A feature that feels fine in a product demo can look like an unapproved financial promotion, an unsubstantiated health claim or a privacy label that does not match the SDKs actually running in the app.

In 2026, the rejections that cost UK teams a sprint are rarely exotic. They are predictable. Here is a pre-submission checklist built around the traps we still see, with a practical appeal note for each.

1. Financial promotions without the FCA paper trail

What gets flagged: investment, credit, buy-now-pay-later, savings or crypto features that look like regulated financial activity. Reviewers may ask for evidence of permissions or approval. A generic disclaimer is not the same as a financial promotion approval.

Pre-submission check: confirm whether the app is carrying out a regulated activity or communicating a financial promotion. Check the FCA register where relevant. Make sure risk warnings, representative examples and terms are visible in the user journey, not buried in a website footer.

Appeal note: attach register entries, approval references and a short description of the exact journey. Keep it factual: what the app does, who approves the promotion, and where the user sees the required information.

2. Health claims that sound like medical device claims

What gets flagged: phrases such as clinically proven, treats anxiety, diagnoses symptoms or improves a condition. UK reviewers and regulators pay attention to intended purpose, substantiation and whether the product crosses into medical device territory.

Pre-submission check: review every claim in the app, store listing and screenshots. Keep evidence for each one. If the product is a wellness tool, make sure the language does not imply diagnosis or treatment. If it is a medical device, have the regulatory classification ready.

Appeal note: show the evidence behind the wording and explain the intended purpose. If claims were changed, say exactly what changed and where. Do not argue that the claim is obvious; show the basis for it.

3. Privacy labels that do not match reality

What gets flagged: App Store privacy labels or Google Play Data safety sections that miss analytics, crash reporting, advertising or third-party SDKs. This is a common own goal because product teams update the app but forget the store declaration.

Pre-submission check: build a data map and SDK inventory before you fill in the forms. Check what is collected, whether it is linked to the user, whether it is used for tracking, and what the privacy policy says. UK GDPR and ICO expectations should inform the policy, even though the store review is separate.

Appeal note: provide a line-by-line mapping between the declared data types and the SDKs or first-party code that collect them. If you have removed an SDK, show the release where it changed.

4. Account deletion that only half works

What gets flagged: apps that let users create an account but make deletion difficult, hidden or web-only when the store expects an in-app route. Reviewers test this.

Pre-submission check: create a test account, find the deletion path, complete it and confirm what happens to data. Check retention rules, backup handling and any web deletion flow. If guest mode exists, make sure it is clear.

Appeal note: attach a screen recording of the full deletion journey from account creation to confirmation. State what data is deleted, what is retained and why. Keep it short.

5. Tracking prompts and consent that arrive too late

What gets flagged: tracking SDKs firing before consent, confusing pre-prompts, or purpose strings that do not explain what is tracked. On iOS, App Tracking Transparency is still a common review point. On Android, the Data safety declaration needs to match behaviour.

Pre-submission check: test a clean install. Watch when the tracking prompt appears and what happens if the user declines. Review purpose strings, privacy policy and consent records. Make sure the app still works without tracking.

Appeal note: include a clean-install video showing the prompt sequence and the app behaviour after decline. Reference the relevant privacy policy section and the SDK list.

6. Subscriptions, trials and paywalls that hide the deal

What gets flagged: unclear pricing, trial length that is hard to find, missing restore purchases, or cancellation information that only appears after payment. UK consumer protection expectations are not identical to store rules, but the review outcome is often the same: fix the disclosure.

Pre-submission check: screenshot every paywall state. Confirm price, billing period, trial conversion, auto-renewal terms, restore purchases and manage-subscription route. Test on a device with an existing subscription.

Appeal note: provide screenshots of the paywall and the restore flow. Point to where the terms appear before purchase. If the issue was a missing restore button, show the build where it was added.

7. Age ratings, kids’ categories and user-generated content

What gets flagged: an app that feels child-facing but has no age gate, weak moderation or advertising that does not match the declared audience. User-generated content without report and block tools is another repeat rejection.

Pre-submission check: review the age rating questionnaire honestly. Test reporting, blocking and moderation queues. Check whether ads, purchases or external links appear in child-facing areas.

Appeal note: describe the moderation policy, show the report and block flow, and explain any age gate. If the audience declaration changed, state the new position clearly.

The pre-submission sweep

Before you hit submit, assemble a review pack: a demo account with sample data, backend notes, regulatory evidence, screen recordings and a named contact. Then do one calm pass through the store listing, screenshots, privacy declarations and paywalls. Most rejections are not a mystery. They are a mismatch between what the app does and what the submission says.

When you appeal, keep it factual and attach evidence. Reviewers are busy; a concise note with the exact build, the relevant guideline and a screen recording is more useful than a long argument. The goal is not to win the debate. It is to get back to shipping.