Catalog delivery

Where the content lives

For the shipped product, listening is server-backed, not “the whole catalog shipped inside the App Store binary.”

Production path (what users get at launch)

We publish a signed catalog (schedule + media object list) to object storage / CDN over HTTPS.
The app verifies an expiring channel descriptor with a pinned Ed25519 public key, then loads that publication.
The player downloads only the media needed for the current listening window into a content-addressed rolling cache on the device (hash + byte-count checked). This is progressive download / cached playback, not a public live radio stream and not an unbounded “keep the whole catalog forever” download.
Music beds stream into that cache; atmosphere and upcoming sparse transmissions are prefetched within budget. Default cache caps are small relative to a full day of catalog (on the order of hundreds of megabytes, not multi‑GB eager sync).
Offline Reserve packs, if offered, are a separate Premium path and may include only items marked approvedOffline. Online rights never silently imply offline rights.

Plain answer

Yes — production listening is server/CDN based. The app pulls scheduled files from our HTTPS media host into a verified on-device cache, then plays them locally with frame-exact scheduling. It is closer to “signed on-demand catalog + cache” than to Spotify-style interactive search, and not a live microphone uplink.

What is not production

Authentic Audition (development build): large local staged library bundled only in the special AuthenticAudition configuration for rights listening. Excluded from Debug/Release store builds.
Fixture mode: procedural test audio for engineering.

Current launch blocker

The delivery machinery is implemented and tested. A production channel URL, signing keys, CDN, and rights-accepted inventory are not configured yet — so a standard live build correctly shows an unavailable signal instead of playing unaccepted media.