A camera feature that works flawlessly in development, on a device the team has already granted permission on, can fail completely for a fresh install the moment a real user taps "Deny" — and if the app's only response to that denial is a native crash or a silently blank screen, the feature is broken for exactly the users a permissions system exists to protect. iOS and Android both require an app to declare, in advance, why it wants access to the camera, location, contacts, or sensors, and both require the user to explicitly grant that access at runtime — but the two platforms declare, request, and revoke that access through genuinely different mechanisms, and code written against only one platform's model reliably breaks on the other.
Getting this right matters beyond avoiding a crash: both app stores reject submissions with permission-usage strings that are missing, vague, or don't match what the feature actually does, and both platforms let a user revoke a previously granted permission at any time from system settings, which means "the user granted this permission once" is never a safe assumption to carry forward — every permission-gated code path has to handle denial and revocation as first-class, expected outcomes, not edge cases.
This lesson covers the two platforms' permission models side by side, how to request camera and sensor access correctly on each, and the specific pattern for building a feature that degrades gracefully rather than breaking outright when access isn't granted.
Analogy🏏Cricket
🏏 Think of it like cricket: A television production crew filming inside a dressing room for a behind-the-scenes documentary cannot simply walk in and start filming — they need explicit, specific consent from the board and the individual players, given in advance, for a clearly stated purpose, and that consent can be withdrawn by a player at any point even after filming has started. A player who agreed to be filmed during warm-ups did not thereby agree to be filmed during a private tactical discussion, and a production that assumed blanket consent from one narrow agreement would be violating the actual terms it was given. Just as consent is scoped to a specific, stated purpose and can be revoked at any time, an app's camera or sensor access is scoped to what the user was told it was for, in the permission prompt, and can be revoked from system settings at any moment after being granted. Just as a professional production crew has a plan for what happens when a player declines to be filmed — cutting to a different shot, not a frozen or broken broadcast — a well-built app has a plan for what the screen shows when permission is denied, not a crash or a blank camera view. The insight is that access to something sensitive is never a one-time, permanent grant — it is a specific, revocable, purpose-scoped agreement that has to be honestly requested and gracefully handled on every single use, not just the first one.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.