What are the App Store requirements for mobile games?

Getting a mobile game onto the App Store or Google Play is not a formality. Both platforms have detailed, layered requirements covering everything from how your app is rated to how money moves through it, and the gap between "we've built the game" and "we can ship the game" can be months of rework if compliance is treated as an afterthought. We have seen that gap cost real projects real money, and on one project it cost the client the product entirely.

Platform requirements are design constraints that must be treated as first principles from the start.

The requirements split into several distinct categories: technical build standards, content classifications, monetisation rules, data privacy obligations, and App Store Optimisation. Each one carries its own review criteria and its own rejection risks. Understanding them together, before a line of code is written, is what separates a smooth submission from a prolonged back-and-forth with a platform reviewer.

This article walks through each category in order, drawing on what we have encountered doing this work, so you can build with the full picture in mind rather than discovering the edges of it at submission.

Apple App Store requirements for mobile games

Apple reviews every app and game before it reaches users. The process covers functionality, content, design standards, legal compliance, and business model. Games face the same baseline checks as any app, but with additional scrutiny on monetisation mechanics, age-appropriate content, and real-money features.

To submit, you need an active Apple Developer Program membership, which costs $99 USD per year. Your game must be built to Apple's technical standards: it must run on current iOS versions, use documented APIs, not crash during review, and include privacy manifests that declare what data the app collects and why. Apple also requires a support URL, a privacy policy URL, and an honest set of metadata including screenshots that accurately represent the actual product.

Review timelines and rejection patterns

According to Apple's published data, around 90% of App Store submissions are reviewed within 24 hours, though complex apps or those flagged for additional review can take considerably longer. Rejection is common on a first submission, and the reason given is not always the only concern a reviewer has. Addressing one issue and resubmitting can surface a second, and then a third. This is not always a sign of genuine compliance gaps: on a currency exchange product we worked on, Apple raised successive new objections each time we resolved the previous one, in a pattern that appeared to have little to do with the stated rules.

What Apple's guidelines actually cover

Apple's App Store Review Guidelines cover five areas: safety, performance, business, design, and legal. For games, the sections on user-generated content, in-app purchases, gambling mechanics, and children's privacy are the ones most likely to generate friction. Reading the guidelines in full before the build begins, rather than after submission, is the single most useful thing a team can do.

Google Play Store requirements for mobile games

Google Play's review process is faster on average than Apple's and historically more permissive, but it has tightened considerably over recent years. Google now applies substantive review to apps targeting children, apps with financial features, and apps using sensitive permissions. Games are not exempt from any of this.

Developers need a Google Play Console account, which costs a one-time $25 USD registration fee. From there, every game submission requires a completed data safety section, an up-to-date privacy policy, a content rating from the IARC questionnaire, and metadata that accurately reflects the product. Google will reject or remove apps where the store listing misrepresents what the app actually does.

Policy differences worth noting

Google's policies on real-money gambling, loot boxes, and subscription mechanics differ from Apple's in specific ways, and the differences matter if your game monetises through any of those routes. Google requires explicit disclosure of loot box odds. Apple does too, but the placement and format requirements are slightly different. On both platforms, simulated gambling games that do not involve real money are generally permitted, while games that pay out real money in any form require additional licences and are subject to geographic restrictions.

Google's enforcement can also happen post-launch through automated policy scans, meaning a game that passed review can later be flagged or removed if a policy update changes what is permitted. Building to the spirit of the rules, not just their letter, reduces that risk.

Age ratings and content classifications

Both platforms require every game to carry an age rating, and both base that rating on a questionnaire answered by the developer. Neither platform assigns a rating independently. The developer declares what content the game contains, and the system generates a rating from that declaration. If the rating turns out to be inaccurate, either because the developer made errors or because the game changed after rating, the app can be removed.

On the App Store, ratings run from 4+ through to 17+. On Google Play, ratings come from the IARC (International Age Rating Coalition) system, which generates ratings for multiple international markets from a single questionnaire. The IARC output is more granular: a game rated suitable for 12-year-olds in the US might carry a different rating in Germany or Brazil, because the underlying classification criteria differ by territory.

A wrong rating is not just a compliance problem, it determines who can find and download your game.

The practical consequence of an age rating is discoverability. A game rated 17+ on the App Store is invisible to any account that has parental controls set below that threshold. Getting the rating right matters for both compliance and reach. If your game includes mild cartoon violence, fantasy themes, or any in-app purchases, those must be declared and will push the rating upward. Underdeclaring content to keep the rating low is a policy violation on both platforms.

Complete the IARC questionnaire for Google Play and the App Store rating declaration on the same day and compare results. Where they diverge, check whether your content description is consistent across both submissions.

In-app purchases, monetisation rules, and payment systems

Both Apple and Google require that digital goods sold inside an app use the platform's own payment system. This applies to in-game currencies, cosmetic items, level unlocks, and subscriptions. Physical goods and services delivered outside the app are exempt, but anything that exists only inside the game must go through the platform's billing infrastructure.

The fee structure sits at 30% for most transactions, dropping to 15% for developers meeting certain thresholds: Apple applies 15% for developers in the Small Business Programme earning under $1M annually, and for subscription renewals after the first year. Google applies 15% on the first $1M in annual earnings and 30% above that, according to SplitMetrics. This has a direct bearing on pricing strategy, since a game priced at £4.99 nets considerably less than that figure after the platform takes its share.

Loot boxes and randomised rewards

Games that sell randomised rewards, commonly called loot boxes, must disclose the odds of each possible outcome before purchase on both platforms. Apple added this requirement to its guidelines after sustained regulatory pressure. Google followed. Several European markets have gone further and classified certain loot box mechanics as gambling, which triggers additional licensing requirements in those territories regardless of what either platform requires.

Subscription mechanics

Subscription-based games face additional rules around how trials are presented, how renewals are communicated, and how cancellation works. Apple requires that free trials include a clear disclosure of what the subscription costs after the trial ends and when the first charge will occur. Burying this information in a terms-of-service link is not sufficient.

Data privacy, permissions, and parental consent

Both platforms have tightened their data privacy requirements substantially since 2021. Apple introduced App Tracking Transparency with iOS 14.5, requiring apps to ask permission before tracking users across other apps and websites. Games that rely on behavioural advertising for revenue must handle the opt-out gracefully and build a fallback monetisation path for users who decline tracking.

Google Play requires a data safety section in every listing, disclosing what data the app collects, whether it is shared with third parties, and whether users can request deletion. The disclosure must be accurate: Google cross-references declarations against the app's actual behaviour, and discrepancies can result in removal.

Children's privacy and COPPA

Games rated for children or marketed to children face the strictest rules. On Apple, any app in the Kids category is prohibited from including third-party analytics, advertising networks, or data collection beyond what is strictly necessary for the app to function. On Google, apps targeting children must comply with Google's Families Policy, which restricts ad networks, behavioural tracking, and data sharing. In the United States, COPPA (Children's Online Privacy Protection Act) applies independently of platform rules and requires verifiable parental consent before collecting personal data from children under 13.

We worked on a fitness social app where a significant proportion of users turned out to be younger than the team had anticipated. The permission architecture had to be revisited before launch to ensure data collection was both disclosed correctly and legally defensible. Discovering that mid-build is a disruptive and costly problem to fix.

If your game has any social or community features and there is a plausible chance users under 13 will use it, map out your data flows before building those features, not after. Retrofitting privacy controls is significantly more expensive than designing them in from the start.

Financial features and anti-money laundering compliance

Games that allow real-money transfers between users, peer-to-peer gifting of monetary value, or cash-out mechanics sit in a different regulatory category from standard in-app purchases. Both platforms treat these features as financial products and apply corresponding scrutiny. On Apple in particular, any feature that moves real money between parties will receive close attention during review.

We encountered this directly on a peer-to-peer currency exchange product we worked on. The core mechanic allowed users to exchange leftover foreign currency with other travellers at interbank rates. We built the transfer mechanism well but did not factor in anti-money laundering requirements at the design stage. Apple flagged the product as a potential vehicle for money laundering because it placed no limit on how many transfers could occur between any two parties. We had to retrofit KYC (Know Your Customer) checks, enhanced transfer security, and hard limits on the number of transfers permitted between any two accounts. That work was unplanned, arrived late in the build, and cost time and budget that could have been avoided entirely.

The escalating objection problem

The same project illustrated another risk specific to Apple's review process. After we addressed the AML objection, Apple raised a new one. After we addressed that, another appeared. We eventually capped transactions at €150, which should have resolved the money laundering concern, but the app was rejected again. The client ran out of budget and abandoned the product. It later became clear the rejections coincided with the build-up to the launch of Apple Pay, which raised questions about whether the rejections were genuinely compliance-based or strategically motivated. The App Store review process has no effective mechanism for a developer to challenge that kind of behaviour.

App Store Optimisation requirements

App Store Optimisation is not purely a marketing discipline. Both platforms have content policies governing what is permitted in a game's title, subtitle, description, screenshots, and preview video. Keyword stuffing in the title field, screenshots that show content not in the current build, and ratings or awards claims that cannot be substantiated are all grounds for rejection or removal.

Beyond the rules, ASO carries a compliance function that teams regularly underestimate. We worked on a gifting and wishlist platform where the client was reluctant to invest in ASO, believing that word-of-mouth referral would drive installs without it. Our position was that the store listing is the product's first impression regardless of how users arrive there: the icon, the screenshot sequence, the short description, and the category selection together determine whether a user self-selects in or out before downloading. A user who downloads and then discovers the product is nothing like they expected generates a low rating and high churn, both of which suppress future discoverability.

The same principle applied even more directly when we built an anonymous messaging app that required upfront registration. Because value could not be drip-fed to users inside the app, everything that would normally unfold through use had to be communicated in the App Store listing instead. The screenshots and copy carried more weight than they would in a product where the onboarding itself could do that work.

Treat your screenshot sequence as a five-frame argument for why someone should download. Each frame should answer a specific objection: what it is, who it is for, what the core mechanic looks like, why it is worth the storage space.

TestFlight, beta testing, and account structure

Apple's TestFlight allows developers to distribute pre-release builds to testers before submitting for full App Store review. Internal testing covers up to 100 users with access to the App Store Connect account. External testing, which requires a brief review from Apple, supports up to 10,000 external testers. This is a meaningful number and makes TestFlight a practical tool for larger beta programmes, not just small internal QA groups.

The account structure matters as much as the tool. On a social football product we worked on, the client held the App Store Connect Account Holder role since the account was registered in their name. We were given admin access and set up three testing groups: one for our team, one for the client, and one for the client's external QA testers. That structure let us control which builds reached which groups during deployment.

As the project approached launch, the client began bypassing the structure by manually sending uploaded builds to whichever group they chose. Because the account was theirs, they had full access and we had limited ability to prevent it. That caused some problems with build consistency during the final weeks before submission.

Google Play's equivalent

Google Play offers internal testing, closed testing, and open testing tracks, which map roughly to TestFlight's internal and external modes. The key difference is that Google's testing tracks sit within the Play Console and do not require a separate tool. Open testing on Google Play is publicly visible on the Play Store, which can affect brand perception if the build is not ready for broad exposure.

Why platform compliance should be a design constraint from day one

Compliance is easier to design in than to retrofit. The projects where we have seen the most painful rework share a common pattern: platform requirements were known in the abstract but not translated into specific design decisions at the point where those decisions were being made. The result is a build that works as intended but fails review for a reason that was never invisible, just never addressed.

The dating app project is a clear example. The client wanted to skip discovery on the messaging component and focus the early build on onboarding. The onboarding was built around verified profiles and bot prevention. The messaging feature, built without equivalent rigour, allowed automated and fake messages, directly contradicting everything the onboarding had established. Fixing the contradiction required a rewrite of the messaging section, costing approximately £15,000 in additional budget and two months of extra work. The compliance concern there was not a platform rule but a product integrity issue: a feature that let fake messages through would not have survived the user trust that platform review cannot directly test for but that App Store ratings quickly expose.

Treating platform requirements as a design brief rather than a post-build checklist changes what gets built and when. It does not slow development: catching a structural problem before writing the code that instantiates it is always faster than catching it during review or, worse, post-launch.

What happens when compliance is left until submission

The consequences of late compliance discovery range from delays to total product failure. Minor issues, such as a missing privacy policy URL or an inaccurate age rating declaration, are quick to fix and only cost a resubmission cycle. Structural issues, such as an AML-non-compliant transfer mechanism or a monetisation model that requires a gambling licence the developer does not hold, are not quick to fix and may require significant rebuild work.

On the currency exchange product, late discovery of the AML requirement led to a sequence of reactive fixes, each one triggering a fresh review cycle and, on that project, a fresh objection from Apple. The client spent significant money on legal counsel and compliance work that should have been scoped into the project from the beginning. They ultimately ran out of budget before reaching the market.

The fitness social app presented a different version of the same problem. The original location-sharing design, which showed users' real-time positions on a map, was built before the team had fully characterised the user base. Research revealed that a high proportion of users were female, making precise location sharing a security concern. The feature had to be fundamentally redesigned to use randomised location offsets, so users could see only a vague area rather than a precise position, with exact location shared only after both parties opted in. That redesign was the right outcome, but it arrived later than it needed to and cost more than it would have if the user research had preceded the build.

Conclusion

The App Store and Google Play requirements for mobile games are not arbitrary obstacles. They reflect real concerns about user safety, financial integrity, children's privacy, and honest advertising, and they carry real consequences for products that do not address them. The cost of getting this right early is always lower than the cost of fixing it late.

The consistent pattern across the projects described here is that compliance problems discovered during review, or after launch, were foreseeable from the beginning. The AML requirements for a peer-to-peer transfer product, the children's privacy obligations for a social app with a young user base, the account structure risks of a client-held App Store Connect account: none of these were surprises in retrospect. They were simply not brought into the design process at the point where they could have been addressed cheaply.

Platform requirements belong in the design brief alongside the product brief. Not as a separate compliance workstream to be handed to legal at the end, but as a set of constraints that shape what gets built, how it is structured, and what it must communicate before a user ever opens it. Building to that standard from the start is what makes submission the end of the process rather than the beginning of a different, more expensive one.

If you are planning a mobile game and want to build with platform compliance in mind from day one, let's talk about your project.

Frequently Asked Questions