--- title: What documentation should you prepare before app submission? description: Avoid app store rejection by preparing the right documents first, from privacy policies and age ratings to KYC requirements and store listing copy. image: https://weareaffective.com/hubfs/learning-centre-images/what-documentation-should-you-prepare-before-app-submission.webp --- [Skip to content](https://weareaffective.com/learning-centre/what-documentation-should-you-prepare-before-app-submission#main-content) [![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com) - [Home](https://weareaffective.com) - About Us - [Our Story](https://weareaffective.com/about) - [How We Work](https://weareaffective.com/how-we-work) - Our Services - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy) - [App Design](https://weareaffective.com/app-design-agency) - [App UX Design](https://weareaffective.com/app-ux-design) - [App UI Design](https://weareaffective.com/app-ui-design) - [App Technical Architecture](https://weareaffective.com/app-architecture) - [Existing App Audits](https://weareaffective.com/app-audit) - [Case Studies](https://weareaffective.com/case-studies) - [Pricing](https://weareaffective.com/pricing) - [Learning Centre](https://weareaffective.com/learning-centre) - [Get Started](https://weareaffective.com/get-started) Expert Guide Series # What documentation should you prepare before app submission? Table of Contents App store rejection is not random. It follows patterns, and almost all of them trace back to documentation that was incomplete, inconsistent, or simply absent when the submission went in. The review process is faster than most people expect, with [Apple's published data](https://gotechsolutions.co/blog/apple-app-store-submission-guide-2026/) suggesting around 90% of submissions are reviewed within 24 hours, which means a rejection comes back quickly and the delay it causes is entirely avoidable. Getting the paperwork right before submission is the work. > Getting the paperwork right before submission is the work. We have seen this play out on our own projects more than once. The peer-to-peer currency exchange product is the clearest example: the core transfer mechanism worked well, but we had not factored in anti-money laundering requirements, and Apple flagged the product as a potential vehicle for money laundering. What followed was a retrofitting process that touched KYC checks, transfer security, and hard limits on the number of transfers permitted between any two parties. All of that [could have been addressed before submission](https://weareaffective.com/app-planning-strategy) with the right documentation in place from the start. This article covers what you actually need to prepare, in the order it tends to matter, drawing on what we have encountered building consumer apps across a range of lifestyle categories. ## Privacy Policy and Terms of Service Both the App Store and Google Play require a privacy policy for any app that collects user data, and in practice that means almost every app. The policy needs to be hosted at a live, accessible URL before you submit, because the review team will check it. A placeholder page or a "coming soon" message will fail the review. The privacy policy needs to cover what data you collect, why you collect it, how long you keep it, who you share it with, and what rights users have over it. If your app operates in or is available to users in the UK or European Union, GDPR compliance is not optional. If you are targeting US users, state privacy laws such as the California Consumer Privacy Act add further requirements around disclosure and opt-out rights. #### Terms of Service Terms of Service are separate from the privacy policy and serve a different purpose. They define the relationship between you and the user: what the app does, what it does not do, acceptable use, liability limitations, and what happens when an account is suspended or terminated. These are the documents that protect you if something goes wrong. Both documents should be drafted or reviewed by a legal professional who understands app law in the territories you are launching in. Generic template policies copied from another product carry real risk, particularly if your app handles payments, health data, or communications between users. ## App Store Listing Copy and Screenshots The listing copy and screenshots are your product's [first impression for most users](https://weareaffective.com/learning-centre/what-curiosity-looks-like-in-a-first-session-and-why-most-products-design-past-i). An average visit to an app product page lasts no more than 10 seconds, with half that time spent on screenshots, according to [SplitMetrics](https://splitmetrics.com/user-behavior-insights-app-store-vs-google-play/). That is not much time to make a case for why someone should install your app. We learned this directly on the anonymous messaging app we built, which required upfront registration before users could experience the product. Because we could not drip-feed value once someone was inside the app, all the messaging that would normally unfold through use had to be front-loaded into the App Store presence instead. The screenshots, the description, and the category selection all had to work harder than they would on a product with a [frictionless first experience](https://weareaffective.com/learning-centre/why-product-owners-should-write-the-users-second-session-before-the-first-one). According to [ASOMobile](https://asomobile.net/en/blog/screenshots-for-app-store-and-google-play-in-2025-a-complete-guide/), about 90% of users do not scroll past the third screenshot, which means the first three images carry most of the weight. Prepare them with that in mind. #### Category Selection Category choice affects your discoverability from day one. Where a product could plausibly sit across two categories, we generally advise launching in the less competitive one first. Higher rankings there generate more organic impressions and downloads, which builds the usage and awareness needed before moving into a more competitive primary category later. Write your App Store description with the first two lines doing the heaviest lifting. On both platforms, users see only a short preview before tapping to expand, so the opening lines have to earn that tap. ## Age Rating and Content Classification Both Apple and Google require you to self-declare a content rating for your app, covering areas such as violence, adult content, gambling, substance use, and user-generated content. The rating you declare affects who can see and download your app, so it needs to reflect what the product actually contains rather than what you would prefer the audience to be. Getting this wrong in either direction creates problems. Under-declaring the maturity of your content will get the app rejected or removed after launch. Over-declaring restricts your audience unnecessarily. A wellness app that includes a meditation timer and nothing else does not need the same rating as an app that includes a social feed where users can post freely. > The rating you declare must reflect what the product actually contains, not what you would prefer the audience to be. If your app includes user-generated content of any kind, both platforms treat this as a significant factor. The presence of social features, messaging, or community posts will push your rating upward and may trigger additional requirements around moderation and reporting tools. If your app includes any form of user-generated content, document your moderation approach before submission. Both Apple and Google want to see that you have a plan for handling harmful content, not just that you intend to deal with it later. ## Design built to *grow* your product We give your app the strategic and design foundations it needs to launch well and keep growing. Research, UX/UI design and technical specs ready for your development team. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## Financial and Regulatory Compliance Documentation If your app includes in-app purchases, subscriptions, or any form of payment, you need to understand the platform fee structure before you set your pricing. Apple retains 15% for developers in the Small Business Programme and 30% in the first year of any subscription. Google applies 15% on the first million in annual earnings and 30% above that. [SplitMetrics](https://splitmetrics.com/blog/google-play-apple-app-store-fees/) covers this breakdown in detail. These fees need to be factored into your pricing from the start, not treated as a surprise after launch. Beyond platform fees, certain product categories carry regulatory requirements that exist entirely outside of what Apple or Google ask for. Financial services apps, health monitoring tools, apps involving children's data, and products that facilitate transactions between users all sit in regulated territory. The documentation you need varies by category and by the territories you are launching in. #### What to Prepare At a minimum, assemble the following before submission for any app with financial components. 1. Confirmation of the legal entity that owns the developer account and is responsible for payments 2. Bank account details linked to the developer account for payouts 3. Tax information relevant to your territory, including VAT registration if applicable 4. Any licences required to operate in your sector, such as financial services permissions 5. Documentation showing compliance with payment card industry standards if you handle card data directly Consumer app revenue builds over time through volume and retention. Pricing structures that try to recover development costs quickly tend to be set at a level that suppresses downloads, which is the wrong trade-off at launch. ## KYC, AML, and Data Handling Requirements If your product facilitates money movement of any kind, identity verification and anti-money laundering requirements are non-negotiable. We discovered this the hard way on the peer-to-peer currency exchange product. The app let users exchange leftover foreign currency at interbank rates, which worked well as a mechanism, but Apple raised concerns that the unlimited transfer capability between two parties could be used for money laundering. We had not built those safeguards in from the start, and retrofitting them after the flag cost time and budget we could have spent elsewhere. What we had to add was not simple. More stringent Know Your Customer checks required additional identity verification steps in the flow. Enhanced transfer security needed its own documentation. And we had to physically limit the number of transfers permitted between any two users. Each of those changes meant rework to a product that had already been built. #### Data Handling Evidence Separately from KYC and AML, both platforms require you to declare how your app handles user data through their data nutrition label systems. Apple's App Privacy section and Google's Data Safety form both ask you to self-declare what data you collect, whether it is linked to the user's identity, and whether it is used for tracking. These declarations need to match what your app actually does. A [mismatch between what you declare](https://weareaffective.com/learning-centre/is-dirty-data-ruining-your-mobile-apps-purpose-what-app-developers-need-to-know) and what the review team finds in the product is a rejection. Map out every data point your app collects, where it goes, and how long it is retained before you complete the platform data declarations. Doing this from memory during submission is where errors creep in. ## Onboarding Flow Validation Evidence The onboarding flow is where users are most often lost, and it is also where submission problems often have their roots. Simon's [pre-launch checklist puts a tested](https://weareaffective.com/learning-centre/how-to-scope-a-pre-build-research-phase-when-the-budget-is-already-signed-off-fo) onboarding flow near the top: [real users need to have moved through it](https://weareaffective.com/learning-centre/what-a-development-team-actually-needs-to-know-about-the-user-before-sprint-one), comprehension needs to be confirmed, and friction points need to be identified and addressed before the product goes to a review team. On the dating app project focused on verified profiles and preventing bots, the client chose to skip discovery for the messaging component and focus only on onboarding. The result was a generic messaging feature that contradicted the entire product premise, allowing the automated and fake messages that the onboarding was designed to prevent. The mismatch between a rigorously verified onboarding and a permissive messaging system meant the whole messaging section had to be rewritten at a cost of approximately £15,000 in additional budget and two months of extra work. The lesson is that the onboarding flow cannot be treated in isolation. It sets up a promise the rest of the product has to keep, and the documentation you prepare for submission should reflect how those two things connect. #### What Validation Evidence Looks Like Reviewers do not need to see your research reports, but having them prepared matters for a different reason: they demonstrate that the [product was built from evidence rather than assumption](https://weareaffective.com/learning-centre/5-things-that-make-the-difference-between-so-so-apps-and-stellar-apps-what-your-). If the review team asks questions about how a specific flow works or why a particular design decision was made, having tested evidence behind those decisions is the fastest way to resolve it. - User testing session notes covering comprehension of the onboarding steps - Any focus group findings that shaped the flow - A clear record of what changed between early prototypes and the submitted version ## Release Scope and Platform Definition Before submission, you need to have made firm decisions about what you are releasing and where. That means a defined version number, a clear list of what is in scope for this release, the platform or platforms you are submitting to, and the geographic territories you are targeting. These are not administrative details. They shape the review process and determine what the team is evaluating. We advised on a well-funded sports club app designed to manage finances, games, schedules, and players across multiple sports. Our recommendation was to launch with a single sport and a single platform first, building out from there once the core experience was proven. The client rejected this approach entirely. They wanted everything released at once and refused to go to market until the full product was complete. That all-or-nothing stance created the [conditions for runaway scope creep](https://weareaffective.com/learning-centre/what-scope-creep-actually-costs-a-sports-club-app-that-spent-twelve-months-growi), and the product took considerably longer to reach users than it needed to. #### Soft Launch Consideration A soft launch in a smaller territory before a full rollout is worth considering for any product with genuine complexity. It gives you a contained environment to catch edge cases and performance issues before the wider audience arrives. The documentation for this is the same as a full launch, but the scope declaration needs to reflect the limited geographic release clearly so that the review team knows what they are assessing. We also saw the cost of premature date announcements on two projects, a gaming app for art enthusiasts and a grassroots football product. Both clients picked fixed launch dates and began publishing them publicly before the products were ready. When development changes pushed those dates, they had to backpedal publicly and repeatedly. Committing to a specific date before the launch is confirmed is a mistake the documentation phase is the right time to avoid. ## Conclusion Documentation is not the part of a product launch that anyone finds exciting, but it is the part that decides whether the launch happens on schedule or gets pushed back by weeks. The currency exchange product, the dating app, the sports club app: across all of them, the problems that caused delays were foreseeable, and most of them would have surfaced during a thorough documentation review before submission. The practical approach is to treat the documentation checklist as part of the build, not as something that happens after the product is ready. Privacy policy, terms of service, data declarations, age rating, KYC and AML compliance, onboarding validation evidence, and a clearly defined release scope all need to be in place before the submission goes in. Each one that is missing is a reason for a rejection that costs more time than the preparation would have. Getting this right the first time is achievable. It requires the same discipline that the product itself deserves, applied to the paperwork that gets it in front of users. If you are preparing for a submission and want a second set of eyes on where your documentation stands, [let's talk about your app launch](https://weareaffective.com/get-started). ## Frequently Asked Questions Do I need a privacy policy before submitting my app? Yes, both the App Store and Google Play require a privacy policy for any app that collects user data, which in practice means almost every app. The policy must be hosted at a live, accessible URL before submission, as a placeholder page will result in a failed review. What should my privacy policy include? Your privacy policy needs to cover what data you collect, why you collect it, how long you retain it, who you share it with, and what rights users have over their data. If your app is available to users in the UK or EU, GDPR compliance is mandatory, and US-facing apps may also need to meet requirements under laws such as the California Consumer Privacy Act. Is a Terms of Service document the same as a privacy policy? No, they are separate documents that serve different purposes. A Terms of Service defines the relationship between you and the user, covering acceptable use, liability limitations, and account termination, while a privacy policy specifically addresses how user data is handled. Can I use a template privacy policy or Terms of Service? Using generic templates copied from another product carries real risk, particularly if your app handles payments, health data, or communications between users. Both documents should be drafted or reviewed by a legal professional who understands app law in the territories you are launching in. How quickly will my app be reviewed after submission? Apple's published data suggests that around 90% of submissions are reviewed within 24 hours, so a rejection can come back very quickly. This means that any delays caused by missing or incomplete documentation are largely avoidable with proper preparation beforehand. What happens if my app has legal compliance gaps at the point of submission? The review team may flag your app and reject it, requiring you to retrofit compliance measures before resubmitting. As the article illustrates with a peer-to-peer currency exchange product, addressing issues such as anti-money laundering requirements and KYC checks after rejection is far more costly and time-consuming than preparing the right documentation from the start. Why do app store screenshots and listing copy matter so much? The average visit to an app product page lasts no more than 10 seconds, with roughly half that time spent on screenshots, so your listing needs to make a strong case for installation very quickly. If your app requires upfront registration or does not immediately demonstrate its value, your store presence must do that communicative work in place of the in-app experience. At what stage should I start preparing my submission documentation? Documentation should be treated as part of the build process rather than something addressed at the end. Preparing it early allows you to identify compliance requirements, such as financial regulations or data protection obligations, before they become costly problems to fix after a rejection. ## Related Articles [![](https://weareaffective.com/hubfs/learning-centre-images/what-is-the-app-store-approval-process.webp)](https://weareaffective.com/learning-centre/what-is-the-apple-app-store-approval-process) ### [What Is the Apple App Store Approval Process?](https://weareaffective.com/learning-centre/what-is-the-apple-app-store-approval-process) So, your business is ready to start [launching your app on the App Store](https://weareaffective.com/app-planning-strategy). Exciting times, right? But... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![App Store Ranking Secrets: What actually works](https://weareaffective.com/hubfs/learning-centre-images/app-store-ranking-secrets-what-actually-works.webp)](https://weareaffective.com/learning-centre/app-store-ranking-secrets-what-actually-works) ### [App Store Ranking Secrets: What actually works](https://weareaffective.com/learning-centre/app-store-ranking-secrets-what-actually-works) Most app store optimisation advice focuses on keywords, screenshots, and descriptions. We look at... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![how-do-i-make-my-app-feel-as-exclusive-as-my-physical-store](https://weareaffective.com/hubfs/learning-centre-images/how-do-i-make-my-app-feel-as-exclusive-as-my-physical-store.webp)](https://weareaffective.com/learning-centre/how-do-i-make-my-app-feel-as-exclusive-as-my-physical-store) ### [How Do I Make My App Feel As Exclusive As My Physical Store?](https://weareaffective.com/learning-centre/how-do-i-make-my-app-feel-as-exclusive-as-my-physical-store) You've worked hard to make your physical store feel special. The lighting, the displays, the way... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com) 20-22 Wenlock Road London, N1 7GU United Kingdom +44 20 4572 8062 [hello@weareaffective.com](mailto:hello@weareaffective.com) Services [App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit) Legal [Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70) Case studies [TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift) About us [Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work) Guides [Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth) Copyright © 2026, weareaffective.com. All rights reserved.