QuickCast and Your Privacy: Exactly What Leaves Your Device
QuickCast was built as a privacy-conscious capture-and-delivery tool: record a voice note, and ship it straight to infrastructure you control. No accounts, no cloud middleman, no AI service in the loop unless you put one there.
That’s easy to say. This post is the technical version — a behavioral map of every byte that can leave your device, when, and what’s in it. If you’re evaluating QuickCast for sensitive material (journaling, client notes, dictation), this is the document to read.
The core principle: there is no QuickCast backend
QuickCast has no server that receives your content. We do not operate an API that your recordings pass through. When you send a recording, it goes directly from your iPhone to the webhook URL you configured — Slack, an n8n or Zapier flow, your own server, a self-hosted endpoint on your home network, wherever.
That means:
- We cannot see your recordings, because they never reach us.
- We cannot store your transcripts, because they never reach us.
- We have nothing to breach, hand over, or leak on your behalf, because we hold none of it.
Your recordings, transcripts, webhook URLs, headers, and settings live in the app’s private on-device storage and stay there until you send them somewhere.
On-device transcription, strictly enforced
QuickCast’s live speech-to-text uses Apple’s Speech framework. As of version 1.6.0, the app explicitly requires on-device recognition and will not fall back to Apple’s server-based recognition.
Concretely:
- Audio is transcribed on the iPhone itself. No audio is sent to Apple — or anyone — for transcription.
- It works fully offline. You can put the phone in Airplane Mode, record, and watch the transcript appear in real time. (That offline test is itself the proof: server-based recognition simply cannot work without a network.)
- If a particular language or device can’t do on-device recognition, transcription is disabled rather than silently shipping your audio off-device as a fallback. The privacy guarantee holds even in the edge case.
Transcripts are stored locally alongside your recordings and are only ever transmitted as part of a webhook upload you initiate.
The only three things that ever use the network
We audited every network call in the app. There are exactly three, and you control all of them:
1. Webhook delivery (the one you asked for)
When you send a recording, the app uploads it to your configured endpoint. This is the whole point of the app. Nothing about this is hidden: it goes to the URL you typed, with the headers you set.
2. Anonymous usage analytics — opt-in, off by default
To understand which features get used, QuickCast can send anonymous events to Aptabase, a privacy-focused, EU-hosted analytics service. This is off by default; the first-launch onboarding asks you explicitly, and you can change it any time in Settings → Privacy → Anonymous Analytics.
What an event contains: a name like recording_started, a coarse duration bucket (short / medium / long), an HTTP status code, and app/OS version. A rotating session ID (a fresh UUID that resets after an hour of inactivity) ties events in a single session together and is never linked to you.
What it never contains: audio, transcripts, webhook URLs, headers, tokens, filenames, or request bodies.
3. Crash & error diagnostics — opt-in, off by default
To find and fix bugs faster, QuickCast can send non-fatal error reports to Sentry’s EU region. This is also off by default and lives under Settings → Privacy → Crash & Error Diagnostics. We’ve also configured Sentry not to store IP addresses.
What a report contains: a short trail of generic in-app actions (“breadcrumbs”) like recording started or Siri stop received, the type and message of an error, and device/app version.
What it never contains: audio, transcripts, webhook URLs, headers, tokens, filenames, or request bodies.
When both toggles are off, the app makes no network requests other than to your webhooks. Full stop. The analytics and diagnostics clients short-circuit before building a request — they don’t even construct one.
The webhook request format
For people sending to their own servers, here’s exactly what to expect on the wire.
Audio upload (multipart):
- Method: configurable per webhook (default
POST;PUTandGETalso supported) - Content-Type:
multipart/form-data; boundary=----QuickCastBoundary<uuid> - Audio part: form field
audio, withfilename="<recording>.<ext>"and a per-format content type (audio/m4a,audio/wav,audio/aac,audio/mpeg,audio/flac,audio/ogg) - Transcript part: a separate form field, included only when transcription is enabled and non-empty; the field name is configurable per webhook (default
transcript) - Custom headers: any headers you define are sent as-is — this is where authorization tokens go
- Metadata: none beyond the parts above; no hidden device or identity fields are added to the body
- Success: any HTTP
2xxis treated as success
Text-only send (no audio): JSON body {"<your-field>": "<text>"} with Content-Type: application/json (default field name text).
Offline queue and multi-destination delivery
If your server is unreachable, the recording is added to a persistent on-device queue and the audio is kept locally. The app retries automatically with exponential backoff and resumes when connectivity returns. If retries are exhausted, the item is marked failed but kept so you can resend it — nothing is silently dropped. There’s no fixed cap on the number or size of queued recordings; the queue is bounded only by your device’s storage.
When you fan out one recording to multiple webhooks, each destination is tracked independently. Destinations that succeed are marked delivered; any that fail can be retried on their own. A failure to one endpoint never costs you the recording or the ability to redeliver to the others.
Sending to your own infrastructure (including Tailscale)
QuickCast uses the system networking stack with standard DNS resolution, so private endpoints — including Tailscale MagicDNS names and *.ts.net addresses — resolve and connect normally. One requirement worth calling out: the app enforces Apple’s standard App Transport Security, so your endpoint needs a valid TLS certificate. Tailscale’s built-in HTTPS certificates (tailscale cert) are publicly trusted and work automatically; a self-signed certificate would be rejected. Use a Tailscale-provisioned or otherwise publicly-trusted cert on your gateway and you’re set.
This is, frankly, our favorite way to use the app: iPhone → your private network → your own machine, with absolutely nothing in between.
In one sentence
Your audio and transcripts only ever go to endpoints you configure; transcription happens on your device; and the only other network traffic is optional analytics and diagnostics that are off by default and never contain your content.
If you have a specific technical question we didn’t cover here, get in touch — we’re happy to go deeper.