A mismatch between shown permission state and actual availability is misdiagnosed as a bug

What it is

The app says "Location is on" or "Notifications allowed," yet it cannot locate or receive—or the reverse: the feature works, the switch is drawn off. When the shown state and actual availability diverge, people diagnose a network fault, a broken account, a reinstall, not a permission to change. This entry is about display matching fact. It is not about whether to detect a Settings revoke (detection is how fact gets updated), and not about how in-use dots and settings rows divide labor.

Why it happens

People use the switch as diagnosis: on but unusable, so the fault must live in some other system. Three usual sources: a cache that was not refreshed; an in-app switch that only stores a product preference but is drawn as the system permission; the system is Once or Selected Photos while the UI paints Allow All. Once the cause is exported, the repair is wrong too: toggle network, clear cache, reinstall, while the permission sits still. Mismatch also hurts trust the other way: the feature works while the UI says off, so people infer collection without a grant.

Where it stops holding

When the system permission is on and the product also has a "pause notifications" preference, draw two rows: system grant, then product preference. Do not fuse them into one lying switch. If the permission is on but the hardware is unavailable (Location Services off in airplane mode, camera in use elsewhere), report hardware or occupancy; do not paint the permission row off. A second of refresh delay is acceptable; a lasting stale state is not.

Applying it

• Permission-row copy reflects only the system's grant enum (Allow / Deny / Once / Selected / Not determined). Product preferences get a second row.
• The feature's available state is bound to that enum: on system denial the entry degrades, and must not still show an "enabled" success state.
• The lifecycle that returns from system Settings must re-read and redraw; do not keep the screenshot-like state from before Settings opened.
• Verify with four combinations—system on/off × UI on/off. Ask uninvolved people to predict whether it works now and where to fix it if not. A prediction that disagrees with real availability, or a repair aimed at the network or a reinstall, means the display failed.

Related

• Within the group: H4.10.1 System in-use indicators and in-app permission entries do different visibility jobs · H4.10.2 When Settings revokes a permission, the app must detect it and degrade · H4.10.4 Unused permissions after first install should prompt a keep-or-drop review
• Adjacent: H4.03 Degradation after Denial · H3.02 Three Elements of Error Messages · H4.07 One-time vs Ongoing Authorization
• Search terms: stale permission UI · grant state mismatch · false affordance