A release deadline exposes the weak branch: the happy path has a verified range, while a denied permission leaves the product without a decision. Teams that code only the first branch often convert missing data into a false age claim.
Microsoft announced broader Windows age signals on September 8. The Windows Age API gives apps coarse ranges and verification state, with consent and account constraints that make unknown outcomes part of the main contract.
Read the Windows Age API contract as a set of states
Microsoft’s developer documentation defines five age ranges: Under 10, 10 to 12, 13 to 15, 16 to 17, and 18 or over. The API avoids exposing a birth date or exact age to the application.
GetUserAgeRangeAsync can return null. Treat null as no signal, not as an adult, a child, an unverified account, or a reason to repeat the prompt.
GetAgeVerificationStatusAsync adds context with Verified, Unverified, OptedOut, TemporarilyUnavailable, and NotApplicable. Keep that status separate from the range because verification and age answer different questions.
One feature boundary, six paths
- Range and verified: apply the documented age-aware feature rule.
- Range and unverified: use the product’s policy for an unverified signal.
- Opted out: honor the choice and continue with a bounded fallback.
- Temporary failure: preserve work and allow a later retry.
- Not applicable: use the non-age-aware product path.
- No range or denied access: show the fallback without an inferred age.
Microsoft says the feature now supports Microsoft accounts. Other account types can receive an administrator-defined default in managed settings. Record the account and policy context in test evidence without collecting extra identity data inside your application.
Ask at the moment of need
Add the userAccountInformation capability because the API needs it. Explain the feature decision before invoking the request, and name what changes if the user declines.
A game might ask before opening a social feature, while a learning app might ask before enabling classroom communication. An application should not request the signal on first launch when every reader receives the same experience.
Access can fail with E_ACCESSDENIED. Catch that error as a normal consent outcome, preserve the user’s current work, and offer the same fallback used for an opt-out. Repeated prompts can turn a lawful choice into coercion.
Design the fallback before the gated feature
A useful fallback preserves the core job. It can hide open messaging, limit discovery, ask for a family-managed path, or keep content in a general catalog. It should explain the limit without assigning an age to the person.
Do not use device model, school domain, typing behavior, installed apps, or purchase history to fill the gap. Those proxies expand data collection and can produce an age claim with no consent or reliable meaning.
Keep product rules on your server or in versioned policy rather than scattering age checks across controls. One evaluated decision can return a named capability set, and the interface can render that set without learning the raw range.
Cache the minimum result for the shortest period that supports the feature. Give the user a route to refresh or withdraw the signal, and invalidate cached policy when the account changes.
Test policy, consent, and account changes
Build a matrix for all five ranges, every verification status, null, access denied, and a thrown temporary error. Add Microsoft and local account states, plus an administrator default where your customer base includes managed devices.
Switch accounts while the app runs and after restart. The previous person’s signal must not survive into the next session, logs, analytics, local cache, or a shared classroom workstation.
Change a family or administrator policy, then confirm that the application refreshes its decision. A long cache can leave a child in an adult feature or lock an adult out after the source state has changed.
Test offline startup and service recovery. The interface should explain that the signal is unavailable, keep safe work accessible, and avoid inventing a status until Windows returns a result.
Audit analytics and support tools
Most analytics need the capability decision, not the age range. Record that a social feature opened under policy version 12 rather than shipping a range to every event, warehouse, experiment, and vendor.
Support staff need enough context to explain the path without seeing an exact age or guessing from account details. A diagnostic can show signal present, verification status, policy result, source time, and fallback reason with suitable access controls.
Microsoft’s Windows announcement says the capability reached Insiders from build 26220.9472 and is headed to broader availability. Gate rollout by OS support and observe null rates rather than assuming every Windows 11 device has the feature.
The Neyrotex Windows App SDK versioning guide helps pin runtime identity. Our Project Zenith guide covers a different desktop launch. Follow the Desktop hub for Windows platform work.
