airtxt

I build airtxt, a voice-to-text keyboard for iPhone. Solo founder. About 600 automated tests, green for weeks.

Then I made a second account on my own phone to check something unrelated. Fresh signup, brand-new email. The app opened to a populated "Your Dictations" list — the previous account's transcripts, sitting there for a stranger to read.

Nothing had crossed the network. The server derives the owner from a verified token, so that half was fine. The bug was entirely on the device: dictation history and memos were single JSON files in a shared container, and sign-out cleared the session but left the files behind. Whoever signed in next inherited them.

What I learned wasn't "write more tests."

Every test I have runs as one user, on one fresh install. "A second person arrives on this device" is not a state my suite can construct. So a whole category of bug — anything that only shows up when a second identity touches the same storage — was structurally invisible to it. Not under-tested. Un-testable, in that shape.

Green tests are not evidence that a stranger's first five minutes work.

So I wrote a manual gate: a short list of checks a human runs on a real phone before every release, each written from a customer's point of view instead of a developer's. Sign in as A, dictate, sign out, sign in as B, look at the screen.

It earned its keep on the very next build, and caught the sequel: the fix wiped local data on account change. Safe , and it also meant that if you handed your phone to a friend so they could use their own account, your own notes were gone when you signed back in. Right on privacy, awful as a product. Invisible to tests too, because the tests assert the wipe happens.

That gate is permanent now. It runs before every release, and it keeps finding things no suite of mine ever will.

airtxt is live on the App Store, currently at 1.1.5: on-device or cloud speech recognition as a per-user toggle, 69 cloud language and regional options, a bot that joins your Zoom/Meet/Teams calls and returns a speaker-labeled transcript, and bring-your-own-keys — your Deepgram, Anthropic, or OpenAI key lives in your device Keychain, goes straight to that provider, and never touches my servers. That provider bills you directly. Free tier, Pro at $9.99/mo.

apps.apple.com/us/app/airtxt-voice-to-text-keyboard/id6785986350

What I actually want to ask this group:

What condition does your test suite structurally fail to create? Not "what bug did you ship" — what state can your tests never construct? Second user, second device, second tenant, an expired card, a timezone rollover, a customer with 10,000 rows instead of 10. I think the list is short, close to universal, and mostly unwritten.

And if you've handled multi-account-on-one-device in a mobile app without destroying data, I'd take that answer specifically.

I dictate more than I type, but every voice tool seemed to force the same choice: keep processing on-device and accept rougher text, or send everything to the cloud for better transcription and cleanup.

I wanted both options—and I wanted dictation to work where I actually write, not only inside a separate recording app. That became Airtxt, an iPhone and iPad voice-to-text keyboard.

Physical-device testing taught me a few painful lessons.

First, simulator and automated tests are not enough. In one TestFlight build, cloud dictation worked perfectly while on-device dictation failed completely on the actual phone.

Second, AI cleanup can be more dangerous than transcription errors. During testing, the raw transcript was correct, but the cleanup model responded to the sentence as if it were a question. Instead of polishing the words, it invented an AI-style answer. That changed how I think about cleanup: the transcript must be treated as data, its meaning must be preserved, and the original text must remain recoverable.

Third, language settings have to reach every part of the pipeline. British and Indian English initially produced American spelling when people used their own Anthropic key—even though Airtxt’s default cleanup handled the locale correctly. The language picker now follows the user’s selection through transcription and cleanup, including bring-your-own-key providers.

Fourth, switching between on-device and cloud processing exposed lifecycle problems. A previous dictation could remain marked as “finishing” and block the next one. Voice software needs the same careful state management as any other asynchronous system.

Airtxt now supports system-wide keyboard dictation, on-device and cloud modes, AI cleanup, bring-your-own keys, voice memos, meeting notes, Siri shortcuts, regional English, and iPhone and iPad.

I’m still learning where trust breaks first for users.

If you use voice typing, which failure bothers you most: incorrect words, AI changing your meaning, or losing the text completely?

Airtxt: https://www.airtxt.ai