The store rates your content, it does not card your customer, so the age check at checkout is a screen you write.

What age rating does an app that sells age restricted goods get?

There is no rating for selling, because Apple never asks. The nearest entry lives under Mature Themes and is called Alcohol, Tobacco, or Drug Use or References. Apple defines it as references to or depictions of the consumption of alcohol, tobacco products, or other licit or illicit substances. Infrequent answers give you 13+. Frequent answers give you 18+. In Brazil the same entry maps to A14 and A16. Read that definition twice, because it is about consumption being shown or mentioned, not about money changing hands.

Which means the rating follows your screenshots and your copy, not your inventory. A wine merchant app that lists bottles, prices and tasting notes is describing products. A wine merchant app whose home screen is a photo of four friends toasting at a table is depicting consumption. The second one rates higher than the first, and the second one is what most people ship, because that is the image the brand already owns. Your questionnaire answers have to describe the app you submitted, so if the hero image changes in version two, the answers change with it.

Two nearby entries catch service businesses out, and neither one sounds like it applies until you read the definition. Chance-Based Activities holds Gambling, which Apple defines as betting or wagering using real money or in-game currency that may be exchanged for real money, and that one lands at 18+. The same group holds Contests, defined as events that allow users to compete with one another for rankings, rewards, or the achievement of personal goals. Infrequent contests sit at 4+ and frequent ones at 13+. A loyalty scheme with a monthly prize draw is a contest. So is a referral leaderboard. Calling it a giveaway in your copy does not change which box you tick.

And one entry that costs you nothing at all. Age assurance is listed under In-App Controls, and in the global tables it sits in the 4+ band alongside Parental controls. Building an age check into your app does not raise your rating by a single tier. That removes the only real argument for leaving the check out, which is usually a worry about losing a low rating that reads well on the product page.

Apple, age ratings values and definitions, read 14 October 2026

Does Apple check your customer's age for you?

In three countries, for the download only. Apple has announced that from 24 February 2026 it blocks users in Australia, Brazil and Singapore from downloading apps rated 18+ unless they have been confirmed to be adults through reasonable methods, and that the App Store performs that confirmation automatically. That is the install, not the order. Everywhere else, and at every rating below 18+, nothing has been checked by the time your first screen appears.

What you get instead is a signal you can act on. The Declared Age Range API arrived in iOS 26 and iPadOS 26. Your app asks for an age range and the answer is a band or a category, depending on what the law in that region requires, rather than a date of birth. Apple's Q&A says the response also carries the method used to confirm the band or category, whether parental controls are enabled, and whether the person is eligible for age-gated features. The eligibility and verification-method fields came in iOS 26.2, and building against them needs the 26.2 SDKs or later.

The part to design around is that the person decides. Apple's wording is that people using your app can decide whether their age information is shared. From iOS 26, parents and guardians can use Age Range for Apps to allow or require children in their Family Sharing group to share age ranges with apps and games, or decline to allow sharing. Adults and teens outside a Family Sharing group choose as well. So your code has three branches, not two: a range, a refusal, and a device that cannot answer because nobody is signed in. Apple also notes that existing accounts running iOS 18 or earlier are not affected, which is a polite way of saying an older phone gives you nothing.

On whose problem this is, Apple is blunt. Developers are responsible for their own age restrictions. In regions where a check is legally required, Apple says you must check the age of the people using your app with that API, and that this holds even when your app is already rated 18+. For anything beyond that it tells you to consult your legal counsel, which is the right answer rather than a dodge, because the rules that bite are local and they are not Apple's.

Apple, age assurance developer Q and A, read 14 October 2026

Where in a booking flow does the age check belong?

Not on the first screen, if you can avoid it. A wall at sign up is the highest friction place to put one and it protects the least. The person has not asked for anything yet, so a wrong answer costs them nothing and they will type whatever gets them through. Put the check against the restricted thing. A salon app that offers haircuts and one laser treatment with a minimum age should ask on the treatment, not at the door, and the person booking a trim should never see it.

The order of operations that survives contact with real customers: pick the service, hold the slot, check the age, take the money. Checking before the slot is held wastes the check when the slot has gone. Checking after payment means refunds, and refunds on a restricted order mean a conversation. If you are holding a slot while a check runs, hold it for a minute or two and then release it, the same way you would for a card sitting in a bank's verification step. Bookings that write through to a staff diary need care about calendar sync for the same reason, because an appointment that reaches the rota before the check clears is an appointment somebody will work.

The payment step is one place Apple makes the decision for you, and it helps. Guideline 3.1.3(e), read on 14 October 2026, says that if your app enables people to purchase physical goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments, such as Apple Pay or traditional credit card entry. A bottle delivered to a door and an appointment kept in a chair are both consumed outside the app. So the check and the charge both live in your code, and you decide the order they run in, with no store billing sheet appearing in the middle of it.

For goods that get handed over, the real check happens at handover and your app's job is to flag it. Nothing anybody taps on a phone confirms who takes the parcel. Mark the order as age restricted, print that on the picking list and the delivery note, and make the courier or the counter staff look at a document. The app's contribution is that the person on the van knows before they knock.

All of this gets sharper if you are building an appointment calendar app that several businesses use, because the minimum age is a property of the service, not of the app. Store it on the service record, let each business set it, and default it to none. A hardcoded eighteen in your checkout is a bug waiting for your first client who rents bouncy castles, and a second one waiting for the tattoo studio whose local rule is sixteen with a guardian present.

One more thing Apple puts on your side of the line. Its Q&A says you are responsible for preventing access to your app or features when required, and for handling the response from the parent or guardian. Blocking is your code. The API tells you what it knows and then stops.

Apple, age assurance developer Q and A, read 14 October 2026

What happens when the check says no?

A refusal needs a path that is not a dead end. Take the three branches one at a time. A refusal on one 18+ service does not have to log somebody out of the whole app. It can hide that service and leave the haircuts, the gift cards and the order history working. A device that cannot answer is not a refusal, and treating it as one locks out everybody who is not signed in with an Apple Account, which is a support ticket you will not enjoy reading. A range that comes back below the minimum is the only one of the three that is actually a no.

Consent can also be withdrawn after you have let somebody in. Apple's Q&A says that when a parent or guardian revokes consent for their child to access an app, Apple will prevent the app from launching, and tells you to handle it with the RESCIND_CONSENT value from notificationType. So age state is not a flag you set once at sign up and trust forever. It is something that can change underneath an account that already has a saved card and a standing booking.

Then the rule that no verification gets you past. App Review Guideline 1.4.3, read on 14 October 2026, says apps that encourage consumption of tobacco and vape products, illegal drugs, or excessive amounts of alcohol are not permitted, that apps encouraging minors to consume any of these will be rejected, and that facilitating the sale of controlled substances, except for licensed pharmacies and licensed or otherwise legal cannabis dispensaries, or tobacco, is not allowed. There is no age rating in front of that last clause. A vape shop app is not an 18+ listing on the App Store, it is a rejection. Find that out before you build the gate, not after.

There is one failure on the rating side worth knowing too. Unrated is a real value in Apple's table, and Apple says an Unrated app cannot be published on the App Store, though it may be published on alternative app marketplaces or websites. Two answers produce it: infrequent or frequent graphic sexual content and nudity, and infrequent or frequent prolonged graphic or sadistic realistic violence. If your calculated rating comes back Unrated, you do not have an age gate problem. You have a content problem, and a gate will not solve it.

Apple, age ratings values and definitions, read 14 October 2026