I’m trying to fully understand the purpose of the ageGates parameter in the AgeRangeService.requestAgeRange API.
The official documentation includes the following statement:
“The system may return geo-specific age ranges that override your provided age gates based on the person’s location and applicable regulations. When geo-specific ranges are required, the returned age range reflects regulatory requirements rather than the bounds of your age gates.”
Based on this, it seems that even if my app provides specific age thresholds through the ageGates parameter, the system may override those boundaries depending on regional laws or regulations, and return a completely different lowerBound / upperBound than what my age gates would suggest.
My current understanding is:
ageGates indicates the thresholds my app uses to define its internal feature tiers,
but the actual age range returned by the OS is determined by legal or regional requirements (e.g., COPPA, GDPR-K, AADC, SB2420),
meaning the returned age range may not align with the age ranges implied by my ageGates values.
I’d like to confirm whether this interpretation is correct.
Additionally, if different regions may produce different lowerBound / upperBound values due to regulatory requirements, then it seems that:
developers shouldn’t rely on fixed age buckets, and
instead must implement feature gating logic dynamically based on whatever age range the OS returns.
So my questions are:
Is my understanding correct that ageGates is simply a hint that describes my app’s tier thresholds, and the OS may override those boundaries to comply with local regulations?
If lowerBound / upperBound can vary across regions, what is the recommended way for developers to design their feature-gating logic? Should we avoid hardcoded age buckets and instead build flexible logic that adapts to whatever range the OS returns?
I’d appreciate clarification so I can design our age-based policies appropriately and in a regulation-compliant way.