I am integrating Declared Age Range into the initial release of an all-ages iPhone utility with an iOS 17 deployment target. It stores user-created records only on the device and has no app accounts, backend, in-app purchases, subscriptions or remotely accessible data. The planned distribution includes the United States.
On iOS 26.4 and later, the planned implementation checks AgeRangeService.shared.requiredRegulatoryFeatures and requests a range when .declaredAgeRangeRequired is present. On iOS 26.2–26.3, it uses isEligibleForAgeFeatures. Returned age information would be used transiently on-device, without persistence or export. A requested boundary of 18 would not restrict this all-ages app to adults.
Two technical points remain unclear:
The current Q&A says existing Apple Accounts on iOS/iPadOS 18 or earlier are unaffected. What supported fallback should an app use for affected new accounts on older supported versions, including iOS 26.0–26.1 without the eligibility property? When a required eligibility or age-range request temporarily fails, is there documented guidance for the access/retry behavior of an all-ages app? The documented notAvailable outcome can represent refusal or unavailability; the implementation should not misreport either as a completed check.
The Q&A says Apple prevents app launch after parental consent revocation and also directs developers to RESCIND_CONSENT App Store Server Notifications V2. For a utility with no server, app account or remote data/access to revoke, is any additional client action or notification endpoint required? If so, what technical mechanism should connect that action to the fully local installation?
I am seeking the documented API and system behavior, not a determination of legal compliance.
References:
Age assurance Q&A
Update for apps distributed in Texas
Requesting an age range
0
0
381