App Age Ratings: App Store and Google Play Guide

An age rating is a product decision, not a launch-day form

A language-learning app looks harmless in its lesson catalogue. Then learners can upload profile photos, message one another and join public study groups. A marketplace may sell ordinary products but allow sellers to write unreviewed descriptions and link to external pages. A fitness service may contain medical advice, supplements, before-and-after images or a community feed. The rating question is no longer answered by the app's main category.

This is why completing the questionnaire five minutes before submission is risky. The person in App Store Connect or Play Console often knows the intended experience but not every path through the product. They may answer for the polished demo account while reviewers and users can encounter chat, advertising, external content or old posts that tell a different story.

The better approach is to treat age classification as a small product review. It sits beside the mobile app launch checklist, privacy declarations and moderation readiness. One owner gathers the facts, another checks them against the current build, and the answers are reviewed when features change.

Separate three questions that teams often mix together

The store age rating tells families and store systems what content or capabilities may be present. On Apple platforms it also works with parental controls. On Google Play, regional rating authorities assign the displayed result from the questionnaire.

The intended audience is the group the product is designed and marketed for. An app can have a relatively low content rating without being designed for children. Conversely, choosing a higher rating does not free a product aimed at children from family, privacy or advertising rules.

Runtime age assurance is how an app obtains an age-related signal and adapts access inside the product. Apple's Declared Age Range API and Google's Play Age Signals API can support this in relevant regions and use cases. They do not replace the store questionnaire. Apple explicitly notes that even an 18+ rating does not remove a developer's age-assurance obligations where the law requires them.

That distinction prevents a common shortcut: "We selected 18+, so the product is covered." A label, an audience declaration and an access control solve different problems.

Build a feature inventory before opening either console

Start with what a person can experience after installation, including content supplied later by users, partners, advertisers and linked websites. A compact inventory is enough if it is honest.

Do not write "none" simply because the risky material is prohibited in the terms. If users can publish content, the questionnaire concerns what can appear and how often, not only what the company would like them to publish. Terms matter, but working reporting, blocking and review tools matter too. The mobile app moderation guide covers that operational layer.

*The questionnaire becomes easier when every content source and capability has an owner, an example and a safeguard.*

How Apple's age-rating workflow works in 2026

Apple's current global system for devices running iOS 26 and the corresponding platform versions uses five bands: 4+, 9+, 13+, 16+ and 18+. App Store Connect derives the result from answers about in-app controls, capabilities and the frequency of content descriptors. It can also display region-specific results where local systems require them.

The practical path is Apps, then the relevant app, App Information and Age Ratings. The questionnaire asks about controls and capabilities before moving through content categories. Apple allows a developer to override the calculated result to a higher rating. If the app's own licence agreement sets a higher minimum age, Apple says the override must respect it. An unrated app cannot be published on the App Store.

"Made for Kids" is a separate, consequential choice. If an eligible app is approved in the Kids category, that selection cannot simply be switched off later, and subsequent updates must continue to follow the category's rules. Do not choose it as an ASO tactic because the interface looks child-friendly.

Apple's questionnaire is still evolving. In June 2026 Apple announced a July update asking developers to indicate social-media capabilities, including interaction with user-generated content through a social feed. This supports new time-management categories in upcoming operating systems. A community feature that once looked like a small engagement tool can therefore affect both classification and how parental controls understand the app.

How Google Play content ratings differ

Google Play requires a content-rating questionnaire for apps and games. Responses are used by participating authorities, including systems coordinated through the International Age Rating Coalition, so the displayed label can differ by region. An app left unrated can be removed from Google Play, and ads served inside the app must be appropriate for its content rating.

The questionnaire sits under Policy and programs, then App content, though console navigation can change. Answer using the live production experience and every enabled region. Google says that if the result appears inaccurate, the developer can retake the questionnaire; a rating authority can also change a rating after review.

This process is not the same as declaring a target audience in Google Play. A product that is not designed for children still needs an accurate rating and must comply with general policies. If children are part of the target audience, Families requirements, advertising choices, data practices and store presentation need their own review. The Google Play policy checklist keeps those declarations together.

Google is also expanding the Play Age Signals API. The July 2026 developer announcement described a global rollout after earlier regional availability. The API can return privacy-preserving age-related signals that a product uses for appropriate experiences. Its terms restrict those signals to age-appropriate access and compliance, not advertising, profiling or analytics. Again, this is runtime behaviour, not a shortcut around the content-rating form.

The features most likely to produce a wrong answer

User-generated content. Review the worst reasonably reachable content, not the nicest feed at launch. Check public profiles, comments, image uploads, live features and links. Document how quickly reports reach a human and what happens before review.

Chat and matching. A support conversation with a known business is different from anonymous random chat. Direct messaging between adults is different from unrestricted contact with minors. Defaults, discoverability, blocking and moderation change the risk even when the chat interface looks identical.

Health and wellness. A step counter is not the same as treatment guidance, discussion of mental health crises or graphic medical imagery. Store declarations, product wording and professional review should describe what the app actually does. The rating itself is not a medical disclaimer.

Chance-based mechanics. A decorative wheel, a paid loot box, a contest and real-money gambling are not interchangeable. Map the mechanic, the reward, whether payment is involved and where it is available. Hiding a feature in one country does not answer what users can access elsewhere.

External content and ads. An embedded browser, video catalogue or advertising network can introduce material that the core team did not author. Check filters and network settings, but do not assume they make the content source disappear from the questionnaire.

Design the product response, not only the store answer

Once the inventory exists, create a simple access matrix. Rows are age bands or unknown-age states. Columns are features such as public posting, direct messages, purchases, mature topics and location sharing. Each cell says allowed, limited, requires permission or unavailable.

The "unknown" row is important. People may decline to share an age range, the signal may be unavailable, or an account may arrive through an older version. The app still needs a safe and understandable state. Do not infer age from behaviour, contacts or advertising data just to avoid that decision.

Then test transitions. What happens when parental approval is revoked? Does an existing conversation remain visible? Can a user reach a restricted screen from a notification or deep link? Does customer support know why an option disappeared? Apple and Google both provide tooling around age signals, but your backend, permissions and support scripts still have to enforce the chosen experience.

Review ratings whenever the product changes

Age-rating answers should be part of release scope when a version adds:

• public profiles, feeds, comments, uploads or live streaming;
• private, group, anonymous or random communication;
• contests, virtual rewards, purchases or chance-based mechanics;
• health, relationship, substance, violence or other sensitive material;
• a new ad network, embedded browser or external content catalogue;
• parental controls, age gates or a different intended audience.

Run the same review for server-side launches. A feature flag can expose a new feed without a new binary, but users and store reviewers still experience it. Keep the completed inventory, screenshots of the relevant console result, the date, the app version and the decision owner. If App Review questions the metadata, this record is much more useful than trying to remember who selected an answer months earlier. The App Store rejection guide explains how to respond when the build and metadata no longer agree.

At Appfyl, we include rating inputs in the product brief rather than leaving them to the release manager. The Appfyl mobile app team connects audience, content sources, account roles, moderation, age-related access and store declarations before submission. The goal is not to force the lowest possible label. It is to make the label, the product and the operating process tell the same truth.

Questions people ask