A cross-platform app cannot treat one permission model as universal

What it is

A shared cross-platform call to "request camera" cannot assume that return values, empty states, Settings paths, and the UI after failure are interchangeable across operating systems. Wrappers often crush each OS into allowed / denied and erase not-determined, restricted, one-time, and limited library. A product that writes its branches for one OS will, on another, see Allow still fail, Retry summon no dialog, or Open Settings land on the wrong page. This entry is the cross-platform assumption itself splitting. Timing, coverage, and re-prompt rules are why it splits; each of those already has its own page. Here the only claim is why "one logic everywhere" does not hold.

Why it happens

A cross-platform framework calls different permission managers through one API. When enums are aligned, restricted on one end is labeled denied, so the product draws "go to Settings and turn it on." In Settings there is no switch—the limit is a parent or a profile. One-time grant on one end returns to not-determined after the process dies, so the next cold start asks again. If the product stored one-time as "permanently allowed," the second launch skips the ask and then crashes or blacks out on the call. Deep-link schemes into Settings differ by OS; copying "open app settings" on a skin lands on an unrelated page. Some ends have no such permission at all (the capability is default-on, or does not exist). The wrapper still returns allowed, the feature cannot run, and the person scores a product defect. The damage is not one rule written wrong. It is one OS state machine used to interpret another OS's return value.

Where it stops holding

An app shipped to a single OS with a frozen minimum version does not need branches for platforms it does not have; adding a second OS or crossing a major version kills the assumption immediately. A pure web product runs the browser permission model, a third state machine, and cannot reuse a native wrapper's allowed / denied. A test fleet of one OEM and one major version will not catch a wrapper's bad mapping. A server cannot request device permissions on anyone's behalf; cross-platform consistency has to be split on the client, not declared as "permission OK" from an API.

Applying it

• Keep each OS's raw status under the wrapper. Write product branches for not-determined / allowed / denied / restricted / one-time / limited, not for a boolean.
• Accept each OS on its own: first ask, retry after denial, where Settings lands, one-time, restricted. A shared flowchart is allowed only up to "enter this OS's state machine."
• Verify the same cross-platform build on three systems: deny camera, then retry. Record whether a system dialog appears, whether Settings opens on the camera row, whether a one-time grant asks again on the next launch. If any end disagrees with the other two on what a button did, and the code has one branch, the assumption is still being used as a universal rule.

Related

• Within the group: K1.12.1 Permissions may be granted at install or asked at the moment of use · K1.12.2 A permission with the same name does not grant the same capabilities on every OS · K1.12.3 After a denial, whether the app may prompt again is platform-specific
• Adjacent: O2.01 Information design of permission prompts · K8.07 Consistency versus platform convention
• Search terms: cross-platform permission · permission status · restricted permission