Runtime permission
The OS popup asking to use your camera, mic, photos, or location, shown while the app runs. The user's answer sticks.
See it
What it is
Sensitive capabilities (camera, microphone, photos, location, contacts, notifications, health, motion) are gated by a dialog the operating system shows while your app is running. You do not draw it, you cannot restyle it, and the user's answer is stored by the OS. iOS has always worked this way and requires a usage-description string in Info.plist, which is the sentence printed inside the dialog. Android moved from install-time grants to runtime prompts in 6.0 and has been narrowing them ever since.
The answers are no longer a simple yes or no. Users can pick 'Allow once', 'While using the app', approximate instead of precise location, or a hand-picked subset of their photo library. Ask at the moment the need is obvious (tapping the camera button, not on launch), and write the usage string as a reason rather than a demand: 'Used to scan receipts so you do not have to type them' beats 'This app needs camera access'.
Gotcha: on iOS, treat the first ask as the only ask. Once someone denies a permission, that same basic request returns denied immediately with no dialog for the life of the install, and your recourse is a button that opens the app's page in Settings. That is why permission priming exists. 'Exactly one dialog per permission, ever' is a little too neat, though: some permissions have staged flows with more than one system surface, like escalating from when-in-use to always-on location, or reopening the limited Photos picker to let someone add more photos. Also design the degraded path: limited photo access and coarse location are normal outcomes, so the app should still do something useful rather than dead-end on a blank screen.
Ask AI for it
Implement runtime permission handling for camera and location in this app, as two independent flows with no shared state. Never request on launch: trigger each request from the action that needs it, after a short in-app priming screen that explains the benefit and offers 'Not now'. Write clear iOS usage-description strings stating the user benefit. For camera, branch on granted, denied, and restricted. For location, branch on the states that permission actually has: while using the app, allow once, precise versus approximate, and denied, and handle an escalation to always-on as a separate later request rather than part of the first ask. In both flows, re-read the current status instead of caching a boolean, and when the status says no further system prompt is available, show an inline explanation with a button that opens the app's Settings page. Re-check status on every app foreground, since the user can change it outside the app, and keep the feature usable in a reduced form when access is partial (approximate location should still do something useful). Do not add photo library permission handling unless I tell you the app reads the library; if I do, treat limited selection as its own outcome.