Why does my age-restricted app keep failing App Store review under the Online Safety Act?

You add a birthday picker to satisfy the regulator, watch signups drop, and App Review rejects the build anyway. Age verification on iOS is three separate jobs, and a birthday picker is bad at all of them. A date a user types in for themselves is not the assurance Apple wants, it does not meet the legal standard the Online Safety Act sets, and it cost you conversion on the way in.

Do these three problems have one fix? No. App Review, the Online Safety Act, and your signup funnel pull in different directions, and a single gate built for one of them tends to fail the other two. The rest of this is about why they diverge, and where the work goes once you stop treating them as one feature.

What does App Review check on an age-restricted app? ¶

App Review checks something narrow: does your content match its declared age rating, and is sensitive material gated at all. It is not auditing your legal compliance or measuring how effective your age check is, only pattern-matching the bundle against the rating you claimed. For an intimacy tracker like SilkSilkPrivate intimate wellness trackerView app, the age rating it carries and the health-and-wellness framing around the data do most of that work. Describe a private relationship journal as "adult content" in your review notes and you invite scrutiny the app does not need; describe the same data as sexual-health journaling and the rating falls out of the content rather than a reviewer's worst-case reading.

I went deep on that classifier in Apple's Problem with Bodies: the rating taxonomy still carries the silhouette of a 2009 system built for media you could point a camera at, and it has no native category for a private journal about bodies that is neither medical nor dating-adjacent. That is the lever App Review responds to, and pulling it is mostly a presentation job rather than an engineering one.

The Online Safety Act is a separate test with its own bar, and it does not care what rating Apple assigned. It wants a reasonable effort to keep minors away from risky material, and that is a legal judgment no single control settles. Ofcom's guidance on "highly effective age assurance" explicitly rules out a self-declared birthday as a method that clears the bar, but it does not oblige every app to collect passports either.^[1]1. Ofcom, "Guidance on highly effective age assurance" under the Online Safety Act 2023 - sets out the criteria a method must meet and lists examples (open banking, credit-card checks, photo-ID matching, facial age estimation) while explicitly excluding self-declared age. Where you land between those depends on what you expose and to whom, and it matters most for a UK-first listing. App Review can wave you through while you stay non-compliant; the regulator can be satisfied by a flow App Review never looks at. Confusing the two is the first mistake most teams make, and settling the distinction before you build the gate is far cheaper than rebuilding after a rejection or a regulator's letter.

Why does the birthday wall lose users and still fail the regulator? ¶

It loses users and fails the regulator because it collapses two layers, identity verification and access control, into one wall that satisfies neither.

Silk locks its entries on the device behind a PIN and biometrics through LocalAuthentication, evaluating deviceOwnerAuthenticationWithBiometrics on an LAContext before anything decrypts.^[2]2. LAContext.evaluatePolicy(_:localizedReason:reply:) with LAPolicy.deviceOwnerAuthenticationWithBiometrics - Apple's LocalAuthentication framework documentation for biometric gating of stored data. The entries are encrypted at rest with a key derived from the PIN via PBKDF2 and sealed with AES-GCM through CryptoSwift.^[3]3. Key derivation via PBKDF2 (PKCS5.PBKDF2) and AES in GCM mode through CryptoSwift, used in Silk's on-device EncryptionService - distinct from Apple's CryptoKit. That is access control: a cryptographic question about who opens data already stored on a device already in someone's hand. Age assurance answers a different question, a probabilistic one about a stranger deciding who gets through the front door before any account exists. Bolt the two together into a single birthday wall and you get a gate the reviewer waves through and the regulator does not, while real users bounce off it.

The case that breaks the naive flow is the adult who declines to give an age band. Declining is not being a minor, but a gate built as a binary treats it that way and turns away a paying customer without clearing the legal bar. A flow that handles "won't say" as a distinct state from "too young" is more work to design, and it gives you an assurance method Ofcom's effectiveness test would accept instead of a hostile signup form. This is where the funnel and the law collide: the flow that keeps the declining adult is also the flow Ofcom is more likely to accept, and the birthday wall fails the user and the regulator together.

There is an acquisition cost sitting under all of this, and it lands before a user ever sees the gate. The moment an app reads as adult-adjacent, Apple Ads pulls bidding on the terms that convert best, and paid discovery dries up for the people the app is for. So part of the work is honest presentation that keeps the listing under that classifier, and Apple widened the room for it in iOS 27: the new Product Page Header sits above your screenshots, search results carry their own visuals, and an Asset Library lets you submit those assets standalone and swap approved ones onto the header and search live without re-review.^[4]4. WWDC 2026, session 205, "Enhance your presence on the App Store" - Product Page Header and custom Search Results visuals in iOS/iPadOS 27, plus the Asset Library, where approved assets swap onto the header and search live without re-review. Custom Product Pages let you fork that framing per market, so a stricter jurisdiction reads more conservatively than a relaxed one. Some gating stays on the device too: Silk ships a calculator disguise that hides the tracker behind a working calculator until the right PIN is entered, deciding who can even see the app on a shared phone rather than answering an age check.

Which age-assurance signal actually clears the legal bar? ¶

No single signal clears it for every app, which is why a birthday picker is a category error rather than a weak implementation. Ofcom's framework judges a method by whether it is "highly effective" at the specific job of distinguishing adults from minors, and it lists examples (open banking checks, credit-card checks, photo-ID matching, facial age estimation) without mandating any one of them.^[1:1]1. Ofcom, "Guidance on highly effective age assurance" under the Online Safety Act 2023 - sets out the criteria a method must meet and lists examples (open banking, credit-card checks, photo-ID matching, facial age estimation) while explicitly excluding self-declared age. The method has to be proportionate to the risk your content actually poses, which means a wellbeing journal and a service hosting explicit user-generated media land in very different places even though both are age-restricted. Reaching for the heaviest possible check on a low-risk app is its own failure.

The trap underneath the method choice is data minimisation. Every assurance signal you collect is now personal data, and the Act sits alongside UK GDPR rather than overriding it, so a passport scan you store badly is a fresh liability you created in the name of compliance. The cleaner designs verify and discard, or push the check to a third-party provider that returns a yes-or-no token and never hands you the document. On-device estimation, answering "is this person plausibly an adult" without an identity document, is attractive for that reason, though it carries accuracy and bias questions you must defend if Ofcom asks. The proportionality of the signal, the retention rules around it, and where the check actually runs decide whether your compliance story holds, and none of those is settled by a control in the UI.

How do you gate content without bolting on a signup that never needed one? ¶

By separating the question of who can enter from the question of who has an account, and by gating at the narrowest point the content actually requires. Teams reach for a full account wall the moment a regulator is involved, because an account feels like the natural place to attach an age check, when it is the most expensive place to put one. The check belongs at the boundary of the restricted content, so if most of your app is not restricted, most of it should not sit behind a gate, with friction that tracks the risk of each surface.

This is the same reverse-engineering discipline I have written about when the platform refuses to state its rules: you infer the boundary from the cases that fail. The declining adult, the shared device, the UK user who needs a stricter flow than the US one each tell you where the gate should sit and what state it has to track. The under-built version treats age as a one-time boolean checked at signup; the version a regulator accepts treats it as a property of a session that can be re-established, declined, or escalated, which takes a small state machine to model. Designing that machine so it satisfies Ofcom, passes App Review on a sensitive-content listing, and does not strangle the funnel is the actual deliverable, and you cannot get there by working down a checklist.

Get those calls wrong and you find out in App Review or a regulator's letter, weeks later and far more expensively than a crash log would have told you. I have shipped the on-device half of this, with encrypted-at-rest tracking behind a biometric lock and a disguised entry point, and spent enough time inside Apple's content classifier to know which lever moves which outcome. If you have an age-restricted app on a deadline and a funnel you cannot afford to break, I take on age verification and compliance work for exactly this.