Designing a No-Account iOS Voice Workflow: Audio to Transcript to Tasks

Eyal Ronen — Mon, 21 Sep 2026 10:56:23 +0000

The product problem

A voice recorder is good at preserving audio. It is not good at helping someone find the decision they made in a meeting, remember the promise buried in a lecture, or turn an idea into a next step.

ToText is a small iOS product built around a longer pipeline:

capture/import -> local record -> temporary transcription ->
transcript -> summary + action items -> questions -> export

The important engineering detail is that this is not one “AI feature.” It is a set of jobs with different storage, retry, and privacy requirements. The app has no user account, and the library is stored on the device, with optional iCloud sync. That constraint shapes nearly every decision.

1. Keep capture separate from processing

The first boundary is the audio file.

A user can record in the app or import a supported file. The app first saves enough local state to represent the recording, then starts processing. That means leaving the app, losing a network connection, or stopping a long recording does not have to destroy the only copy.

A useful job model looks roughly like this:

recording
  -> queued
  -> uploading
  -> transcribing
  -> generating
  -> ready

uploading/transcribing/generating -> failed -> retryable

The exact implementation can use Swift concurrency, a persistent queue, or another approach. The key is that the state is durable and visible. A spinner is not a recovery strategy.

For long recordings, the app needs to keep the source available while work is in progress. If a request fails, the user should see a failed job, a reason when possible, and a retry action. If a server-side job stalls, the usage allowance should not remain permanently consumed.

2. Be precise about the privacy boundary

“No account” and “on device” are different claims.

ToText does not require an account, email address, or sign-in. The saved library is on the device, with optional sync to the user’s own iCloud Drive. There is no permanent server library of completed recordings.

The main recording flow still needs cloud speech-to-text. Audio is temporarily sent to AWS Frankfurt and Soniox for transcription, then deleted about a minute after processing. That is the honest boundary: local library, temporary processing service, no permanent server archive.

Generated features such as summaries, action items, and questions use transcript context. The product should explain that processing is required for these features rather than implying that every operation is local. A privacy label is only useful when it tells the user which path they are choosing.

There is one absolute never-leaves-the-device path, and it is not the main recording flow. On iOS 26 and later, the Apple dictation keyboard can provide that option when the user uses the system dictation path. Keeping this distinction in the UI and documentation prevents a convenient slogan from becoming a false technical promise.

3. Treat the transcript as evidence

Speech recognition output is not the same thing as a verified record. Names, numbers, deadlines, and commitments need review.

The useful interface pattern is to keep the recording beside the transcript. When timing data is available, a sentence can point back to its position in the audio. Speaker labels help with conversations, but they can still need correction, especially with overlap or noise.

This makes the later steps safer:

The summary is a compact reading view.
Action items are suggestions extracted from the transcript.
Q&A answers should stay grounded in transcript text.
A timestamp gives the user a fast way to check a claim.
Export should preserve enough context to make review possible.

The app supports summaries and generated text in the user’s chosen app language while keeping the transcript in the language or languages that were spoken. That matters for bilingual speech. Translating the transcript and summarizing it are different operations, and they should not be presented as the same thing.

4. Design the no-account tradeoff deliberately

A no-account product gives up some familiar features. There is no server-backed workspace, no team invitation, and no automatic library on every device through a vendor account.

In return, the core library does not need to be tied to an email address. Usage can be tracked with an anonymous device identifier, and paid access can be managed through Apple’s purchase system. The product remains freemium, with a free plan and optional in-app purchase plans for higher usage, without making signup the first task.

This model moves complexity into the client:

Persist recording metadata before network work begins.
Keep pending files recoverable after interruption.
Make retry idempotent so a second tap does not create confusing duplicates.
Reconcile purchase state reliably.
Make deletion report the actual result.
Keep the local library searchable, including mixed Hebrew and English text.

Privacy is not just a backend retention policy. It is also the behavior users see when the network is unavailable.

5. Respect iOS product boundaries

The app can capture through its own recorder or import audio. It does not join online meetings or directly capture phone calls, Zoom, Google Meet, or other system audio.

The keyboard path has its own iOS constraint. A third-party keyboard cannot simply hold the microphone open as if it were the main app. A practical design can hand the user into the recording path, then return with inserted text. That is a different user experience from recording a full conversation and saving it in the library.

Live Activity controls can make an active recording easier to pause or stop from the Lock Screen. Accessibility also belongs in the first design pass: VoiceOver labels, Dynamic Type, and reduced motion are not polish added after the data model is done.

6. Test the failures, not only the demo

A builder can make the happy path look impressive in one afternoon. The real work is testing what happens when:

the user stops a recording and immediately leaves the app
the network drops during upload
a recording lasts an hour or more
the transcript contains right-to-left and left-to-right text
two speakers overlap
the generated summary invents a detail
the user deletes the library while a job is pending
a verified subscription is temporarily unavailable to the UI

A clear failed state is a feature. A retry that does not duplicate work is a feature. Showing the original audio beside a generated answer is a feature.

The small-system principle

The architecture for a voice-to-notes app does not need a permanent cloud library to be useful. It needs explicit boundaries:

store the user’s working library locally
send only what processing requires
delete temporary audio on a defined schedule
make generated text easy to verify
expose failures and recovery
do not confuse an iOS dictation path with the main cloud transcription path

That is the system behind ToText: record or import, transcribe temporarily, generate useful views, and keep the result close to the original recording. The result is not a promise that AI never makes mistakes. It is a workflow that makes those mistakes easier to spot and the useful parts easier to carry forward.

ToText is available for iPhone and iPad at https://apps.apple.com/app/id6770080775. Review important names, numbers, and commitments against the audio before relying on generated text.

DEV Community: Eyal Ronen