A permission with the same name does not grant the same capabilities on every OS

What it is

Dialogs that all say "Location," "Photos," or "Bluetooth" do not open the same hardware and data on every OS. The capability coverage of a same-named permission is defined by the platform. Location on one system once bundled Wi-Fi and Bluetooth scanning; another splits location, Bluetooth, and nearby devices into three doors. Photos on one system is the whole library; another can grant add-only, or only the items just picked. Treating aligned names as aligned capabilities over-asks on one end and silently fails on the other. This entry is the coverage mismatch. It is not whether the ask happens at install or at use, not whether a denial can be followed by another prompt, and not how a cross-platform framework collapses status enums to one value.

Why it happens

A permission is a row in the OS access-control table. Rows evolve with OS versions, not with a product's feature list. Photos on one system means read all media; on another it splits into read images, read video, a limited picker, and append-only. Tapping Allow on both ends lets one app build smart albums and the other write only the shot it just took. Location's while-using versus always, precise versus coarse, are not the same set of rungs on every OS. Where a rung is missing, the app either widens the permission or degrades the feature. Bluetooth is the sharp case: scanning for a nearby accessory needs a Bluetooth permission on one OS and historically rode on location on another. A port from the latter keeps asking for location. People see a flashlight asking where they are; they deny; the accessory breaks; both sides feel the other is being unreasonable. The mismatch lives in the grant table, not in copy polish.

Where it stops holding

Coverage also shifts across major versions of the same OS (a library going from bulk read to a picker). "Android versus iOS" is not the only axis; draw the table against the minimum version the product claims. A capability that exists on only one end (tracking transparency on one, file-tree access on another) has no same-named peer. Align the user task, not the permission name. A WebView or mini-program nested in a host inherits the host's coverage, not a separate inner manifest. Desktop often treats the file system as available by default and has no "photos permission" row; the mobile coverage table does not paste.

Applying it

• For each user task, write a per-platform capability table: which permissions "scan for a nearby accessory" or "pick one photo" actually require, and which APIs each permission opens. A single permission name is not a table.
• When one end is narrower, degrade to what that end actually opened (the system picker, not a walk of the library). Do not backfill with a wider permission that happens to share a name.
• Verify by granting the same-named Photos or Location permission on two systems, then listing the APIs the product actually calls. If one end walks the whole library and the other only receives the picker item, coverage has already forked—explanations and failure copy have to be written per end.

Related

• Within the group: K1.12.1 Permissions may be granted at install or asked at the moment of use · K1.12.3 After a denial, whether the app may prompt again is platform-specific · K1.12.4 A cross-platform app cannot treat one permission model as universal
• Adjacent: O2.01 Information design of permission prompts
• Search terms: permission scope · while using location · limited photo library