PRIVACY · 10 MIN READ
What happens to your audio after you press record
In Aurora the samples land in one directory on your own device (twice, before any model sees them), and the audio is removed after seven days. Here is the path, the file protection, the retention rule, and every network call the app is allowed to make.
Published · Updated
Does Aurora upload my recordings?
No, not to transcribe them. Aurora saves the recording on your device, where speech recognition, speaker separation, summaries and action items run without opening a connection. Through Aurora, the audio leaves the device in one case only, a diagnostic report you send with its recording switch turned on. Conversation sync, off until you turn it on, copies transcript text, never audio, to your own iCloud. As of October 2026, the audio is deleted after seven days while the transcript stays, so Aurora does not suit you if you want recordings kept for good or on your other devices.
Aurora saves the recording on your device before transcription begins. The models process it there, and after seven days the audio is removed while the transcript stays. You decide whether a diagnostic report takes a copy.
Most transcription products answer "what happens to my audio" with a privacy policy. A policy describes intent; the data path describes what is possible. This article traces the path Aurora actually takes: the directory the samples are written to, the format they are written in, the protection attribute set on them before the first byte lands, and the complete list of network calls the app is allowed to make.
On these figures. Every path, format, threshold and route below is read out of Aurora's own source, and each is stated with the file and commit it came from so it can be checked or contradicted. Figures marked device-confirmed come from process-kill tests on a physical iPhone and are provisional: they were measured to settle a design question, not published as a benchmark.
Where does Aurora write the audio while you are still speaking?
Aurora writes captured audio into a directory it owns inside the app's own container, one directory per session, while the recording is still running. The file is Apple Lossless in an .m4a container (16 kHz, mono, with a 16-bit depth hint) because live transcription and the later refinement pass both read the same canonical 16 kHz mono stream that the microphone path produces.
The session directory is created with the iOS data-protection class Apple calls complete-until-first-user-authentication, and the same attribute is applied to the audio file immediately after the writer opens and before any samples are written into it. That ordering is the point: a protection attribute applied after the first write would leave unprotected bytes on disk for as long as the write took.
| Artifact | Format | Where it lives | Protection |
|---|---|---|---|
| Session audio | ALAC in .m4a, 16 kHz mono | Application Support/sessions/<id>/<id>.m4a | completeUntilFirstUserAuthentication |
| Crash-recovery sidecar | Raw Float32 little-endian, 16 kHz mono | Same directory, <id>.pcm | completeUntilFirstUserAuthentication |
| Transcript and revisions | Local SQLite database | App container on the same device | App container |
There is no third location for the audio, and nothing is staged for upload: no network path takes a recording for transcription or storage. Through Aurora, the audio leaves the device in one case only, a diagnostic report you send with its recording switch turned on. The transcript can travel in the same report, and it has one more route if you choose it: conversation sync, which copies text, never audio, to your own iCloud. Both are in the list below.
Why does Aurora write the same audio twice?
Aurora keeps a second, dumber copy of the audio because the first one is not reliably readable if the process dies mid-recording. A fragmented MP4 that has not been finalized is only decodable up to its last completed fragment, and the encoder decides when that is. Aurora emits a fragment every 0.5 seconds and asks the writer to behave as a realtime sink, which caps the theoretical loss, and that still was not enough.
Two device-confirmed results drove the design. With the writer batching normally, a recording over a minute long came back as roughly 14 seconds after a hard kill. With realtime writes and half-second fragments, a killed session still recovered only a few seconds of audio. So every chunk is mirrored into a plain PCM sidecar (sample count is file size divided by four, with no container to repair), synced to disk about once a second by a worker that sits off the audio path, so disk durability can never stall sample ingestion. A clean stop deletes the sidecar, which makes its presence the crash signal: recovery prefers it only for sessions that actually died.
A recording that survives the crash is worth more than a transcript that was elegant right up to the moment the process was killed.
Aurora product principle 1: never lose the recordingHow long does Aurora keep the audio?
Seven days. A recording's audio is deleted from the device once its newest audio write is more than seven days old. The sweep that deletes it runs after launch and when Aurora comes back to the foreground, so expired audio goes on the next sweep rather than at the minute it turns seven days old. Audio of a session that is still open, or still waiting for refinement, is kept until that is done. Only the audio files are removed: the transcript, the summary and everything else made from the recording stay. There is no setting that changes this. The app says it in its own words: "Recording audio is removed after a week. Transcripts stay, and audio still being refined is kept until it's done."
Once the audio is gone, there is no recording left for a diagnostic report to attach, and the report form stops offering one.
Does Aurora's transcription make any network calls?
No. Recording, speech recognition, speaker separation, offline refinement, summaries, action items and Ask Aurora all run on the device that captured the audio, and none of them opens a connection to do it. Aurora is local-first rather than network-free, though, and the honest form of that claim is the list of paths which do exist, together with their defaults. Apart from an export you make yourself, only two of them can carry what was said: a report you send, which carries the session's transcript unless you turn session details off and its audio only if you turn the recording switch on, and conversation sync, which if you turn it on carries transcript text to your own iCloud.
| Path | What it carries | Default | Conversation content |
|---|---|---|---|
| Model download | Model files, fetched at setup and again when a model is added or changes | Runs at setup; on cellular, more than 100 MB waits for your consent; the small live speaker-separation model is exempt | None |
| Setup estimate and profile | Platform, device class, Low Power Mode, model generation; an aggregate estimate and preparation profile come back, with no identifier | On where configured, physical devices only | None |
| Update check | A request for this website's current-version file, with no identifier, cookie or credential | App Store installs at most daily, TestFlight at most every six hours; never in development builds | None |
| Settings and recording totals | Your settings, and each device's running recording time and number of recordings, in your own iCloud key-value storage | Always on; there is no switch | None |
| Conversation sync | Titles, transcripts, notes, summaries, chats and folders, to your own private iCloud database | Off, per device | Transcript text, never audio |
| Subscription check | A subscription-status request to RevenueCat, under its own anonymous app user id | When the main screen opens | None |
| Free-minutes ledger | The App Store's signed record of your copy of the app, kept by Aurora's service only as a pseudonym; a random installation id; the seconds each recording used | Free tier only: when the main screen opens, and when a recording starts and ends | None |
| Onboarding question | "How did you hear about Aurora?": your answer and the app version | Asked once at the end of setup on iPhone; Skip sends nothing | None |
| Usage metrics | Setup timings, and recording time and number of recordings in length ranges, with platform, device class, OS version and app build | Only after a yes; one answer covers both | None |
| Diagnostic delivery | An encrypted report you chose to send | You start it; session details starts on, the recording starts off | Session details unless you turn them off; audio only if you turn its switch on |
| Export or share | Whatever you exported | Nothing happens on its own | Whatever you chose to export |
Reading your calendar is not on that list because it is not a network path: Aurora reads your next event on the device and sends nothing anywhere for it.
Usage metrics are the row a privacy page is tempted to leave out. Aurora asks one question about them at the end of setup on iPhone, and once after setup, before the main window, on a Mac: whether Aurora can share anonymous usage data (setup timings, recording time and number of recordings) to help improve the app, never recordings, transcripts or anything that identifies you. The buttons are "Don’t share" and "Share and continue", and that one answer covers setup timings and recording time and counts alike. It is stored as three states rather than a boolean, because a boolean cannot tell "declined" apart from "never asked", and only an explicit yes lets a record leave; you can change it later under Privacy in Settings. The upload also requires a set of build-time approvals and a kill switch, every one of which defaults to off. The records carry no identifier, no text and no audio, and recording time leaves as a total and as counts in length ranges, never as the length of one recording.
The free-minutes ledger replaced the counter that used to sit in your iCloud storage. On the free tier, 20 recording minutes a month, the app asks Aurora's own service what is left when the main screen opens, when a recording starts and after it ends. It sends the App Store's signed record of your copy of the app, a random identifier for this installation, and for a recording a random id and its length in seconds. The service keeps the App Store record only as a pseudonym, not as an Apple identifier, and it never receives audio, transcripts or titles. Subscribers, development builds and copies not installed from the App Store or TestFlight never contact it. How long each record is kept is in the Privacy Notice.
What stops the on-device AI from leaking a transcript?
Aurora's chat surface refuses to resolve any image URL the model produces. This is a real exposure in any product that renders model output as markdown: a markdown image renderer resolves a markdown image by fetching its URL, and a transcript containing injected instructions can steer a language model into emitting an image URL with conversation text in its query string. The request itself is the leak; whether an image ever appears is irrelevant.
So the chat renderer installs image providers that draw nothing for a block-level image and throw for an inline one, and that reference neither the networking layer nor any network-image type. A test feeds a reply containing an exfiltration URL through the renderer and asserts that no request is issued. That closes one channel, not the whole class of prompt-injection problems, and Aurora does not claim otherwise, but it is the channel that most reliably turns a local model into an exfiltration path, and it is held shut by a test rather than by a convention.
What leaves the device when you report a problem?
Only a report you asked Aurora to send. Diagnostics are collected locally so that a fault can be investigated at all, and nothing is transmitted until you act. What the report carries is governed by two switches. "Include session details in report" starts on, and from inside a session it attaches that session's title, transcript, summary, Ask Aurora chat and images, including a screenshot of Aurora's window. "Include the recording" starts off: the audio goes only if you turn it on, and only while it is still on the device. With session details off, the report is your description and technical diagnostics: no audio, no transcript, no summary, no note, no image. What is actually inside an Aurora diagnostic report covers both switches, the package members and how long a report is kept.
What does Aurora's on-device claim not cover?
It covers the speech pipeline: capture, transcription, speaker separation, refinement, storage and local AI. It does not mean that nothing ever crosses the network, and a product telling you that would be misrepresenting at least its own model download. Aurora's claim is bounded deliberately:
- Bytes in are not bytes out. Models are fetched once. That is traffic toward your device, not away from it, but it is still a request, and the host serving it sees your IP address, the time and the size.
- Your own copies are yours to manage. An export, a share sheet, a device backup or a file you move elsewhere leaves Aurora's boundary on your instruction.
- One optional feature carries text. Conversation sync is off until you turn it on, per device. It copies titles, transcripts, notes, summaries and chats to your own private iCloud database, never audio, and no Aurora server is involved.
- Consent-gated usage metrics exist. One answer covers setup timings and recording time and counts. Content-free, refusable, and silent unless you said yes.
- Some paths are not optional. Your settings and each device's recording totals always follow your Apple Account through your own iCloud key-value storage, and on the free tier the free-minutes ledger tells Aurora's service how many seconds each recording used. Neither carries what was said.
- A report can carry content, and starts that way. On a session report the session-details switch opens on; the recording has its own switch, which opens off. That is the one place where the honest answer is "check before you send", not "nothing happens unless you act".
What should you ask any transcription app?
Three questions separate architecture from policy, and the third one answers the first two. Ask where the audio goes. Ask where the transcript goes, a different question with a different answer at many vendors, because a product can transcribe locally and still send the finished text to a cloud model to be summarized. Then put the device in airplane mode and record.
A product that keeps working with the network off cannot have been depending on a server for that work, and no later policy revision can take that property away. A product that stops working has just told you where your conversation was going. Be precise about what the test proves, though: it proves that capture, transcription, separation and summaries are local. It does not prove that an app makes no network calls at all; the table above is Aurora's own list, and a model download is on it. Airplane mode tests the pipeline, not the whole application.
References
- Apple. FileProtectionType. developer.apple.com: the data-protection classes, including the one Aurora applies to session audio.
- Apple. AVAssetWriter.movieFragmentInterval. developer.apple.com: fragment emission, and why an unfinalized file decodes only to its last fragment.
- OWASP GenAI Security Project. LLM01: Prompt Injection. genai.owasp.org: the injection-to-exfiltration pattern the chat renderer blocks.
- European Union. Regulation (EU) 2016/679 (GDPR), Article 9. eur-lex.europa.eu: special-category data, the reason voice identification belongs on the device.
Related
- What is actually inside an Aurora diagnostic report: the path that can carry the recording, field by field.
- What on-device transcription costs on an iPhone: the compute budget this architecture spends.
- Aurora's privacy policy: the named network paths, the report tiers and the retention periods.