On 9 September 2026, four companies started checking the age of Australian users before letting them download an app rated 18+. They picked four different methods. None of the four tells you which one your user passed.
That second sentence is the whole problem, and it is going to be misread for the rest of this year as good news.
The reading that is about to spread through product and compliance teams goes like this: the storefront now verifies age at the door, our app sits behind that door, so the hard part is handled. It is a reasonable-sounding inference and it is wrong in three separate ways. The gate is keyed to a rating that is frequently incorrect. The code that binds the storefront is not the code that binds your service. And the result of the check never crosses the boundary into anything you can hold, audit or produce.
What actually switched on
Australia’s Age-Restricted Material Codes are nine industry codes made under the Online Safety Act. Industry bodies drafted them. The eSafety Commissioner assessed them, found they gave appropriate safeguards, and registered them, which is what makes them enforceable.
They arrived on a ladder of dates rather than all at once:
| Date | What started |
|---|---|
| 10 December 2025 | The separate under-16 social media minimum age took effect |
| 27 December 2025 | Internet carriage, hosting and search engine codes commenced |
| 9 March 2026 | Social media, messaging, designated internet services, app distribution and equipment provider codes took effect |
| 27 June 2026 | Search engines had to have logged-in age assurance running |
| 9 September 2026 | App distribution services had to check age before enabling 18+ downloads |
The app distribution code was registered in September 2025 and took effect in March 2026, but the age assurance obligation inside it carried an extra six months of lead time. That is the deadline that passed on 9 September.
The penalty is not symbolic. If eSafety finds a service is not complying and issues a formal direction, breaching that direction can attract a civil penalty of up to A$49.5 million. Hold that number. It matters again in a moment.
Four storefronts, four different answers to the same question
The codes are deliberately technology-neutral. eSafety’s own guidance says the method is up to the service, so long as it meets the definition of appropriate age assurance and complies with the Privacy Act. Four companies read that same sentence and built four different things.
| Storefront | Method chosen | What a developer receives |
|---|---|---|
| Apple App Store | Account signals. Declared profile age, whether a payment method with purchase history is attached, whether the account is a child account under Family Sharing. Announced in February 2026 for Australia, Brazil and Singapore. | Nothing tied to the download decision. Separately, the Declared Age Range API can return a coarse bracket if the user or a parent chooses to share one. |
| Google Play | The Play Age Signals API, running on top of Family Link. Brazil first, then Australian and Canadian users from the middle of August 2026, with a worldwide developer rollout following. | An age bracket, but only where a parent has chosen to share it. No signal at all otherwise. |
| Microsoft Store and Xbox | Email confirmation via VerifyMy, or facial age estimation, credit card or document check via Yoti. Announced August 2026. Microsoft says the partners handle the images and documents and return only a completion result. | Nothing. |
| Steam | A credit card kept on the account. Debit cards are not accepted. No alternative method is offered. | Nothing. |
Read the right-hand column again. Three of the four give the developer nothing at all, and the fourth gives a bracket that is optional for the user’s parent to share.
The confidence levels behind those four checks are also nowhere near each other. Apple’s approach is inference from account history. A profile that has been buying music since 2015 with a card attached looks adult to it. A fresh account with no card looks like a minor. That is a sensible heuristic and it is not the same act as Yoti running a facial age estimate or reading a passport chip. If you find yourself writing “the app store verified them” in a compliance document, notice that the sentence is now describing at least two different things depending on which phone the user is holding.
We have written before about why an operating system age signal is not a verification and about the specific gap between Google’s Play Age Signals and Apple’s Declared Age Range. This post is about a different thing. Those posts are about the quality of a signal you receive. This one is about a gate whose output you never receive at all.
The rating underneath the gate is wrong
The store gate does not ask what your app contains. It asks what your app is rated. So the reliability of the whole mechanism rests on the rating being right.
In September 2025 the Sydney Games and Play Lab published research on exactly that question. Professor Marcus Carter and colleagues found that one in five of the top 100 games on Apple’s App Store carried the wrong Australian age rating, and 48% of the top 100 on Google Play did. Their companion paper, One Game, Four Age Ratings, found exactly one game in the sample with fully coherent ratings across the places it was listed. Eighteen games carried four conflicting ratings at once.
This matters for two groups of people, in opposite directions.
If you publish an 18+ app, the gate now stands in front of your download button and your install conversion just changed. You know that already, because your numbers told you.
If you publish anything rated lower, the gate does not stand in front of you, and that is the dangerous position. You are outside the store check because of a rating you assigned yourself, in a market where roughly a fifth to a half of comparable ratings in the top charts are wrong. Australia tightened its classification rules in September 2024 so that games with simulated gambling mechanics have to carry an R18+ rating. Plenty of titles were never reclassified. The penalty for a mislabelled app has been reported at around A$6,000. The penalty for breaching a direction under the codes is A$49.5 million. Those two numbers are four orders of magnitude apart and they are attached to the same underlying error.
A wrong rating used to be a listing problem. It is now the load-bearing input to a legal gate.
The app distribution code is one of nine
Here is the part that gets skipped, because it requires reading which code is addressed to whom.
The App Distribution Services Code binds app stores. It is one of nine. The codes for designated internet services, relevant electronic services and social media services each carry their own age assurance obligations for the age-restricted material those services make available. eSafety’s FAQ lists the service categories separately and describes the storefront duty as one layer among several.
So a download gate at the store does not discharge a service duty at your app. They are different obligations, addressed to different actors, about different moments.
Work through a concrete case. You publish a general-audience app rated 12+. It has user profiles, direct messaging, a media upload feature and an in-app browser. Nothing about it trips the store’s 18+ gate, so your Australian users install it with no check at all. But messaging and online chat fall inside the relevant electronic services category, and an in-app browser reaching adult material sits close to the designated internet services category. The store gate was never pointed at any of that. Your obligation for what happens inside your product did not move when the store put up a gate in front of your download button.
The same structure shows up everywhere else in the region, which is why we mapped the whole thing in four layers rather than eight separate laws. Australia is one of the few markets that genuinely leaves the method to you. Leaving the method to you also means leaving the responsibility with you.
The check fires once, at acquisition, against an account
Three properties of the store gate are worth stating plainly, because none of them match how a session-based product works.
It is scoped to acquisition, not to use. Microsoft said explicitly that games already purchased or downloaded stay playable regardless of whether the account has completed a check. The gate stands in front of a transaction. It does not stand in front of the tenth time someone opens the app.
It is bound to an account, not a person. A child signed into a parent’s Apple ID on a hand-me-down tablet is, as far as the gate is concerned, an adult with a long purchase history. That household setup is common, and it is the exact case the gate handles worst. We have written about this failure mode in general as the binding problem.
Its cadence is undefined. eSafety’s FAQ says some services may allow one-off checks that carry across future sessions or connected services, while others may require confirmation session by session. The regulator left that call to industry. Which means the store’s answer to “how long is this check good for” is a commercial decision made by Apple, Google, Microsoft or Valve, not a floor you can rely on. If your own re-verification design assumes the store re-checks, you are assuming something nobody has promised. Our post on age check expiry and re-verification cadence goes through how to set that interval deliberately.
The Steam lesson, which is about what not to copy
Valve’s implementation deserves attention because it is the cleanest example of choosing a method that satisfies a regulator and fails a large share of real adults.
To reach 18+ content on Steam in Australia you now need a credit card kept on the account. Not a debit card. Not a one-time check. The card has to stay attached. Without it, adult titles disappear from store pages, search results and recommendations.
Reporting on the change cited Finder research putting credit card holders at 12.1 million Australians as of July 2026, which is about 43% of the total population. Be careful with that figure, because the honest version is narrower: children do not hold credit cards, so the share of adults with one is meaningfully higher than 43%. It is still nowhere close to all of them. Debit-only banking is normal, and it is most normal among younger adults, which is to say among the users closest to the threshold you are trying to measure.
We wrote a whole post on why a credit card is not proof of age. Nothing about the Australian codes changes that argument. A card proves a bank was willing to extend credit to someone. It does not prove the person at the keyboard is that someone, and card ownership correlates with age rather than establishing it.
The design lesson is not “credit cards are bad”. It is that a single-method gate inherits the coverage of that method exactly. Every adult the method cannot reach is an adult you have locked out, and you find out about it through churn rather than through a compliance report. This is the same failure we covered in accessible age verification and in reducing drop-off.
What to build instead
Six rules. None of them require you to ignore the store signal, because ignoring it wastes a genuinely useful input.
Treat a store or operating system signal as a fast path, never as the gate. When Play Age Signals returns an adult bracket, or Apple’s Declared Age Range comes back clearly above your threshold, use it to skip a check for that session. That is the layered waterfall pattern, and it is what keeps the expensive path small. The signal earns you speed. It does not earn you a conclusion.
Never read an absent signal as adult. Play Age Signals depends on a parent choosing to share the bracket through Family Link. Apple’s bracket depends on the user or parent sharing it too. A missing signal means “I do not know”, and “I do not know” routes to your own check. Any code path where null falls through to the adult branch is a bug with a regulatory consequence.
Hold your own evidence. If eSafety, Ofcom or a court asks how you knew a particular user was an adult on a particular day, “the app store checked” is not a record you possess. Store the method, the outcome, the predicate you evaluated, the confidence, the policy version in force and the timestamp. A stored boolean cannot answer any of those questions six months later. We made the same argument about producing evidence under an information request, and Ofcom has now fined an operator specifically for failing to answer one.
Check at the point of access, not the point of install. Your gate belongs in front of the feature that carries the risk. Put it where the chat opens, where the upload happens, where the 18+ content loads. The store already showed you what an install-time gate covers, which is installs.
Fix your ratings. This is the cheapest item on the list and it is now load-bearing. Go and check your actual classification in every Australian storefront you ship to, especially if your app has anything resembling simulated gambling, loot boxes or a chance-based reward loop. A rating that was a marketing detail in 2023 is a compliance input in 2026.
Write down the reliance decision. Decide explicitly whether you are relying on the store’s check for a given surface, and record why, with the date. When someone asks in eighteen months why the age gate is where it is, the answer should exist as a document rather than as a memory. If the decision is “we are relying on the store and accepting the residual risk”, that is a legitimate answer. It just has to be a decision, not a gap.
How Xident is built for this
Three parts of our design matter directly here.
Every check produces a record, not a flag. A Xident result carries the outcome, the method that produced it, the predicate that was evaluated, the confidence, the policy version and the timestamp. When four storefronts are running four different methods at four different confidence levels, and your own check sits behind all of them, a flag cannot tell you which mechanism produced which outcome. A record can. That is the difference between answering a regulator’s question and reconstructing a guess.
The Check and Verification split is what makes a fast path worth building. A Verification is the document path, with optical character recognition and a face match. A Check covers browser-based age checks, liveness, returning-user Xident ID lookup and OAuth. On our Growth plan those are 0.20 EUR and 0.02 EUR, a factor of ten apart.
That gap is the entire economic case for using store signals as a fast path. Most sessions resolve on the cheap side. Only the users near your threshold, or the ones whose device gave you nothing, reach the expensive one. If your vendor bills a single blended rate per call, the layering saves you nothing and there is no commercial reason to build it.
The free sandbox lets you exercise the failure branch first. It grants 1,000 Checks and 100 document Verifications as one-time allowances rather than a monthly quota. The 100 Verifications exist so you can run the document path end to end, including the case where the document fails, before you pay for anything. The branch you most need to have tested before an Australian launch is the one where the store signal is absent and your own check has to carry the decision alone.
The short version
Four storefronts started checking Australian ages on 9 September 2026 using four methods of unequal strength, and all four kept the result. The gate they built stands in front of a download, keys off a self-assigned rating that is wrong on a fifth to a half of comparable top-chart titles, fires once per account rather than per session, and produces no artefact you can hold.
None of that makes the store check worthless. It makes it a signal. Signals are useful inputs to your decision and terrible substitutes for it.
The date to plan against is not 9 September, which has passed. It is the first time eSafety issues a direction to a service that assumed the storefront had covered it, and the reply has to explain how that service knew the age of a specific user on a specific day. The answer will either be a record you kept or a sentence about what Apple probably did.
Xident provides age verification and age estimation infrastructure built around decision records rather than boolean flags, so a store signal, an estimate and a document check all leave an auditable trail in the same format. There is a cheap Check path for returning users and a separate document Verification path. The free sandbox includes a one-time allowance of 1,000 Checks and 100 document Verifications. Talk to us if Australia is on your roadmap.
