What the age rating questionnaire is really asking.

Most developers treat the age rating form as a five-minute compliance chore on the way to a submit button: click through the violence questions, answer no to everything, take the 4+ and move on. That reading was never quite right, and after the last eighteen months of changes to both stores it's actively expensive. The questionnaire isn't a form where you declare a rating. It's an input to a rating engine, and its output controls a badge on your product page, which regions can see you, and — new this month on Apple's side — which screen-time budget your app gets charged against on a family device.

You don't choose the number

This is the part people get wrong first. On neither store do you pick an age rating. You answer questions about content and capabilities, and the platform computes a rating from your answers. Apple generates the tier from the frequency and presence of each content descriptor; Google hands your answers to the International Age Rating Coalition, which runs them through each member authority's own rules.

The practical consequence: there is no "we'd rather be 4+" lever. If your app has a feature that trips a threshold, the rating moves, and the only way to move it back is to change the app. Apple does offer one manual override, and it only goes one direction — if your own policy requires a higher minimum user age than the calculated rating, you can raise it after answering the questions. You can never lower it.

Apple's tiers changed, and so did the questions

In July 2025 Apple replaced the old ladder with a more granular one. The tiers are now 4+, 9+, 13+, 16+ and 18+ — the long-standing 12+ and 17+ buckets are gone, and every existing app was automatically re-mapped onto the new scale. There is also an Unrated state, which is not a rating so much as a shelf: an unrated app cannot be published at all.

Four new required question categories came with it — in-app controls, capabilities, medical or wellness topics, and violent themes — and Apple set a deadline of 31 January 2026 for every app to answer them. That deadline has passed, and the enforcement is exactly what it sounds like: apps that haven't completed the updated questionnaire hit an interruption when they try to submit an update. If you have an app that hasn't shipped since 2025, the thing blocking your next release may be a form, not a build.

The full set of categories Apple now asks about: in-app controls (parental controls, age assurance), capabilities, mature themes, medical or wellness, sexuality or nudity, violence, and chance-based activities. That last one covers gambling, simulated gambling, contests and loot boxes, which is worth knowing if you've ever shipped a randomised reward.

Capabilities is where non-games get caught

If your app has no violence, no nudity and no gambling, you will skim past most of the form and land in the section that actually applies to you. Apple's capabilities questions cover unrestricted web access, user-generated content, social media, messaging and chat, and advertising.

Every one of those is a feature a perfectly ordinary utility can have. An in-app browser for opening links is unrestricted web access. A comments field is user-generated content. A support chat is messaging. None of them are content decisions you'd think of as age-sensitive, and all of them push the computed rating up. This is why a note-taking app with a public sharing feed can come out at 13+ while a competitor without one sits at 4+, with no difference in the actual material either app shows.

Read that consequence carefully, because it's a genuinely new kind of cost. Time Allowances let a parent budget screen time per category. If your productivity app answers yes to the social question, it stops competing for a child's attention against other productivity apps and starts competing against the feeds — out of the same shrinking budget. That's a product decision now, not a paperwork one, and it's worth asking whether the discovery feed you're planning is worth the bucket it puts you in.

The same answers produce different ratings in different countries

Both stores localise the outcome, which is why "our rating" is really a matrix. Apple assigns ratings per country or region against local standards: Australia applies different thresholds for social media and loot boxes at 16+; Brazil shows self-rated ClassInd pictograms (AL, A6, A10, A12, A14, A16, A18) alongside official MJSP ratings, and gambling apps there need a valid Brazilian fixed-odds betting licence; in Korea, simulated gambling content requires a Rating Classification Number before the app can be listed at all.

Google's IARC questionnaire is a single form that fans out to ESRB (Americas), PEGI (Europe and the Middle East), USK (Germany), ACB (Australia, games only), ClassInd (Brazil), GRAC (South Korea, games only), an IARC Generic rating for everywhere else, and a Google Play Rating used for apps in South Korea and Russia. One set of answers, eight verdicts. A feature that's a shrug to the ESRB can be the one USK rates strictly, so if your install base skews to a single market, read the per-authority summary Play shows you before you submit rather than after.

The only real trap is under-rating

Google's language on this is unambiguous: misrepresentation of your app's content may result in removal or suspension, and rating authorities can override your rating during review. Apps with no content rating at all get removed from the Play Store. Rating yourself lower than your content warrants is not a grey area you can argue later — it's the same category of offence as a misleading store listing, and it reaches the developer account, not just the app.

Over-rating is a softer failure but still real: an 18+ app is invisible to a large chunk of family devices. The answer isn't to shade your answers in either direction — it's to answer honestly and then, where the rating surprises you, change the feature that caused it.

It is not a set-and-forget field

Both platforms require you to re-answer when the app changes. Google is explicit that you must retake the questionnaire whenever content or features change in a way that affects your responses — and "features" is doing real work in that sentence. Adding a chat, adding ads, adding an in-app browser, adding a share feed: each is a new yes on a form you filled in two years ago and haven't looked at since.

The cheap habit that prevents all of this: add one line to whatever release checklist you already run. Does this release add a capability — web, chat, UGC, ads, social, randomised rewards? If yes, open the questionnaire before you build the release candidate, not after review sends it back. The form takes ten minutes; a rejection at the end of a submission queue costs days.

Your screenshots have to agree with your answers

One last seam, between two systems that don't talk to each other: your store screenshots are reviewed against the rating you declared. A frame showing a weapon, a wager, or a feed full of stranger-generated content in a 4+ listing is a contradiction reviewers do act on — and the fastest version of this failure is a screenshot that advertises a feature your questionnaire says you don't have. We've written about what actually gets a screenshot rejected separately; the age-rating angle is simply that your marketing frames are evidence about your app's content, and they're read that way.

Which makes the boring fix the right one: know what rating your feature set computes to, design the screenshot set to match it, and re-check both together whenever a release adds a capability. ShotCanvas won't fill in the questionnaire for you, but it will get the other half — a consistent, pixel-exact set for both stores — done in an afternoon instead of a week.