iOS 27 gives Apple, and a growing stack of regional laws, a formal way to tell your app how old a user is before you collect data on them. If your app gathers anything from minors, and most consumer apps do without thinking of it that way, the way you request consent and document what you collect has to change. Not eventually. For a growing list of regions, now.
This is a compliance topic, so one caveat up front: this article is a practical orientation for marketing and product teams, not legal advice. Your obligations depend on where your users are and what your app does, and a lawyer should sign off on the specifics. What this guide does is map what iOS 27 introduces, what it means for the tracking and segmentation your team relies on, and a checklist to work through before the App Store gate tightens. Pushwoosh is a customer engagement platform, and where consent and data collection touch what you configure with us, we point to it.
What iOS 27 actually introduces
Two APIs sit at the center of this, and they work together.
The Declared Age Range API lets your app request a user’s age band, for example 13+, 16+, or 18+, without ever asking for or storing a birthdate. Apple supplies the range; you get a signal, not a date. The framework has been available since iOS 26, and iOS 27 is where the surrounding requirements and enforcement harden.
PermissionKit handles the parental-consent side. When your app makes a significant change that affects how a minor uses it, PermissionKit is the flow that informs the user and, in regulated regions, requests a parent or guardian’s approval before the minor continues.
The important design point: the system tells you when this applies. Through signals like isEligibleForAgeFeatures and requiredRegulatoryFeatures, the OS indicates whether age obligations apply to a given user and whether you need to request the age range or parental consent. You are not guessing per user. The platform hands you the applicability.
The part the “mandatory in September” headlines get wrong
It is worth being precise here, because the obligation is not a single global switch, and “mandatory in September” is not something Apple actually says. There are two separate things going on, and coverage tends to collapse them into one deadline.
The first is the App Store review gate. Apple has been steadily tightening what your privacy documentation and age handling have to show, and apps with social or user-generated-content features are expected to implement a user-facing age gate backed by the Declared Age Range API. This tightens through the iOS 27 cycle rather than flipping on one dated morning, but if your app has social features, treat it as work to finish before your next release, not after.
The second, and the one with hard dates, is regional law, and it is already live in places. Apple itself ties the Declared Age Range obligations to specific jurisdictions: age categories are shared for new Apple Accounts in Utah as of May 6, 2026 and Louisiana as of July 1, 2026, and Apple began blocking 18+ downloads in Australia, Brazil, and Singapore on February 24, 2026. Other laws are on their own timelines, some already in force, some moved. The system’s regulatory signals exist precisely because the answer to “do I have to do this for this user” depends on their region and the current state of that region’s law.
The practical reading: if you have social or UGC features, or you collect data from minors in any regulated region, this is live work, not a future item. If neither applies to you yet, keeping your privacy documentation current is still expected, and the regional map is expanding, so building the capability now is cheaper than retrofitting it under a deadline later.
Why this lands on marketing, not just legal
Age assurance looks like a legal-and-engineering task until you follow what it touches. Then it lands squarely on how you track and segment.
If you collect advertising identifiers, fire automatic behavioral events, or build segments on in-app activity, an age signal changes what you are allowed to gather and about whom. A user in a protected age band is not someone you can quietly enroll in the same behavioral tracking and ad-ID collection as an adult. The moment the OS can tell you a user is a minor in a regulated region, “we track everyone the same way” stops being a defensible default.
This is also the moment to close a gap many apps have been carrying: unclear or undocumented handling of advertising IDs (IDFA on iOS, GAID on Android). If your data documentation does not clearly state what advertising identifiers you collect and why, that gap was already a liability. As the review gate tightens through the iOS 27 cycle, it becomes a rejection risk. Fixing the age-collection story and the ad-ID documentation in the same pass is the efficient move, since they live in the same privacy disclosures.
Your compliance checklist
Work through these with your legal and engineering partners:
- Map where your minors are. Identify which regions you operate in that have live age-assurance laws, and whether your app has social or UGC features that trigger the App Store gate regardless of region.
- Adopt the applicability signals. Use the OS signals that tell you whether age obligations apply to a given user, rather than building your own guesswork. Let the platform tell you when to request an age range or consent.
- Request the age range, not the birthdate. Where you need an age signal, use the Declared Age Range API so you get a band and never collect or store a date of birth you would then have to protect.
- Wire up parental consent for significant changes. If minors use your app, make sure the significant-change consent flow is in place for the regions that require it.
- Segment tracking by age band. Ensure users in protected age bands are excluded from advertising-ID collection and behavioral tracking that is not permitted for minors. This is a data collection and consent configuration, not a manual review per user.
- Update your privacy documentation. Bring your App Store privacy disclosures current, and while you are in there, close the advertising-ID documentation gap so IDFA and GAID handling is clearly stated. This is the item the review gate checks first.
- Review your consent copy. Make sure the consent language a minor or guardian sees matches what you actually collect, in the same spirit as your GDPR consent practices.
Handle age-aware data collection cleanly with Pushwoosh
Pushwoosh gives you consent management and data-collection controls to segment tracking by age band, exclude protected users from collection they should not be in, and keep your advertising-ID handling documented and clean. Compliance work is never zero effort, but the data side of it should not be the hard part.
