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, when offline-approved inventory is published, is a
separate Premium path: five one-hour shots download by default and the
device may retain up to twelve hours. Each shot keeps its schedule and
verified layered audio in the app sandbox. Only items marked
approvedOfflinemay enter it; 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.