The Online Safety Act and Your iOS App: Age Verification Explained for UK Founders

If you're reading this, someone has probably already told you your app might be in scope of the Online Safety Act. Maybe it was a lawyer, maybe it was a warning email from Apple, maybe it was a headline about Ofcom fines.

Here's the direct answer: if your iOS app lets UK users create accounts, message each other, share content, or access anything 18+, you almost certainly need proper age assurance in place now, not a checkbox that says "I'm over 18." Ofcom has already issued multiple six and seven-figure fines for exactly this gap, and the maximum penalty under the Act runs up to £18 million or 10% of global turnover, whichever is higher.

This isn't a legal briefing. It's what your build actually needs to look like, what Apple's tooling now handles for you, and what still sits on your development team's plate.

Quick Answer

• A self-declared "I'm over 18" checkbox is not compliant. Ofcom has explicitly ruled this out as insufficient for services that need "highly effective age assurance."
• Apple's Declared Age Range API (available from iOS 26.2, built with Xcode 26.2) lets your app request a user's age bracket from the device without collecting a birth date yourself. It helps, but it doesn't automatically make your app compliant on its own.
• You're most likely in scope if your app has user-generated content, direct messaging, social features, or 18+ material, and has a meaningful number of UK users.
• Retrofitting age assurance into an existing app typically touches onboarding, account creation, content gating, data storage, and your privacy documentation, not just a single screen.
• Ignoring it carries real financial risk. Ofcom has already fined multiple platforms into six and seven figures and has dozens of open investigations.
• This is a design problem as much as an engineering one. Get the UX wrong and you lose sign-ups at the door; get it right and it barely registers with users.

Does Your App Actually Need to Comply?

The Online Safety Act applies to any service that lets UK users encounter user-generated content, communicate with each other, or access certain categories of content, regardless of where the company is based. Size doesn't exempt you. Ofcom has fined operators with no UK office and relatively small user bases, on the basis that a "significant number of UK users" is what triggers the duty, not headcount or revenue.

You're likely in scope if your app includes any of the following:

• Social features: profiles, following, comments, direct messages
• User-generated content: posts, photos, videos, reviews, forums
• Dating, community, or social discovery functionality
• Livestreaming or user-to-user video
• Content rated 18+, including anything adjacent to adult material, gambling-style mechanics, or graphic content

You're less likely to be in immediate scope if your app is purely a single-player utility, a B2B tool with no user-to-user interaction, or content that's entirely first-party and non-interactive. Even then, it's worth a proper risk assessment rather than assuming you're exempt, since Ofcom's guidance covers a wider range of "user-to-user" functionality than most founders expect, including something as simple as a comments section.

If you're unsure, the honest answer is: get a proper compliance risk assessment done before you build anything, not after. This is exactly the kind of question that should come up in a discovery workshop before any screens get designed.

What "Highly Effective" Age Assurance Actually Means

This is where most existing apps fall short. Ofcom's standard for "highly effective age assurance" rules out anything that's easy to lie on. A checkbox, a dropdown asking for a birth year, or a "tick to confirm you're 18" toggle all fail this test because they rely entirely on self-declaration with nothing verifying it.

Methods Ofcom and the wider regulatory guidance generally treat as acceptable fall into a few categories:

• Photo ID verification, matching a government-issued document to the user
• Facial age estimation, using a live photo or video to estimate age
• Credit card checks, which imply adult status through financial verification
• Digital identity services, third-party providers that confirm age without the app storing the underlying ID
• Device or account-level signals, such as Apple's age range data, used as one input among others

The regulator's own framing is that assurance methods need to be accurate, robust against being tricked, reliable, and fair across different user groups. A method that works well for one demographic but is easy to bypass for another doesn't meet the bar.

For most apps, this means age assurance stops being a UI afterthought and becomes an actual system: a decision about which method (or combination of methods) you use, how you store the result, and how you handle edge cases like a user without a passport.

Apple's Declared Age Range API: What It Solves and What It Doesn't

Apple introduced the Declared Age Range API in iOS 26, and the version most developers actually need to build against requires the iOS 26.2 SDK and Xcode 26.2. It's a genuinely useful piece of infrastructure, and worth understanding properly rather than treating as a black box.

Here's how it works in practice:

• The API lets an app request a user's age bracket, typically under 13, 13–15, 16–17, or 18 and over, without ever receiving an actual birth date
• The real date of birth stays with Apple at the account level
• For under-18 Apple Accounts inside Family Sharing, a parent or guardian sets the range; adults set their own
• Users choose whether to share this once, always, or not at all, and the response is cached across their devices so they're not re-prompted constantly
• From iOS 26.4, Apple also rolled out its own age verification prompts at the OS level for UK users, which Ofcom has publicly welcomed as a positive step for child safety

What it doesn't do is remove your compliance obligation entirely. The API gives you a signal, not a certificate. If a user declares "16 and older" through Apple's system, that's a useful input, but Ofcom's standard is about the overall effectiveness of your assurance approach, not just whether you plugged in an Apple API. For apps handling higher-risk content, you may still need a dedicated age verification method (ID check, facial estimation, or a third-party provider) layered alongside the OS-level signal, particularly if your app also serves Android users where this API doesn't exist at all.

The practical upshot: Apple's API is the best default signal available on iOS right now, and it's free to integrate compared with a third-party verification vendor. But treat it as one layer of a proper age assurance strategy, not the whole strategy.

Is This iOS-Specific, or Does Android Need It Too?

The Online Safety Act itself is platform-agnostic. Your legal obligation exists regardless of whether a user is on iOS or Android. What's iOS-specific is Apple's tooling: the Declared Age Range API and the OS-level verification prompts are Apple's implementation, built to help developers on Apple's platform meet these requirements more easily.

If your app is cross-platform, you'll need an equivalent approach on Android, which currently means leaning more heavily on in-app verification (a third-party age assurance vendor, or your own ID or facial-estimation flow) since there's no directly comparable native signal from Google at the same maturity level as Apple's system. This is a common gap in scoping conversations: teams assume that solving it on iOS solves it everywhere.

What Actually Has to Change in Your App

This is the part legal guidance tends to skip. In practical terms, adding proper age assurance touches more of your app than most founders expect.

Onboarding and account creation. You'll likely need a new step where age is established, either through Apple's API, a third-party verification flow, or both. This has to happen early enough to gate access to restricted content or features, but late enough that it doesn't feel like an interrogation before someone's even seen your app do anything useful.

Content and feature gating. Once you know a user's age bracket, your app needs actual logic to restrict what they can see or do. This usually means new conditional rendering across feed content, messaging permissions, search results, and any user-generated content surfaces.

Data storage and retention. You now hold a new category of data (age assurance results, verification method used, timestamps) that needs a clear retention policy, secure storage, and a defensible reason for how long you keep it.

Data Protection Impact Assessment (DPIA). Because age assurance often involves processing sensitive data about minors, most UK legal advice will point you toward completing or updating a DPIA under UK GDPR before launch, not after.

Parental controls and appeals. If your app serves under-18 users at all, you need a route for correcting an incorrectly assigned age bracket and for parents to manage settings, which Apple's Family Sharing integration can partly support but rarely covers completely on its own.

App Store Connect age rating. Your declared App Store age rating needs to genuinely reflect your content and features, not just whatever rating was set at launch three years ago.

None of this is a weekend job on an existing app with real user data already in production.

Cost and Timeline: New Build vs Retrofit

If you're building a new MVP, designing age assurance in from day one is significantly cheaper than retrofitting it later. It's a handful of extra screens in your onboarding flow, a data model that already accounts for age brackets, and a content-gating layer built alongside your core features rather than bolted on afterwards. For a typical MVP, this might add a modest amount to your timeline rather than restructure it.

Retrofitting into an existing app with live users is a different job. You're now dealing with:

• Existing users who've never gone through any age check
• Content and messaging systems that were never designed with gating in mind
• A migration plan for how you handle the gap between "launch" and "everyone verified"
• Potential rework of your data model to store new verification data cleanly

Depending on the size and complexity of the existing app, this tends to land somewhere between a focused few-week sprint for a simpler consumer app, and a genuinely substantial project for a platform with deep social or messaging features. The honest answer for cost is: it depends heavily on how your existing onboarding and data layer were built, which is exactly why a proper technical audit before quoting a fixed number matters more here than on most feature requests.

What Happens If You Ignore It

Realistically, for a small UK app, the immediate risk isn't usually an overnight fine. Ofcom's enforcement pattern so far has generally followed a sequence: information requests, a compliance investigation, a formal warning, and then financial penalties if nothing changes. Several operators have avoided fines entirely by fixing their age assurance once flagged.

That said, the direction of travel is clear. Ofcom has already issued fines well into six and seven figures against multiple platforms for failing to implement effective age assurance, and it currently has a substantial number of open investigations running in parallel. The regulator has also shown it will pursue services with no UK physical presence, provided they have a meaningful UK user base, and has stacked additional penalties on top for failing to respond to information requests. Waiting until you get a letter is a materially worse position than being ready before you do.

There's also a less obvious cost: app removal risk. Apple can and does act on regulatory pressure around app compliance, and a UK compliance failure is the kind of thing that can jeopardise App Store availability in the region, not just trigger a fine.

Common Mistakes We See

• Treating this as purely a legal task. The legal risk assessment matters, but if it never reaches the development team as a concrete spec, nothing actually changes in the product.
• Bolting on a checkbox and calling it done. This is the single most common gap, and it's the one Ofcom has been most explicit about rejecting.
• Assuming Apple's API alone is sufficient. It's a strong signal, not a compliance certificate.
• Designing the age gate as a wall instead of a flow. A clunky, ID-heavy verification step dropped in front of onboarding kills conversion. Good age-gating UX asks for the minimum needed at the point it's actually needed, not everything upfront.
• Ignoring Android entirely. Solving it on iOS and assuming Android is covered by association.
• Forgetting the DPIA. Age assurance data is sensitive, and skipping the data protection paperwork creates a second compliance gap alongside the first.
• Not updating the App Store age rating to match what the app actually does once age-gating is live.

Should You Handle This Yourself, or Get Help?

If you're technical and your app is genuinely low-risk (no UGC, no messaging, no 18+ content), a straightforward Declared Age Range API integration might be something your in-house team can knock out directly from Apple's documentation.

For anything with social features, user-generated content, messaging, or 18+ material, this is worth treating as a proper scoping conversation before development starts. The reason isn't sales positioning, it's that the wrong call at the "which method do we use" stage tends to cascade into onboarding rework, data model changes, and design revisions later, all of which cost more to fix after launch than to plan for upfront.

This is exactly where mobile app development and UI/UX design need to work together rather than in sequence. Age assurance is a compliance requirement, but how it's presented to a new user in their first thirty seconds is a design decision with real conversion consequences.

FAQs

Does my app actually need to comply with the Online Safety Act?

If your app has UK users and includes user-generated content, messaging, social features, or 18+ material, you almost certainly need proper age assurance rather than a self-declaration checkbox. Apps with no user-to-user interaction and no restricted content have a much lower bar, but should still confirm this rather than assume it.

Is a self-declared "I'm over 18" checkbox enough?

No. Ofcom has explicitly stated that self-declaration doesn't meet the "highly effective age assurance" standard, since it's trivially easy to bypass.

What is Apple's Declared Age Range API, and does it solve compliance automatically?

It's an iOS feature (from iOS 26.2, built with Xcode 26.2) that lets your app request a user's age bracket without collecting their birth date. It's a useful, privacy-preserving signal, but on its own it doesn't guarantee you meet Ofcom's full standard, particularly for higher-risk apps.

How much does it cost to add age verification to an existing app?

It depends heavily on your existing onboarding flow, data model, and whether you're integrating Apple's API alone or combining it with a third-party verification vendor. New builds are considerably cheaper to design in from the start than retrofits into apps with live user data.

What happens if my small UK app doesn't comply?

Ofcom typically starts with information requests and investigations before moving to fines, but has already issued penalties well into six and seven figures against multiple platforms, with dozens of investigations open. There's also a risk to App Store availability if Apple acts on regulatory pressure.

Does this apply to Android apps too?

Yes, the legal obligation is platform-agnostic. Apple's Declared Age Range API is iOS-specific tooling, so cross-platform apps need an equivalent approach on Android, typically through a third-party verification method.

Should this be a discovery workshop conversation?

For anything beyond a simple, low-risk app, yes. Age assurance touches onboarding, data handling, and content gating all at once, and it's far cheaper to plan for upfront than to retrofit after a compliance gap is flagged.

Final Thoughts

The Online Safety Act isn't going away, and Ofcom's enforcement pattern makes clear this isn't a box-ticking exercise you can quietly defer. Apple has genuinely made the technical side easier with the Declared Age Range API, but the responsibility for getting age assurance right, both legally and in terms of user experience, still sits with you.

Done properly, this doesn't have to feel heavy-handed to your users. Done badly, it either fails to meet the standard Ofcom expects, or it becomes the reason people abandon your onboarding flow before they've even seen what your app does.

If you're not sure where your app stands, that's a conversation worth having before any development work starts, not after.

Not sure if your app is in scope?

We help UK founders work out exactly what the Online Safety Act means for their app, and build age assurance that meets the standard without wrecking onboarding. Let's talk it through in a Discovery Workshop.

Lets have a chat