Exercise 3: Why PhotosPicker's No-Info.plist-Key Design Is Deliberate, Not an Oversight — Possible Solution
===================================================================================================================

Location and camera access both genuinely require an Info.plist
usage-description key because the app itself is granted real, ongoing,
broad access to a genuinely sensitive real capability once the user
approves the request - continuous location updates, or full real
camera control - which is exactly the kind of powerful, potentially
privacy-invasive access a user reasonably deserves a specific,
explained reason for before granting it at all.

PhotosPicker's own real, underlying mechanism is structurally
different in a way that removes that same specific privacy risk
entirely: per the chapter's own finding, it runs as a genuinely
separate, sandboxed SYSTEM process, not code running inside the app's
own process boundary at all. The app itself never actually gains
broad access to the user's full photo library - it only ever receives
the exact specific image (or images) the user personally selected and
handed over through that separate system interface. There is no real
broad grant of access happening here at all for a usage-description
string to meaningfully explain or justify in the first place.

This is precisely why Apple's real design choice makes sense rather
than looking like an inconsistency: the usage-description requirement
exists specifically to make a user pause and understand what BROAD
access they're about to grant. PhotosPicker was deliberately engineered
so that no such broad grant of access ever actually occurs - the
user's own act of picking a specific photo IS the entire real consent
event, functioning much like choosing a specific file to open, rather
than a location or camera-style app-wide permission grant needing its
own separate, explained justification beforehand.

ANSWER: Location and camera access require an Info.plist key because
approving them grants the app real, ongoing, broad access to a
sensitive capability that genuinely needs justifying in advance.
PhotosPicker needs no such key because it was deliberately engineered
to run as a separate, sandboxed system process that never grants the
app broad photo-library access at all - the user's own act of picking
a specific photo already IS the real consent event, so there's no
broad access grant left for a usage-description string to meaningfully
explain.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains the real underlying reason usage-description keys exist
(justifying a broad access grant) and shows why PhotosPicker's own
sandboxed design structurally removes the exact condition that
requirement exists to address, rather than treating the exception as
arbitrary.