DEV Community: Simple Memo

I killed every meeting as a solo dev. Half of it backfired.

Simple Memo — Tue, 28 Jul 2026 13:37:13 +0000

The line I was proudest of, for about 14 months, was that I ran a product with zero meetings. No standups. No syncs. Not one calendar invite. I said it the way people announce they have quit caffeine: a little smug, waiting for the flinch of envy.

Then I put one meeting back. A single recurring call, once a month. And the month after I added it, I closed a decision I had been circling for three weeks. The timing nagged at me enough that I went back through my own notes to work out what the meetings I had so proudly deleted were actually doing. The answer was not flattering.

TL;DR

Zero meetings as a solo dev was half right: the coordination meetings I deleted really were dead weight, because there was nobody on the other side to coordinate with.
It was half wrong. Meetings also force decisions, put a witness on your commitments, and drop a hard stop on the workday. Those jobs did not vanish when the invites did. I just stopped paying for them on purpose and started paying interest instead.
The fix was not reinstating meetings. It was rebuilding those specific jobs deliberately, with one standing call, a timeboxed weekly review, and a habit of deciding in public.

The boast, and where I picked it up

I did not invent the anti-meeting position. I inherited it, fully formed, from people I respect.

Paul Graham's 2009 essay "Maker's Schedule, Manager's Schedule" taught a generation of builders that a maker and a manager run on different clocks, and that a single midday meeting can blow a crater in an afternoon by splitting it into two pieces too small to build anything in. A year later, Jason Fried and David Heinemeier Hansson gave the movement its bumper sticker in Rework, in a section literally titled "Meetings Are Toxic," where they pointed out that a one-hour meeting with five people is not one hour, it is five. I read both in my twenties and treated them as settled law.

So when I went solo, dropping meetings felt less like a choice and more like finally getting to practice what I had preached. And here is the part I still stand behind: for a solo developer, most meetings genuinely are waste. A standup coordinates handoffs between people. A sprint planning session negotiates capacity across a team. A status meeting exists so that eight humans can build one shared picture of where things are. When the team is one person, all of that machinery is spinning against no load. It is the same reason I eventually stopped using an issue tracker built for a team I don't have: the tool was solving a coordination problem I no longer had.

That much was right, and I want to be clear about it before I take the rest apart. Deleting coordination meetings cost me nothing, because there was nothing there to coordinate.

So what were the meetings really doing?

The mistake was assuming coordination was the only thing meetings did. It was the most visible thing, so I concluded it was the whole thing. It wasn't.

When I traced my worst weeks back to a cause, the same few functions kept showing up, and every one of them was a job a meeting used to do off to the side, while everyone thought the point of the meeting was the agenda.

What a meeting also did	My solo substitute	What it actually cost
Forced a decision by a hard date	"I'll decide once I've thought it through properly"	Decisions drifted for weeks; a deadline had been doing work I never credited it for
Put a witness on my commitments	Kept the plan in my own head	I quietly abandoned plans nobody had seen me make
Surfaced disagreement in real time	Argued both sides with myself on paper	I shipped confident mistakes with no one to catch them
Dropped a hard stop on the day	Worked until I drifted off it	The task sprawled to fill every hour I gave it

None of these are coordination. All of them are load-bearing. And unlike the coordination overhead, which I could delete for free, these four were structural. Removing the meeting removed the structure and left the need standing there with nothing to lean on.

The three weeks I lost to a decision nobody forced

Here is the one that finally got my attention, because it was expensive and entirely my own fault.

I had a schema change to make. Small, reversible, the sort of thing that in a previous job would have come up in a Tuesday sync, gotten fifteen minutes of mild argument, and been decided by Wednesday because the meeting simply ended and a choice had to exist by then. On my own, with no meeting to end, the decision had no deadline attached to it. So I did the responsible-sounding thing and kept thinking about it.

I thought about it for three weeks. I wrote two documents weighing the options. I felt productive the whole time, because writing documents feels like work. But the schema did not change for 21 days, and the feature sitting on top of it did not ship, and the actual amount of new information I gathered in week three versus week one was close to zero. I had not been deliberating. I had been marinating.

A meeting would have killed that decision in a day, not because meetings are smart but because they are over at a specific time, and a decision that has to exist by the time a meeting ends tends to exist. I had thrown away the deadline along with the small talk. This is the thing the anti-meeting essays are quietest about: for someone like me, the meeting was never the interruption. The meeting was the forcing function, and the calendar was doing my executive function for me.

What I changed without reopening my calendar

I want to be honest that this is where my zero-meetings boast became literally false, and I think that is fine. The goal was never zero meetings. The goal was zero waste. I had confused the two.

I rebuilt those functions on purpose, and only those. The forcing function and the hard stop came back together, as clocks. A standing weekly review, 30 minutes with a timer running, where any decision I have been "thinking about" for more than a week has to resolve or get explicitly killed, plus a fixed end-of-day I hold to so the work stops sprawling into the evening. The witness came back as deciding in public. When I commit to something now, I write it somewhere a reader could see it, because a plan with a witness behaves differently from a plan I am keeping in my head, even when the witness is a handful of strangers who will never follow up.

And the disagreement came back as the one real meeting, the monthly call, with another solo developer who is under no obligation to be nice to me. I had already written about losing the one person who tells you you're wrong when you ship alone. The meeting is where that person used to live. Rebuilding a thin version of them was worth exactly one calendar invite a month.

Notice what I did not add back: a standup, a status meeting, anything recurring whose job is coordination. Those stayed dead, because those really were waste. I paid to restore the functions I had lost and refused to pay for the ones I hadn't.

Isn't this just meetings with extra steps?

This is the fair objection, and I have argued it against myself more than once, so let me put it at full strength.

You could say I have simply reinvented meetings, badly, and that my "timeboxed review" is a standup with a party of one, my "deciding in public" is a status update, and my monthly call is just a meeting I have decided to feel clever about. There is a version of this where I spent 14 months taking the machine apart only to rebuild most of it and claim I invented something.

I think that objection is about 60% right, and the honest 40% is this. The reconstructed versions are strictly weaker than the real thing at exactly one job, disagreement, and that weakness is not fixable. When I argue both sides of a decision on paper, I am still the one holding the pen, and I cannot fully surprise myself. The monthly call helps, but it is one hour against a whole month of me agreeing with me. I do not actually know yet whether that call is doing real work or whether it is a comfort blanket I have talked myself into needing. Ask me in a year. Forcing, witnessing, and stopping all rebuild cleanly, because they are mechanical and do not need a second brain. Disagreement is the one that genuinely wants another human, and it is the one I am still faking.

Where I think I'm wrong next

If the pattern holds, the belief I am currently too proud of is that async always beats sync. I have spent this whole post defending a slower, written, meeting-light way of working, and I still believe it for most things. But I have started to notice a specific class of problem, usually a tangled decision with three or four interacting unknowns, where 20 minutes of live back-and-forth with one person gets me further than a week of careful async ever does. I suspect I am still underpricing synchronous bandwidth for exactly the decisions that are too knotty to write down cleanly, and that in a year I will be back here explaining which half of this post was wrong.

That is the actual lesson, if there is one. Not "meetings good" or "meetings bad." Just that when you delete a ritual, you should figure out every job it was silently doing first, because some of those jobs do not have the decency to announce themselves on the way out.

A couple of questions I keep getting

Doesn't a weekly self-review just become another thing you skip? It did, until I put a hard external date on it by tying it to the same day I do my monthly numbers, which I will not skip because money is involved. Attaching the soft ritual to a hard one was the only version that survived.

Why not just get better discipline and decide faster without any of this? Because "get better discipline" is the plan that has failed every single time I have tried it, and building a structure that makes the right thing happen on a schedule is the plan that works. I would rather engineer the forcing function than keep losing to my own good intentions.

What if you had employees? Then most of what I deleted would come straight back, because it would be doing real coordination work again, and this entire post would be irrelevant. That is the point. The right number of meetings is a function of how many people have to stay in sync, and for a team of one that number is small, but it is not zero.

Here is the question I would actually like answered: when you removed a meeting, a standup, a weekly sync, a recurring call, what job did it turn out to be doing that you only noticed once it was gone? I am collecting these, because I suspect forcing, witnessing, and stopping are not the only three.

I'm a solo developer building an iOS app called Simple Memo. It turns a thought into a sent email before I can talk myself out of it. I write here every few days about the parts of working alone that nobody warns you about.

A 15-second interruption cost me 40 minutes of re-entry

Simple Memo — Fri, 24 Jul 2026 13:37:08 +0000

The auth bug was ten minutes from fixed. I had the whole failure loaded in my head: the token refresh racing the retry, the three files it touched, the one line I was reaching for. Then a Stripe email slid across the top of the screen at 3:12 PM. I read it. Fourteen seconds, maybe. Then I looked back at Xcode and the structure was just gone. Rebuilding it took the better part of forty minutes.

That ratio bothered me enough to start timing it. A fourteen-second glance had cost me forty minutes, and no tool I owned had a place to record that. My calendar knew about the meeting. My timer knew the hours. Nothing knew the tax.

What thirty days of timing actually showed me

The interruption is the cheap part. Re-entry is where the time goes, and almost nobody measures it.
My re-entry cost was bimodal. Trivial switches ran about two minutes; deep ones ran thirty to forty-five. There was almost nothing in between.
The single biggest predictor of which one I got was stupidly simple: whether I had written down my next move before I left.
Blocking interruptions barely moved the number. Making re-entry cheap moved it a lot.

The setup, and why a solo dev can't just "avoid distractions"

Here is the part the productivity advice skips. As a solo developer I am the engineer, the support desk, the ops on-call, and the person who notices the payment failed. Most of my interruptions are not distractions I can silence. They are the job arriving out of order. "Turn off notifications" is advice written for someone who has colleagues to absorb the things they ignore. I don't have colleagues.

So after the forty-minute day I stopped trying to block interruptions and started measuring what they cost. One line per interruption for thirty days: the time, what I was doing, what pulled me away, and when I was genuinely back in. That last field turned out to be the one that mattered. I defined "back in" as my first correct edit after returning, not the moment my eyes hit the screen. Those are very different timestamps.

I want to be honest about the instrument before I quote it. This is one developer timing himself, and on a bad day the faculty doing the timing is the same one the bad day has already degraded. Treat my numbers as a shape, not a benchmark.

The population number does exist, and it is worse than most people think. Gloria Mark's team at UC Irvine, shadowing office workers through their real days, found it took an average of 23 minutes and 15 seconds to return to a task after an interruption, and that people don't go straight back but pass through about two intervening tasks first. Her 2023 follow-up is bleaker: average attention on a screen has fallen to roughly 47 seconds, with an interruption about every three minutes. The 23-minute figure is real. What it hid, for me, was the shape underneath the average.

Why is re-entry the expensive part, not the interruption?

Because the interruption doesn't charge you for its own length. It charges you for the teardown.

When I'm deep in a bug I'm holding a small structure in working memory: which call races which, what I've already ruled out, the exact edge I'm standing on. That structure isn't saved anywhere. It lives in the most volatile storage I own. A fourteen-second read doesn't cost fourteen seconds; it evicts the structure, and then I have to rebuild it from source — reopen the files, re-derive what I'd ruled out, walk back to the edge. Mark's two-intervening-tasks finding is the same story told from the outside: you rarely drop straight back into the thing. You bounce off two smaller things on the way.

This is the extension of something I found the hard way a couple of months ago, when I was logging energy instead of hours: the villain in that ledger was never interruption either, it was unresolved ambiguity running a background thread and eating the depth I was saving for the hard task. This is the same monster in a different coat. Interruption isn't expensive. Losing your place is.

What the timer showed: the same switch, two different bills

Once I sorted thirty days of lines, the split was embarrassingly clean. The cost of a switch had almost nothing to do with the interruption and almost everything to do with the one thing I controlled: whether I had left myself a note.

	No next-action written	Next-action written
Shallow switch (I knew where I was)	~2 min	~2 min
Deep switch (mid-problem, stack loaded)	~34 min	~6 min

The top row barely reacts. When the work was shallow, re-entry was cheap no matter what, because there was no structure to lose. The bottom row is the whole story. A deep switch with nothing written down cost me a median of about 34 minutes. The same depth of switch, when I had spent one second writing down my next move, cost about 6. Same interruption, same me, a five-fold difference that came down entirely to whether I had left a breadcrumb.

The fix that didn't work

For a month before this I did what everyone recommends. Notification batching. Do Not Disturb blocks. "Focus hours" fenced off on the calendar. It moved the number so little I almost didn't bother logging it.

The reason is that blocking assumes the interruption is optional, and mine mostly weren't. The build broke; I had to look. A customer couldn't log in; I had to answer. The pattern the advice is built for, a stream of pings you could ignore without consequence, is not my pattern. You cannot Do-Not-Disturb your way out of being the entire company. Blocking treats the switch itself as the enemy. For me the switch was usually the correct thing to do. The damage came afterward, in the re-entry, and blocking did nothing about that.

The one that did: cheapen re-entry, don't prevent the switch

So I gave up on preventing switches and put everything into making re-entry cheap. The whole method is one habit: before I leave a task, even for fourteen seconds, I write one line saying exactly what I was about to do next.

Not "fix auth." That is a task label, and it is useless coming back — it names the mountain, not the step. The line has to be the specific next physical action: refreshToken guard in AuthClient fires before the refresh resolves; change the guard near line 80, not the retry. That sentence reloads the structure. When I come back I don't rebuild from source; I read one line and step onto the exact edge I left.

The catch is that this only works if writing the line is nearly free. If capture takes longer than the thought, I won't do it mid-switch, and I'll quietly promise myself I'll remember. So the breadcrumb rides the same one-second capture path as everything else I catch, because a thought I can't get out of my head in about a second is already gone. One line into my own email, there in about a second; on the evenings I sit down to curate, the same line is already under that day's heading in my vault. The point isn't where it lands. The point is that the exit costs a second and the re-entry it buys back costs half an hour.

The part I don't want to oversell

This is n=1, self-reported, and the "back in" timestamp is a judgment I made about my own head. The breadcrumb has a real failure mode too: when the interruption changes the task (a production incident that rewrites what the next action even is), there's no place to return to, and the note is worthless. And none of this is some new law of attention. It's one crude instrument telling one developer he had been counting the wrong number for years.

Which is the actual takeaway, if there is one. Every tool I own counts interruptions. Not one of them counts re-entry, and re-entry is the number that was eating my days. Measure the thing that costs you, not the thing that happens to be easy to count.

A few questions I keep getting

Isn't a breadcrumb just a TODO? No, and the difference is the whole point. A TODO records a task: "fix auth." A breadcrumb records a resume point: the specific race, the specific line, the thing I had already ruled out. A task label makes you rebuild the context; a resume point hands it back. You can feel which one you wrote by whether reading it reloads your head or just reminds you the mountain is still there.

Doesn't stopping to write the line just add another interruption? It lives inside the switch you were already taking, and it costs about a second against a re-entry that runs into the tens of minutes. I have never once regretted the second. I have lost the afternoon plenty of times by skipping it.

What if I can't tell a deep switch from a shallow one in the moment? You don't have to. Write the line on every switch. On shallow ones it costs a second and you throw it away; on deep ones it saves you half an hour. It is cheap enough to buy as insurance on all of them, and you stop having to make the call.

So here is what I actually want from you: what is your own re-entry time after a deep interruption, and have you ever measured it apart from just counting how often you got interrupted? The count is the number every app puts in front of you. I am increasingly sure it is the wrong one, and I would like to know whether your log says the same.

I'm a solo developer building Simple Memo, an iOS app that gets one line of text into my own email about a second after I think it — roughly the speed a breadcrumb has to be caught to survive a context switch. I write here every few days about the parts of building alone that caught me off guard.

What I measured cutting my iOS cold start to 280 ms

Simple Memo — Tue, 21 Jul 2026 13:35:19 +0000

Stage (my iPhone, tap → first usable frame)	Before	After	How I measured it
Pre-main (dyld)	210 ms	88 ms	`DYLD_PRINT_STATISTICS=1`
`didFinishLaunching`	120 ms	21 ms	`os_signpost` intervals
Root view build + first CA commit	100 ms	71 ms	Instruments, App Launch template
Total	430 ms	180 ms	—

That table is the better part of a year spent chipping at a single number: the time between my thumb landing on the icon and the first usable frame of an iOS app I build alone. On my own phone it fell from 430 ms to 180 ms. In the field, where it actually counts, the number is different and more stubborn, and getting honest about that gap is most of what this post is about.

The short version:

The cost of a cold start on a small app is mostly dyld pre-main, and the biggest lever there is how many dynamic libraries you link — not how clever your own code is.
The rest of the cuts came from refusing to do work on the launch path that most launches never use: hydrating the whole note store, checking iCloud, warming the audio stack.
The 280 ms in the title is a field median, and it is the least honest number in the post, because the cold start users actually feel is the tail and the first launch after an update — and that one is still over a second.

Why does dyld dominate a small app's cold start?

Before your main() runs, the dynamic linker has already done a day's work. It maps your dependent dynamic libraries, applies rebase and bind fixups so every pointer lands in the right place, registers your Objective-C classes and runs any +load methods, then runs your C++ static initializers. All of that is "pre-main," and on a small app it is routinely the largest single slice of the cold start. Your own code has not executed yet.

The number that surprised me when I first turned on DYLD_PRINT_STATISTICS=1 in the scheme's environment variables was how little of pre-main was mine. The breakdown it prints (dylib loading, rebase/binding, ObjC setup, initializer time) was dominated by dylib loading. I was paying, on every cold start, for the privilege of having split my app into tidy dynamic frameworks.

Here is the actual shape of it on a fresh install, the numbers DYLD_PRINT_STATISTICS printed to the console:

Total pre-main time: 210.44 milliseconds (100.0%)
         dylib loading time: 128.19 ms (60.9%)
        rebase/binding time:  41.02 ms (19.5%)
            ObjC setup time:  22.31 ms (10.6%)
           initializer time:  18.90 ms  (9.0%)

Sixty percent of my pre-main was the linker finding and mapping binaries. No amount of cleverness inside didFinishLaunching can touch that slice; it is spent before my code draws breath. The only knob that moves dylib-loading time is how many separate dynamic binaries dyld has to open, and that is a decision you make in your target settings, not your source.

Two honest caveats before the numbers, because pre-main is the easiest place to fool yourself. First, measure a release build on a device; a debug build on the simulator will lie to you in both directions. Second, modern dyld caches a launch closure after the first run, so a warm cold start is far cheaper than the one that matters most: the first launch after an install or an app update, when the closure is rebuilt. The scary pre-main number is the post-update one, and it is the one DYLD_PRINT_STATISTICS on a fresh install shows you.

The three hypotheses I tested

This kind of optimization (measure, guess, cut, measure again) only works if the guesses are written down before the cut. Here are the three I actually tested, in the order the profiler pointed me at them.

H1: pre-main is dominated by dynamic library count

Tested by counting. I'd already pulled every third-party dependency out of this app, which I wrote about separately; that turned out to be the single biggest thing standing between me and a fast pre-main, and I hadn't even measured it at the time. But I still had my own code carved into a couple of embedded dynamic frameworks for module hygiene. Each one is a separate binary dyld has to find, map, and fix up.

The cut: I collapsed my own modules back into the main app target and let them link statically. Module boundaries are a compile-time nicety; the runtime does not care how clean your dependency graph looked in Xcode. Pre-main dropped from 210 ms to 88 ms on my device — most of it the disappearance of dylib-loading time. Apple has been saying "keep your dynamic framework count low" since the 2016–2017 startup-time talks, and for a small app the advice is close to a free 100 ms.

H2: I'm doing store work on the launch path that the first frame doesn't need

Tested with os_signpost. I wrapped each phase of didFinishLaunching in a signed interval and read it back in Instruments:

let log = OSLog(subsystem: "app.launch", category: .pointsOfInterest)
let id = OSSignpostID(log: log)
os_signpost(.begin, log: log, name: "hydrate-store", signpostID: id)
store.loadAll()          // <- the expensive line
os_signpost(.end, log: log, name: "hydrate-store", signpostID: id)

store.loadAll() was a JSONDecoder reading the entire note history to build the first screen. On my store it cost ~60 ms, and the latent bug was worse than the number: it was O(n) in note count, paid on every launch. A user with a few thousand notes was subsidising my laziness on the launch path every single time they opened the app.

The cut: render the first frame from nothing (an empty capture field, the one thing a capture app can always draw instantly) and hydrate the store on a background queue afterward, updating the view when it arrives. The persistence layer already drained its outbox asynchronously, so I was borrowing a pattern I'd already built. In the same pass I moved the iCloud availability check, url(forUbiquityContainerIdentifier:), off the launch path and onto first actual use; that call can block for a surprising while the first time you make it. didFinishLaunching fell from 120 ms to 21 ms.

H3: I'm warming a subsystem for a feature most launches never touch

This is the one I'm least proud of. I had been eagerly building the audio and on-device dictation stack during launch so the mic would feel instant the moment someone tapped it. Signposts put it at ~35 ms on the launch path, and it also poked AVAudioSession awake for no reason on launches where nobody dictated anything.

The trade I'd made without noticing: I was taxing every cold start to make one occasional tap feel faster. I moved the whole stack to lazy initialization on first mic tap. Cold start got cheaper for everyone; the mic's first-tap latency rose by an amount I could hide behind the waveform animation that plays while it spins up. Warm the thing the user is about to use, not the thing they might use — and never on the path to first frame.

The field is not your dev phone

Here is where the tidy lab numbers meet reality. MXAppLaunchMetric from MetricKit reports the real distribution from real devices, delivered once a day to an MXMetricManagerSubscriber, aggregated and privacy-preserving. This is field data, not a hero run on the newest phone in the room. It looked nothing like my 180 ms:

MetricKit `timeToFirstDraw` (all users)	Before	After
p50 (median)	~610 ms	~280 ms
p90	~1.2 s	~520 ms
Worst ~1% (post-update, cold, old devices)	rarely under 2 s	still ~1.3 s

My lab number was the ceiling, nothing like the typical case. The field median is roughly 1.5x my device; the p90 is closer to 3x. The gap is older CPUs and slower flash, thermal throttling, low-storage devices where the filesystem is slow, launches while the system is busy doing something else, and above all the first launch after an update, when dyld has no cached closure to lean on. The 280 ms I put in the title is honest as a median. It is also, on its own, a little misleading.

Which cold start actually matters to a user?

Not the one I spent the most time on. That is the uncomfortable finding.

The p50 sits below the threshold where a person consciously registers a delay; shaving my own phone from 430 ms to 180 ms was, for the median user, mostly vanity I happened to enjoy. What a user actually feels is two things I under-invested in. The first is the tail: the p95 and p99, the bad-device, bad-moment launches that still run over a second, because one slow launch is remembered longer than fifty fast ones. The second is that most launches are not cold at all. A capture tool gets opened twenty times a day, and nineteen of those are warm resumes governed by applicationResumeTime, not the cold path I obsessed over. I optimised the least frequent launch because it was the most satisfying to measure. The honest allocation would have put more of that year into the tail and into resume time.

I'm keeping the cold-start work (100 ms of free pre-main is still 100 ms, and the store bug was a real scaling landmine), but I'd be lying if I sold you the median as the win. The median was the easy, feel-good part.

A few questions I keep getting

Does this even matter on modern dyld with launch closures? For warm cold starts, less than it used to; the closure does most of the caching for you. It matters exactly on the launch you can't cache: the first one after an app update. If you only ever test warm launches, you are measuring the case your users feel least.

SwiftUI or UIKit — does the choice change the cold start? At this scale, less than the dynamic-framework count does. The first-frame cost differed by a handful of milliseconds between a minimal UIKit root and a minimal SwiftUI one in my testing; the 100 ms swing came from dyld, not the UI framework. Optimise the linker before you re-litigate your UI stack.

Isn't 100 ms of cold start below the human perception threshold anyway? For the median, roughly yes, and that is exactly my counter-take above. The reason to still care is the tail: the same cut that moves a 180 ms launch you can't feel also moves a 1.3 s launch you very much can.

The number I still can't see

The measurement I want and don't have is the post-update first-launch time-to-first-draw, in the field, isolated from ordinary cold starts. MetricKit buckets them together, so the one launch I believe my users actually judge me on is hidden inside an average with all the cheap warm-cache launches. Next, I'm going to tag it myself: stash the last-launched bundle version in UserDefaults, compare it on launch, and when it changed, emit a signpost around first draw so I can pull that specific launch out of the noise. My bet, and it is only a bet until the data lands, is that it is the only cold start that has ever cost me a user.

If you've shipped an iOS app: what is your first-launch-after-update time-to-first-draw, and did you ever manage to measure it apart from ordinary cold starts? That's the number I can't cleanly see, and I suspect it is the only cold start anyone actually feels.

I'm a solo developer. I build Simple Memo, an iOS app that turns one typed line into an email about a second later, and I keep it small enough that the cold-start ledger above is a normal Tuesday for me. It's on the App Store if you're curious what that constraint produces.

I deleted every Zettelkasten ID and my notes got better

Simple Memo — Fri, 17 Jul 2026 13:33:32 +0000

For three years I hand-maintained a Luhmann-style ID on top of every note I kept: roughly 1,400 of them, little addresses like 3a2 and 3a2b clipped to the front of each line. Last spring I deleted all of them in one afternoon. The disaster every Zettelkasten guide promises, notes collapsing into an unnavigable pile the moment you remove the structure, never arrived. If anything, the notes got better at the one job I actually need them for now: being read by a machine.

I want to argue that the famous ID scheme at the heart of the Zettelkasten method solves two problems I no longer have, and quietly charges me for a third I never noticed. And I want to make that argument in the era where a large share of my note retrieval is not done by me at all, but by a language model reading my notes as context.

TL;DR

The folgezettel ID was an answer to a physical constraint (paper cannot be searched) and to a human navigator walking a branch by hand. In a plain-text note folder I have neither problem.
Full-text search and backlinks already reproduce most of what the ID graph did. Even inside the Zettelkasten community this is largely conceded for digital setups.
The newer reason to drop the IDs: a model reads dated plain prose far better than a lattice of cryptic addresses, and I feed it my notes constantly now.
What I lost is real. The "at a glance" shape of a thought's branch does not survive the change, so this is a trade, not a free lunch.

The orthodoxy, stated fairly

Niklas Luhmann, the German sociologist, built a paper Zettelkasten of around 90,000 index cards starting in the early 1950s, and credited it as the engine behind a working life of dozens of books and hundreds of papers. The cards were digitized and put online in 2019, so this is not folklore; you can go and look at the actual slips.

The part everyone borrows is the numbering. Luhmann used what German speakers call folgezettel, "follow-up notes." The first card is 1. An unrelated new card is 2. But a card that continues, comments on, or branches from card 1 becomes 1a; the next in that strand is 1b; a comment on 1a becomes 1a1. The address is not a filing location, it is a position in a tree of thought. A quietly brilliant second-order effect falls out of this: a topic worked for years grows long addresses, so the length of an ID tells you at a glance how deep that vein has been mined.

Sönke Ahrens' 2017 book How to Take Smart Notes carried this method out of German academia and handed it to a generation of knowledge workers, and the modern digital Zettelkasten scene (zettelkasten.de, the Obsidian and Logseq crowds) grew from there. The orthodoxy that travelled with it is stated often and stated confidently: the ID is what makes a Zettelkasten a system instead of a junk drawer. Drop the ID and you have a pile.

I believed that the whole time. I was wrong about it, and the reason I was wrong is the useful part.

Why did the IDs feel productive when they weren't?

Because assigning an address felt like thinking, and it wasn't. It was filing.

Every time I made a note I had to decide where in the tree it hung, which meant re-reading neighbors, comparing, placing. That work produced a warm sense of having done something rigorous. But almost none of it changed what I later understood; it changed only where a card sat. I had confused the ceremony of organizing with the act of thinking, and the ceremony carried a real cost I was paying at every single capture.

Here is the tell. In all those years I can count on one hand the times I retrieved a note by walking its folgezettel branch. Every other retrieval, thousands of them, was a full-text search. I had built and maintained an elaborate coordinate system and then navigated by coordinate almost never.

What the ID was actually for

Two jobs, and both have quietly expired.

The first job was giving paper a coordinate system. A physical card has no Ctrl-F. If you cannot search the contents you must know where a thing lives, so you impose an address and a tree on top of it. Luhmann's move was partly a workaround for the fact that a wooden box of cards is opaque to search. My vault is a folder of Markdown files. It is nothing but searchable. The original problem is simply gone.

The second job was letting a human walk a line of thought by hand, card to card. That one is subtler and more defensible, and I will come back to it, because it is the part I actually gave something up to lose.

Then there is the job nobody designed the ID for, the one that decided it for me. I now spend a large part of my week handing chunks of my own notes to a language model as context: debugging with it, drafting with it, asking it to reconcile something I wrote in March against something I concluded in June. A model does not traverse my link graph. It reads text, straight through, in order. To that reader a line like 2026-03-14 Outbox retry needs jitter or the whole queue wakes on the same tick is entirely legible. A line that opens with 3a2b -> is noise it has to spend attention decoding. The ID I was maintaining for a human navigator is, to my most frequent reader, litter.

	Folgezettel ID	Dated plain line
Optimized for	A human walking a branch	Search, and a model reading straight through
Cost per capture	Compare neighbors, place in the tree	Stamp the date, type the thought
How I retrieve	Navigate the graph by address	Full-text search or a backlink
Machine-readable	Poorly; the address is opaque	Natively; it is just dated prose
Maintenance on insert	Re-thread, sometimes re-number	None

The evidence, including the part that hurts

The community already half-admits the first half of this. Spend an hour on the Zettelkasten forums and you find the folgezettel debate running for years: whether the branching ID means anything once you have gone digital. The recurring finding is that in a tool like Obsidian you do not need unique IDs to capture the folgezettel structure at all, because backlinks reproduce it. Open a note and its continuations are simply listed as the things that link back to it. The timestamp method, where you date-stamp the note and let search and links carry the rest, is a completely mainstream alternative and not a heresy I invented on my own.

So the deletion was low-drama. I stripped the 3a2 prefixes with a script, kept the dates, and my retrieval, being search all along, never noticed the IDs were gone.

Now the part that hurts, because I do not trust a case that only flatters the person making it.

Folgezettel's second job, the at-a-glance topography, does not come back. When the shape of the branch is the information, when seeing that one vein has grown a forty-character address tells you instantly that this is where your real work has accumulated, backlinks genuinely do not give you that. A list of backlinks is a set, not a shape. For the two years I was building toward one long argument, that topography might have been worth its tax. I killed it because I am not building one long argument. I am running a software product and catching fast-moving thoughts before they evaporate. Different job, different tool. But I would rather say plainly that I traded something away than pretend I found a strictly dominant move.

So when does a Zettel ID still earn its keep?

Three honest cases. When your corpus has to outlive your tools, whether that means paper or a format you will migrate across decades, an ID that is independent of any one app is a real asset. When the branch shape is the product, as in genuine long-form theory-building, the topography is worth maintaining by hand. And when you have no trustworthy full-text search, the coordinate system stops being ceremony and goes back to being load-bearing.

None of those is true for me. All of them might be true for you, and if so, keep your IDs; the method earned its fame honestly.

What I run now is almost the opposite of a system. One folder, one dated line per capture, written in nouns and verbs a stranger could parse, no addresses. Search is the index. Backlinks are the graph. And the second reader I actually optimize for is not future-me squinting at 1a1; it is the model I will paste these lines into next week. In the LLM era, the second brain worth keeping is the one the machine can also read.

I deleted 1,400 IDs and replaced them with the date.

A few questions I keep getting

Isn't this just a worse Zettelkasten? It is a different bet. Classic Zettelkasten optimizes for a human building a connected argument over years. I optimize for cheap capture and for two readers, search and a model. If your work looks like Luhmann's, mine is the worse choice. If it looks like shipping and debugging, I think the reverse.

How do you link notes with no IDs? Plain backlinks and the date. If two notes belong together I link their titles directly; the date gives me a stable ordering and a rough "what was I chewing on that week" axis. I also split capture and curation into a fast layer and a slow one, so the linking happens later, while I am reading, not while I am trying to catch the thought.

Does full-text search really hold up over years? So far, yes. My notes are a couple thousand plain Markdown files and search is instant. The one place it strains is genuinely ambiguous terms, which a date range or a single backlink resolves. Plain text is also the one format I am confident will still be searchable in twenty years, which is more than I can say for any app's database.

If you run a real folgezettel Zettelkasten, here is what I want from you: the single retrieval you can do that I no longer can. The specific lookup where walking the ID graph beats my search box. Not the philosophy, the concrete case. That is the thing I might have thrown away without noticing.

I build Simple Memo by myself: an iOS app that puts one line of text into my email about a second after I type it, and appends the same line to my Markdown vault on the evenings I sit down to curate. I wrote up how the Markdown side works if that is the part you came for.

I stopped counting hours and started counting energy

Simple Memo — Tue, 14 Jul 2026 13:10:41 +0000

Day 1. I logged 4 hours and 40 minutes of work and shipped nothing I kept. The time tracker said it was a decent day. I had spent most of those 240 minutes re-reading a crash report I did not have the head to fix, and the twenty good minutes went into a settings toggle nobody asked for. That night I closed the timer app for the last time and wrote a different kind of line in my text file: wake 4 / mid 2 / eve 2 - burned on a crash report I couldn't hold in my head.

Day 2. The schema, because a ledger with no schema becomes a diary and a diary becomes nothing. One appended line per day, four fields: three energy readings on a 1-5 scale at roughly 08:00, 14:00 and 21:00, then one clause naming where the energy actually went. No categories. No tags. No app. It takes about fifteen seconds a day, which matters more than any of the rest of it, because a ledger that costs two minutes is a ledger I will abandon by Thursday.

Day 3. First honest reading: wake 5 / mid 5 / eve 4. Five hours of real work on the Outbox retry path. The hours tracker would have recorded this as roughly the same day as Day 1. That is the whole complaint in one comparison, and it is the reason I bothered.

Day 6. I notice I am gaming the scale. Rating my own energy at 21:00 after a bad day feels like grading my own homework, and I catch myself writing 3 when the truthful answer is 2, because a 2 looks like an accusation. The fix is dumb and it works: I stopped calling it energy in my own head and started calling it available depth - how many layers of a problem I can hold at once before one slips. Depth is a fact about my brain at that moment. It does not sound like a verdict on my character, so I stopped lying about it.

Day 9. First real finding, and it annoyed me. My 5s do not arrive at the same time every day, but they cluster hard in the first ninety minutes after I wake up, and I had been spending that window on email and App Store Connect. I had been feeding my best cognition to a task any tired person could do. Swapping those two blocks was the highest-return change of the month and it cost nothing but the discomfort of leaving the inbox unread until 10:00.

Day 12. A 1 day. Total. Slept badly, a support email got under my skin, and I sat in front of Xcode for six hours producing a commit I reverted the next morning. Under the hours regime this would have registered as a full working day and I would have felt vaguely virtuous about it. The ledger just says: wake 2 / mid 1 / eve 1 - support thread; reverted everything. No credit for the six hours. That is the point of the instrument. It refuses to pay me for attendance.

Day 14. What is this ledger actually measuring?

Not mood. Not productivity. It measures how much of a problem I can hold in working memory at once, which for a solo developer is the only genuinely scarce input. I have unlimited hours in the sense that nobody is stopping me from sitting at the desk. What I do not have is a second person to hand the hard thing to when my head is thin, and that is exactly the assumption every hours-based system is built on. Time tracking was invented to bill clients and to coordinate teams. Neither of those things is happening here. I am the only worker, the only manager, and the only budget.

Here is the honest comparison after two weeks of running both:

	Hours ledger	Energy ledger
What it counts	Minutes at the desk	Depth available, 3x a day
How I cheat it	Sit still, feel virtuous	Round a 2 up to a 3
What it predicts	Almost nothing	Whether tomorrow's hard task lands
Cost to keep	An app and a habit	One appended line, ~15 seconds
Worst failure	Rewards a bad six hours	Says nothing about why

That last row is not a rhetorical concession. It is where the method broke.

Day 18. The ledger told me I had four low days in a row and offered zero explanation, because I had written the where it went clause lazily: "app stuff," "app stuff," "admin," "app stuff." Four days of data, no signal. A drain field only works if it names something specific enough to be avoided. So I rewrote the rule: the clause must contain a noun another person could recognise. Xcode archive failing on a provisioning profile I did not change is a drain. App stuff is a feeling.

Day 20. Re-reading the fixed lines, the pattern is embarrassing and clear. Interruption is not what costs me. Unresolved ambiguity is. A support email I know how to answer takes eight minutes and costs nothing. A support email I do not know how to answer costs the rest of the morning even if I never open it again, because some part of my head keeps a thread running on it. Ambiguity does not wait its turn. It runs in the background and eats the depth I was saving for the hard task.

Day 22. So I started closing loops in the cheapest way available, which usually means writing one line and getting it out of my head immediately rather than "handling it properly later." The line goes to my own email in about a second, and at the end of the day it also lands under today's heading in my daily note, so I have stopped carrying it around. None of this is a new insight; it is the reason I built my capture app the way I did, and I have argued before that a thought you cannot capture in about a second is already gone. What surprised me is that the ledger measured it. The days after I closed the loops read mid 4, mid 4, mid 5. The days I told myself I would deal with it later read mid 2.

Day 25. The counter-take, because I do not trust a system that only ever confirms me. Energy is a lagging, self-reported, one-observer metric. It has none of the properties you would want in an instrument. I cannot calibrate it against anything, I cannot compare it to yours, and on a bad enough day my ability to rate my own state is exactly the faculty that is impaired. Hours, for all their stupidity, are at least objective. If I had a client to bill or a co-founder to coordinate with, I would keep the timer and I would not apologise for it. The energy ledger works for me because my failure mode is not laziness. It is grinding: sitting at the desk at a 1 and calling it work. If your failure mode runs the other way, this instrument will lie to you in the direction you want.

Day 28. The tally, run with grep and my own eyes, not a dashboard:

Days rated 4-5 at wake: 19 of 30. Days I actually used that window on the hardest available task: 11.
The gap between those two numbers is the whole remaining opportunity, and it is larger than anything a productivity app was ever going to hand me.
Named drains appearing three or more times: unresolved support threads, provisioning and signing errors, and one long-running design decision I kept re-opening instead of deciding.

Day 30. What I keep: the three readings, the drain clause, the fifteen seconds. What I throw away: any attempt to average it, chart it, or turn it into a score. The moment this becomes a number I optimise, I will start optimising the number instead of the work, and I will get very good at scoring 5s on days that produce nothing. The ledger is a mirror, not a KPI. It works precisely because nobody, including me, is grading it.

Day 31 starts tomorrow, and the only change is a fourth field, on trial: what I deferred that day. My suspicion, based on Day 20, is that the deferral list predicts the next day's low reading better than anything I currently write down. I will know in a month.

What if I already know I'm a morning person?

Then you know one of the four things this told me, and it was the least surprising one. The useful findings were behavioural: which specific class of task was eating the good window, and which specific class of open loop was draining the afternoon. Those are not personality facts. They shift month to month, and I could not have guessed either of them from a chronotype.

Is fifteen seconds a day really enough data?

It was enough to change two habits, which is more than eleven months of automatic time tracking ever did for me. Precision is not the constraint here. Survival is. A rich schema I abandon in nine days beats nothing, but it loses badly to a crude schema I still keep on day thirty.

Where I want to be told I'm wrong

I want to hear from anyone running both instruments at once who has a real opinion about the overlap: not a philosophy, a specific case where the hours told you something the energy reading missed. And if you keep any daily self-log that survived past a month, name the one field in it you would fight to keep. Mine is the drain clause, and I am fairly sure it is the only field doing real work.

I develop Simple Memo by myself: an iOS app that takes one line of text and has it in your email roughly a second later. It is also the thing I use to close the open loops this ledger kept catching me carrying around.

The issue tracker was built for a team I don't have

Simple Memo — Wed, 08 Jul 2026 01:40:28 +0000

This is going to be a rant. I'll earn it before the end.

Here is what set me off. Last Tuesday I spent forty minutes grooming a backlog that exactly one person will ever read. That person is me. I moved cards between columns, I set a priority field on each one, I dragged four of them into something my tool insisted on calling a sprint, and at no point in those forty minutes did I produce a line of code, a fixed bug, or a piece of information I did not already have in my head when I sat down.

I have run my product alone for over a year. For most of that year I kept reaching, by reflex, for the same category of software every team I ever worked on used to coordinate itself: the issue tracker. Jira, Linear, GitHub Issues, a Trello board with a tasteful column layout — the brand kept changing, the reflex did not. I want to talk about why that reflex is wrong for a solo dev, because it took me an embarrassingly long time to name what was bothering me.

What I was actually doing for forty minutes

Break down the ceremony of an issue tracker and almost every ritual in it exists to answer a question that a second person would ask.

Story points exist so a team can forecast capacity across several people and argue about it in planning. Status columns exist so that when I hand a ticket to you, you can watch it move from "mine" to "yours" without either of us sending a message. A "definition of done" exists so that two people who disagree about what finished means can settle it in writing before it becomes a fight. Assignee fields, sprint boundaries, WIP limits, triage labels: every one of them is a coordination primitive. They are answers to the problem of getting work through more than one pair of hands.

I have one pair of hands. When I set a story-point value, I am estimating my own capacity to myself, then reading my own estimate back later and feeling vaguely accused by it. When I move a card from "In Progress" to "Review," there is no reviewer. The card is moving from me to me. I had built an entire apparatus for handing work off, and then I stood on both sides of every handoff.

Why this is worse than wasted time

If the tracker only cost me forty minutes a week I would shrug and pay it. The real cost is that the tool quietly reshapes the work to fit its own shape.

A board wants to be tended. An empty column feels like failure; a full "Done" column feels like progress even in a week where I shipped nothing that mattered. I caught myself making tickets for work I had already finished, purely so I could drag them to Done and feel the small hit of it. That is status theater, and I was performing it for an audience of nobody.

Then there is the guilt. A stale board is a quiet daily accusation. Forty-one open tickets, six of them older than a quarter, all of them technically "mine" and none of them moving: the board turns an ordinary backlog into a monument to my own unreliability. On a team that pressure is sometimes useful, because a colleague can see the same board and the shared visibility creates real accountability. Alone, it is just a machine for manufacturing low-grade shame, and I was paying a monthly subscription to run it.

The mismatch underneath all of this is simple. An issue tracker is optimized for state that is shared and asynchronous: many people, touching the same work, at different times, needing a durable record of who holds what. My work is neither. It is one person, holding the whole thing in one head, in more or less continuous time. I was using async-coordination software to coordinate with no one.

What I reach for instead

I keep a single plain-text file. Every line starts with a date and a verb. 2026-07-06 fix the timezone bug in the CSV export. When the line is done I do not drag it anywhere; I put an x in front of it and move on. There are no columns, because there is nobody to hand a column to. There is no status beyond "still here" or "struck through."

Time-bound obligations go in the calendar, because a calendar is honestly better than any tracker at the one job it has: telling me a thing must happen on a specific day. And the only real queue I keep, the only place where work actually arrives from other people, is my email inbox. I wrote a whole separate piece about treating the inbox as the single task queue, so I won't relitigate it here, except to note the principle is the same one running through the text file: the thing that assigns me work is allowed to be the thing that tracks it, and I refuse to keep a second copy by hand.

The one rule under all of it is that capturing a task has to be cheaper than the thought that produced it. If writing a task down takes eleven seconds of choosing a project and a label and a priority, I will not write half of them down, and the unwritten half is where the real bugs hide. So capture is a dated line and nothing else. It is the same instinct that made me build Simple Memo, my own capture app, around a single action instead of a menu: the instant you force someone to decide where a thought goes, you have already lost some of the thoughts. Sorting can happen later, on a quiet Sunday, when sorting is cheap. The capture moment has to stay too dumb to ask questions.

The part where I argue against myself

I said I would earn this rant, so here is the half of it I think is wrong.

There are cases where an issue tracker earns its place even for one person, and they share a tell: a second human shows up somewhere in the loop. The moment my project has outside contributors, a public bug tracker stops being ceremony and becomes the actual shared surface those people need. I cannot ask a stranger on the internet to append a dated line to my private text file. Anything with a compliance or audit requirement needs the durable, timestamped, who-changed-what record that a tracker gives you for free and a flat file does not. And there is one more that has nothing to do with other people at all: scale over time.

That last one is the trade-off I am genuinely unsure about. My text file is fast to write and miserable to query. Ask me what I was working on in March and I am reduced to grepping the file and reading around the matches. A real tracker would let me filter by label and date in a second. For a project I intend to run for a decade, I may be trading away a queryable history that future-me will badly want, in exchange for a capture speed that present-me enjoys today. I have chosen present-me every time so far. I am not at all certain that is the right person to keep choosing, and I notice I grow less certain the older the file gets.

Before you tell me I'm wrong

Some of you run a personal tracker and love it, and some of you are on teams where the board is the only reason the work ships at all. I am not coming for your board. I am coming for the reflex: the assumption that because real software teams track work in Jira, a party of one should too.

So here is the question I actually want answered, because I think it exposes the whole thing. What is the one field in your tracker that you fill in on every single ticket and have never once read back? Story points is my bet. Tell me I'm wrong, and tell me which field genuinely earns its keep when nobody but you will ever look at it.

I build Simple Memo alone — an iOS app that turns a line of text into a sent email in about a second, then gets out of the way. I post here a couple of times a week, usually when one of my strong opinions survives a fight with my own logs.

Taking apart the write path into another app's iCloud folder

Simple Memo — Fri, 03 Jul 2026 13:23:09 +0000

I am going to take apart, layer by layer, roughly 90 lines of Swift that let my app write a single line into a file owned by a different app, inside that app's own iCloud Drive container, with no plugin and no server in between. Four layers, one API most iOS developers never touch on purpose, and one bug that cost me a weekend because I trusted FileHandle more than I trusted Apple's warning label on it.

What's in this teardown:

Why an iOS app cannot just guess another app's iCloud Drive path, and what UIDocumentPickerViewController actually grants you
Why the permission it grants goes stale, and the bookmark trick that survives a relaunch
Why a plain append can silently corrupt a file mid-sync, and what NSFileCoordinator changes about that
The one case none of the above solves, and how I detect it instead of pretending it can't happen

The thing I'm taking apart

Since the end of May, a small iOS note-to-email app I build has had an optional feature: send a memo, and a timestamped line also lands in a markdown vault stored in iCloud Drive, formatted the way a daily note expects. No server round trip, no companion plugin installed inside the vault. One app writes into a folder it does not own, on a filesystem two different processes are actively syncing at the same time.

The app is called Simple Memo, and I wrote about the two-layer capture-then-curate shape of its note system in an earlier post. This one is about the pipe underneath it, not the shape: the part that actually moves bytes across the sandbox boundary. That premise hides four separate problems, and I built the feature in the wrong order the first time. I wrote the "append a string to a file" part first, decided it was basically done, and only found the other three problems by making them happen on my own phone. Here they are, in the order iOS actually enforces them, not the order I discovered them.

Why can't I just hardcode the vault path?

The instinct is to construct a path: ~/Library/Mobile Documents/iCloud~md~<vault app>/Documents/<vault name>/Daily/2026-07-03.md, or something close to it, and open a FileHandle on it. On macOS this sometimes works, because the sandbox is looser and Full Disk Access is a checkbox away. On iOS it does not work, on purpose. Every app's iCloud container is a separate sandbox; one app cannot enumerate or open another app's container by path, no matter how well you know the naming convention, because the naming convention is not a contract — it is an implementation detail Apple can and does change between OS versions.

The only sanctioned door in is UIDocumentPickerViewController. The user picks a folder (their vault folder, in my case) through the system file picker, and iOS hands your process a security-scoped URL — a token, effectively, not just a path string. That URL is only valid while you call startAccessingSecurityScopedResource() on it, and only for as long as the system feels like honoring it in that session. This is the first real design constraint: the user has to grant access once, explicitly, through UI you do not control. There is no way to skip that dialog and no way to pre-select the folder for them. I tried, because a one-tap flow was the whole point of the app; Apple's sandbox model says no, and the "why" is the same reason your banking app can't read your email app's cache: cross-app storage access is opt-in per user gesture, not per developer intent.

func requestVaultAccess(from viewController: UIViewController) {
    let picker = UIDocumentPickerViewController(forOpeningContentTypes: [.folder])
    picker.delegate = self
    viewController.present(picker, animated: true)
}

func documentPicker(_ controller: UIDocumentPickerViewController,
                     didPickDocumentsAt urls: [URL]) {
    guard let vaultURL = urls.first else { return }
    guard vaultURL.startAccessingSecurityScopedResource() else {
        // grant refused or already revoked — surface this, don't silently no-op
        return
    }
    defer { vaultURL.stopAccessingSecurityScopedResource() }
    persistBookmark(for: vaultURL)
}

That last line, persistBookmark, is where layer two starts, and it is where I made my first wrong assumption.

Why does the permission go stale between launches?

A security-scoped URL does not survive process death. Quit the app, relaunch it, and the URL you stored in memory (or, if you were careless, in UserDefaults as a plain path string) is worthless — you'll get a permission error on the very first write, every single time, and the failure mode looks exactly like a bug in your write code instead of what it actually is: a missing re-authorization step.

The fix is a security-scoped bookmark, which is a small opaque Data blob you create once and can resolve back into a working URL on every future launch, without asking the user again:

func persistBookmark(for url: URL) throws {
    let bookmark = try url.bookmarkData(
        options: [],
        includingResourceValuesForKeys: nil,
        relativeTo: nil
    )
    UserDefaults.standard.set(bookmark, forKey: "vaultBookmark")
}

func resolveVaultURL() -> URL? {
    guard let data = UserDefaults.standard.data(forKey: "vaultBookmark") else { return nil }
    var isStale = false
    guard let url = try? URL(
        resolvingBookmarkData: data,
        options: [],
        relativeTo: nil,
        bookmarkDataIsStale: &isStale
    ) else { return nil }
    if isStale {
        // the folder moved, got renamed, or iCloud re-issued its identity — bookmark is dead, re-prompt
        return nil
    }
    return url
}

isStale is not a hint you can ignore. I ignored it for about two weeks of internal testing, on the theory that a stale bookmark would still resolve to something close enough. It does not. A stale bookmark that you use anyway will sometimes resolve to a URL that looks correct and fails on the write, and sometimes resolve to nothing your app can read at all, and the difference depends on exactly how the underlying folder moved — which is not something I control, because the user can rename their vault, or iCloud can re-shuffle the container during a sync conflict, entirely outside my app's runtime. Once isStale comes back true, the only honest move is to drop the bookmark and ask the user to re-grant access through the picker. I now show one line of UI for that ("Reconnect your vault folder") instead of failing the write silently, which is what the app did for those first two weeks.

Why does a plain append corrupt the file mid-sync?

This is the layer that cost me the weekend, and it is the one most tutorials about FileHandle do not mention at all, because most tutorials are not writing into a file that a different process (the iCloud daemon) might be reading, uploading, or rewriting at the exact same moment.

A naive append looks reasonable:

let handle = try FileHandle(forWritingTo: fileURL)
handle.seekToEndOfFile()
handle.write(lineData)
try handle.close()

This works close to 100% of the time on a phone sitting idle. It becomes unreliable the moment the file is actively syncing — for example, right after the user edited the same daily note on their Mac and iCloud is mid-upload of a newer version when your write lands. I reproduced this by editing the same daily note on my Mac and firing a memo from my phone within the same few seconds, on a loop, forty-some times. Three of those runs produced a daily note with a line inserted in the middle of another line's bytes: not a merge conflict dev.to readers would recognize from git, just corrupted UTF-8 you'd only notice by opening the file and seeing garbled text.

FileHandle has no concept of "someone else might be touching this file right now." NSFileCoordinator does — it is the actual mechanism iCloud Drive apps are supposed to use for exactly this, and it existed the entire time; I just did not reach for it on the first pass because the "write a string to a file" tutorials online almost never mention that a coordinator exists.

func appendLine(_ line: String, to fileURL: URL) throws {
    let coordinator = NSFileCoordinator()
    var coordinationError: NSError?
    var writeError: Error?

    coordinator.coordinate(writingItemAt: fileURL, options: .forMerging, error: &coordinationError) { safeURL in
        do {
            if !FileManager.default.fileExists(atPath: safeURL.path) {
                try Data().write(to: safeURL)
            }
            let handle = try FileHandle(forWritingTo: safeURL)
            defer { try? handle.close() }
            handle.seekToEndOfFile()
            handle.write(Data((line + "\n").utf8))
        } catch {
            writeError = error
        }
    }

    if let coordinationError { throw coordinationError }
    if let writeError { throw writeError }
}

Two details in that block are the ones I would flag if I were reviewing someone else's PR. First, .forMerging, not the default writing intent, which assumes you are replacing the whole file. .forMerging tells the coordinator (and, by extension, any NSFilePresenter the other app registered, including that app's own sync layer if it's watching) that this is an additive change, which changes how the coordinator schedules your access relative to a concurrent iCloud upload instead of just serializing "biggest write wins." Second, the coordinator hands you a safeURL inside the closure — not the URL you passed in. Writing to the original fileURL instead of the coordinator-provided one defeats the entire point; I found that mistake in my own first draft by re-reading the closure a third time, not by a test failing.

I re-ran the same forty-loop stress test after switching to the coordinator. Zero corrupted files across three separate runs. That is not a controlled benchmark (it is a home-brew stress test on one Mac and one phone), but it is the difference between the bug reproducing reliably and not reproducing at all, and for a background feature nobody watches while it runs, "not reproducing" is the bar that matters.

The naive path vs. the coordinated path

	Plain `FileHandle` append	`NSFileCoordinator` + `.forMerging`
Survives a concurrent iCloud upload	No — corrupted 3/40 runs in my test	Yes — 0/40 in the same test
Works after an app relaunch	Only with a manual re-grant	Yes, via bookmark resolution
Detects a placeholder (not-yet-downloaded) file	No — throws a generic "file not found"	No by itself — needs an explicit download check (below)
Extra code vs. a plain append	—	About 15 lines
Requires the user to grant folder access once	Yes	Yes (same requirement either way)

The one thing this doesn't solve

None of the above helps if the target file is an iCloud placeholder your phone hasn't downloaded yet — which happens the first time you point the app at a vault someone else set up on a different device, or after the OS evicts an old file to save local storage. NSFileCoordinator will hand you a safeURL that exists in the directory listing and still fails the moment you try to actually read or write its bytes, because the bytes are not on the device.

You have to check for this explicitly, before you coordinate the write:

let values = try fileURL.resourceValues(forKeys: [.ubiquitousItemDownloadingStatusKey])
if values.ubiquitousItemDownloadingStatus != .current {
    try FileManager.default.startDownloadingUbiquitousItem(at: fileURL)
    // and then either poll resourceValues again, or accept the write will
    // land on next app launch — I chose the second, on purpose
}

I chose to let the write silently defer to the next launch rather than block the UI on a download of unknown length over an unknown connection. That is the one deliberate trade-off in this whole pipe: I could hold the user's memo in a queue and retry the download-then-write on a timer, which would feel more "real-time," or I could accept that a first-time cross-device vault sync is rare enough that a one-launch delay is an acceptable cost for not adding a retry queue to a feature that already has three other failure modes to track. I picked the second, and I'm not fully sure it's the right call — it's the kind of decision that looks obviously correct until someone hits it on a slow hotel Wi-Fi and can't tell why their note didn't show up.

A few questions I keep getting

Does this need the Files app permission, or a special entitlement?
No special entitlement. UIDocumentPickerViewController for folder access is a standard framework API; the entitlement you do need is the ordinary iCloud Documents capability if you also want your own app's container to sync, which is a separate concern from writing into someone else's.

Does this work if the other app isn't running?
Yes, the write happens against the filesystem, not against the other app's process. The receiving app does not need to be open on any device for the append to land; it will pick up the change the next time it's opened or the next time it polls for changes, same as any other iCloud-synced edit made from another device.

Why not just use a plugin inside the other app instead?
Because that requires the user to install and configure something inside a second app, which is a much heavier ask than granting a folder once through a system picker — and it ties your feature's reliability to another app's plugin API staying stable, which is a dependency I did not want to own.

The one thing that mattered after taking it apart

Every layer here exists because of the same rule: iOS does not trust one app's judgment about another app's files, and it is right not to. The permission model, the bookmark, the coordinator — none of it is incidental complexity you can shortcut past with a clever enough FileHandle call. The closest thing to a lesson I'd underline twice is that .forMerging line: the entire corruption bug disappeared behind one enum case I would have found in the documentation on day one if I had gone looking for "how do other apps write into iCloud files safely" instead of "how do I append to a file in Swift." The second question has a five-line answer that is wrong for this exact situation, and the wrong answer looks completely fine until two devices touch the same file within the same second.

If you've built a write path into a file iCloud is actively syncing, I'd like to know whether NSFileCoordinator alone solved it for you, or whether you also had to add your own conflict resolution on top of it — that's the part I'm least confident I've fully covered.

I write at @simple_memo. Simple Memo is the iOS app behind the pipe this post takes apart. On the days I have background note-forwarding turned on, the same write path lands a line in my vault.

The prompt is the cheap part. The context is the product.

Simple Memo — Tue, 30 Jun 2026 13:27:55 +0000

Suppose the model forgot you completely between every message. No memory, no history, no idea who you are or what you were doing thirty seconds ago. Every time you hit send, it wakes up with total amnesia, reads whatever you put in front of it, answers, and dies.

That is not a thought experiment. That is just how a large language model works. The weights are frozen. Between two API calls it remembers nothing. Everything that feels like continuity (the model "knowing" your codebase, your tone, the bug you were chasing) is text that something assembled and handed over again, one more time, as if for the first time.

I find it useful to take that fact and push it all the way to its conclusion, because the conclusion quietly changes what I think I am building when I work with these tools.

Here is the first thing that falls out of it. If the model is amnesiac, the prompt is the most disposable artifact in the whole system. I used to treat the prompt as the thing I was crafting: the careful wording, the role-play, the "you are an expert" preamble. But a prompt lives for exactly one call and then it is gone. It is a paper airplane. Whatever value I thought I was banking in my prompt-writing skill was mostly evaporating on send.

The durable thing, the thing that actually decides whether the answer is any good, is the context I assembled around the prompt. Which files I pulled in. Which past decision I pasted back. Which error log, which schema, which three sentences of "here is why I do it this weird way." That assembly is the real work. It is also the part I kept treating as an afterthought while I fiddled with adjectives in the instruction line.

Why does this reframe matter?

Because it moves the engineering surface to a different place than most people are looking.

The industry has been circling this for about a year. Sometime in mid-2025 the phrase "context engineering" started showing up as the successor to "prompt engineering," and by 2026 it is the default framing. Anthropic published a whole piece on context engineering for agents; the trade reports are saturated with it. The short version of the shift: prompt engineering is about how you ask, context engineering is about what the model can see when you ask. The first is a sentence. The second is a system.

I think the reframe is correct, but I want to put it more bluntly than the vendor posts do. The prompt is the cheap part. It is cheap to write, cheap to copy, cheap to throw away. The context is the product. It is expensive to assemble, expensive to keep current, and it is the one part nobody can lift from you, because it is made entirely of your specifics: your code, your constraints, your year of small decisions.

And the moment context becomes the product, you walk straight into the thing the big-window marketing skips over. More context is not free. Models in 2026 ship million-token windows, and a few advertise ten million. But a long context is not a filing cabinet you can stuff and forget. Every serious evaluation I have read lands on the same failure: facts buried in the middle of a long context get lost, with accuracy dropping somewhere around 10 to 25 percent compared to the same fact placed at the start or the end. The bigger the window, the more "middle" there is to lose things in.

So context is not "paste everything." Context is curation under a relevance budget. That is an editorial job, not a storage job, which is exactly why it does not get easier as the windows grow. A bigger truck does not make you a better packer.

What this changed about my own notes

Here is where I stopped theorizing and looked at my own desk. If context is the product, then for me, working alone, the raw material for that product is the pile of things I have written down. My notes are not a memory aid anymore. They are the storage layer that everything I hand a model gets drawn from. A half-sentence I captured in a meeting in March becomes, in June, the exact line I paste in to stop the model re-suggesting the approach I already rejected and forgot I rejected.

Which means the bottleneck is not the model, and it is not the prompt. It is capture. A thought I failed to write down is context that will never exist, no matter how large the window gets. I build a note-to-email app, so I am biased here, but the bias grew out of the problem rather than the other way around: the cheapest lever on the quality of my context is the friction of getting things into it. A lot of mine now goes in by voice. I talk, it transcribes on the device, the line lands while my hands are still on the keyboard or the steering wheel. The method is not the point. The point is that lowering capture friction raises the ceiling on every future prompt, and almost nobody budgets for it.

I can date the moment this stopped being abstract. One afternoon in April I spent two hours fighting the same suggestion from Cursor, which kept proposing I cache a value I had very deliberately decided not to cache, for a reason that lived only in my head. Each time, I re-typed some version of that reason into the chat, got a fine answer for that one turn, closed the tab, and lost the explanation again. I was doing prompt engineering, I was doing it competently, and it was worthless, because none of it survived the session. The fix was not a sharper prompt. The fix was writing one durable line, the decision and its reason, into the place my notes already live, so that the next time the question surfaced I pasted instead of re-argued. The two hours I burned were not a model failure. They were a context failure, and the gap was entirely on my side of the keyboard.

The shape of a context line that earns its keep, for me, looks boring on purpose:

2026-03-14 decided: no background refresh on the watch app.
reason: watchOS kills long-running sends; relay through the phone instead.

That is not a note to myself. It is a paste-ready unit of context. When the model cheerfully suggests background refresh on the watch three months later, I do not argue with it and I do not re-derive the reasoning. I paste the line. The decision and the reason for it travel together, into the model's amnesiac little world, as if I had just explained both for the first time. I keep a versioned log of every prompt I send for the same reason; the prompt I wrote is disposable, but the context that made it work is worth filing.

The half of this I do not believe

Now the part where I argue with my own thesis, because I only half-run it.

If context is genuinely the product, the logical move is to hoard. Capture everything, store everything, retrieve aggressively, feed the model a fat dossier every time. I do not do that, and I have come to think hoarding is a trap, for two reasons. The lost-in-the-middle problem means a bloated context actively hurts: the signal drowns in the volume. And a context store you never prune rots. Last year's decision, the one I reversed in March, is still sitting there ready to mislead a model that has no way to know it is stale. A second brain stuffed with expired context is worse than a small one, the same way a confident wrong code comment is worse than no comment at all.

So the honest version of my position is narrower than the slogan on the title line. Context is the product, but the product is edited, not accumulated. The skill is not "save more." It is knowing which one paragraph, out of a year of notes, to put in front of the model right now, and being willing to throw the rest out of the frame. That is a judgment I cannot automate yet, and I am not fully convinced I want to.

So I run half my own thought experiment. I take seriously that the model forgets me, and I pour the effort into the context instead of the prompt. I refuse to take seriously the idea that more context is better, because the evidence and my own rotting notes agree that it is not.

If you work with these tools every day, I am curious about one specific thing, because it is exactly where I am least sure of myself. What is the one piece of context you catch yourself re-explaining to the model over and over, the decision or the constraint or the "no, it has to be done this way," that you have never managed to store somewhere it gets reliably pulled back in? I want the actual line, not the category. I suspect the collected answers would draw a pretty accurate map of where the tooling still pretends the model remembers you, when it plainly does not.

I'm a solo dev. I build Simple Memo, an iOS app that turns a thought into an emailed note before I lose it. I write here every few days about working with LLMs and shipping things alone.

Five things shipping a product alone took from me

Simple Memo — Tue, 23 Jun 2026 13:24:31 +0000

My notebook has a running page I never meant to start. It is a list of things shipping alone has taken from me. Not skills I had to learn, the list of those is boring and endless, but things I used to have and gave up the day I decided to run a product by myself. I added five entries to it over the past few months. They are not complaints. Most of them I would give up again. But I had assumed solo work was mostly an addition problem, a matter of learning more jobs, and the page is my evidence that it is at least as much a subtraction problem. Here are the five, copied out and cleaned up enough to read.

The second reader

The first thing to go was the person who reads my work before the world does. No reviewer on the pull request, no editor on the release notes, nobody who notices that the button says "Cancle." I used to think code review was about catching logic bugs. Working alone taught me that most of its value was catching the dumb, surface things a tired author cannot see in their own work, because the brain helpfully renders what you meant instead of what you typed.

I have tried to buy the function back without the person. I let a diff sit overnight before I merge it, because the version of me that reads it in the morning is a different enough reader to catch a few things. I write the reason for a change in the commit body as if I were explaining it to someone, and the act of explaining surfaces the parts that do not hold up. I lean on tests harder than I would on a team, because a test is the one reviewer that never gets bored on a Friday.

None of it fully replaces the second reader. I keep a small file of bugs that shipped because no one but me looked: a date-math error that was off by a day only in one time zone, a setting that silently did nothing for two releases. Every entry is a thing a five-minute glance would have caught. I have made peace with the fact that some of those will always get through, and that part of the cost of working alone is paid by the people who hit them first.

The roadmap

I gave up the plan I could show people. Not planning itself, but the kind with quarters on it, the kind where "search is coming in the fall" is a thing you can say and mean. A team can make that promise because the plan survives any one person's bad week. Alone, I am the only resource, and the plan does not survive my bad week, my flu, the two days I lose to a bug that turns out to be a typo. Every estimate I make is really an estimate of a single human's uninterrupted attention, which is the least reliable quantity I know.

So I stopped keeping a roadmap and started keeping a very short queue. I plan the next thing, sometimes the next two, and I refuse to dignify anything past that with a date. It feels irresponsible some days, like flying without instruments, and on the days a user asks when a feature is coming I have nothing honest to offer but "I don't know yet."

What I got back is that I mostly stopped lying, including to myself. A roadmap for one person is a forecast dressed up as a commitment, and pretending otherwise just means apologizing later. The short queue is uglier and truer. I lost the comfort of a plan and the small authority that comes with being able to announce one, and I am still not sure that trade was free.

Being good at one thing

I used to be good at one thing. Going solo, I traded depth for surface area, and now I am passable at maybe six jobs and excellent at none. I design screens a real designer would quietly fix. I write marketing copy that makes actual marketers wince. My backend works and would not impress anyone who does backends for a living. Every part of the product carries the faint fingerprint of an amateur, because every part of it was made by someone doing that job part-time.

For a while I treated this as a problem to fix, as if I could read enough about typography between releases and come out a designer. I cannot. The honest move was to accept the ceiling and decide where to spend my few hours of real focus. I let most things be a competent five out of ten and pour the effort into the one or two places where the product actually has to be sharp, which for me is the speed of the core action, the thing the whole app is about.

The strange gift is that nothing gets lost in a handoff, because there is no handoff. The person who designs the screen is the person who writes the code behind it and answers the support email when it confuses someone. The seams between jobs, where teams leak the most, simply are not there. I gave up being good at one thing and got a blurry, end-to-end view of the whole that I do not think a specialist ever quite sees.

Someone else on call

There is no one else on call. When something breaks at one in the morning, the rotation is me, and after me it is nobody. The first time my send pipeline started failing silently (a server hiccup that left notes stuck instead of delivered), I found out because I happened to be the user who noticed, and I fixed it at an hour no employer could have asked anyone to work.

The lesson was not "work more hours." It was that I had to engineer the absence of a team into the product itself. If no human is on call, the software has to fail safe on its own. So the send path became an offline-first Outbox: a note is written to durable local storage the instant you hit send, and a background worker keeps retrying delivery with backoff until it succeeds, whether that is now, after a reboot, or after the subway. I built it less for the user's convenience than for my own sleep. The resilience I could not provide as a person, I had to provide as code.

I gave up the safety net of someone else handling it, and the cost is that these days I over-engineer for failure in a way a bigger team might call paranoid. Maybe it is. But when you are the entire on-call rotation, the cheapest incident is the one that quietly resolves itself while you sleep, and I will spend real effort to buy more of those.

The person who tells me I'm wrong

The last entry is the one I underestimated most. I gave up the colleague who tells me I am wrong before the market does. Alone, every idea I have is reviewed by a board consisting entirely of me, and that board approves almost everything, because my bad ideas show up wearing the same confidence as my good ones. There is no one in the room to say "that is a feature for you, not for users," which is the single most useful sentence I have ever been handed and now have to remember to say to myself.

I have cobbled together substitutes. I keep a decision journal where I am required to write the strongest case against what I am about to do, and writing it honestly kills a fair number of plans. I ship small and fast so reality gets to disagree with me early, while a mistake is still cheap. And I have started treating the comment section as a de-facto review board. When I wrote here recently that capture latency is the only note metric that matters, a reader who builds a writing tool replied with the same finding from his own product: he had a category prompt blocking the start of a draft, removed it, and watched people actually start writing. That time the board agreed with me. But agreement from a stranger who tested the idea independently is worth more than agreement from the board inside my own head, precisely because it could have gone the other way.

That is the one I would warn a new solo dev about. You can replace the reviewer and the on-call engineer with discipline and code. Replacing the person who disagrees with you is harder, because the failure mode is invisible from the inside. You do not feel an echo chamber. You just feel correct.

What is still on the page

The list in my notebook is not finished, and I have a feeling it never will be. Subtraction keeps showing up where I expected addition. I will copy out the next batch once it is long enough to be worth reading.

If you ship alone too, tell me the entry you would add: the specific thing you gave up that you did not expect to miss, and whether you bought it back somehow (with a habit, a tool, a piece of code) or just learned to live without it. I am collecting these now, and the ones that still sting are the useful ones.

I'm a solo developer. Simple Memo is the iOS app I make by myself: you type a line and it lands in your email about a second later. I write here every few days, mostly about the parts of going it alone I had to learn the slow way.

A thought you can't capture in a second is already gone

Simple Memo — Fri, 19 Jun 2026 13:15:10 +0000

A thought you cannot capture in about a second is, for practical purposes, already gone. Not slower to retrieve. Not filed somewhere inconvenient. Gone, with no copy anywhere, and usually you do not even notice the loss, which is the part that should bother you.

I spent years treating my note-taking like a storage problem. I compared apps by how they organized things: folders versus tags, backlinks versus search, local files versus a synced database. Every few months I migrated to whatever promised a tidier shelf. None of it changed the thing that was actually costing me ideas, because the thing that was costing me ideas happened before storage was ever involved. It happened in the gap between having a thought and getting it out of my head, and that gap is measured in seconds, not in retrieval quality.

There is an old experiment that I think about more than is probably healthy. In 1959, Lloyd and Margaret Peterson gave people three-letter strings to remember, then immediately made them count backward by threes so they could not rehearse. After three seconds of that distraction, people still recalled the letters about eighty percent of the time. After eighteen seconds, recall collapsed to around ten percent. Eighteen seconds, and the letters were gone, because attention had been pointed somewhere else for less time than it takes to find the right app and tap into the right note.

That is the real shape of the problem. Human working memory is not a hard drive that holds your thought patiently until you get around to saving it. It is a leaky bucket, and the leak is fast. So the requirement on the moment of capture is harsher than almost any other requirement in a personal system: it has to be fast enough that catching the thought beats losing it, every single time, including on the days you are tired, walking, holding something in your other hand, or being talked at by a stranger.

Here is where most systems quietly fail, and they fail for a reason that looks like a virtue. They make capture happen inside structure. To write the thought down, you first open the app, then you are looking at a hierarchy, and the hierarchy asks questions. Which notebook. Which folder. Which tag. Does this belong with the other thing or is it new. Each question is a small decision, a few hundred milliseconds of deliberation, and a few hundred milliseconds is enough. While you are deciding where the thought goes, the thought is already draining out of the bucket. You end up with an immaculately organized system that is missing exactly the ideas that mattered most, because good ideas tend to arrive at the worst possible moments for filing.

So I started measuring my own setup with a single number, and it is the only note-taking metric I trust now: how long, in seconds, from the instant I have a thought to the instant it is recorded somewhere safe and I can stop holding it in my head. Not how searchable it is later. Not how nicely it is filed. Just the latency of the catch. When I started timing that honestly, my elaborate system was costing me three to five seconds per capture, sometimes more if I hesitated over where something belonged, and I could feel the hesitation as a kind of low background tax on thinking. I had been optimizing the warehouse while the loading dock leaked.

Cutting that number down turned out to be almost entirely a matter of removing decisions, not adding features. The capture surface has to be dumb on purpose. No folder prompt. No tag picker. No "which notebook." A line goes in, it lands somewhere I trust, and I keep walking. Everything that feels like organizing has to be ripped out of the moment of capture and pushed to later, because organizing is a decision and decisions are exactly what the fast layer cannot afford. The discipline is counterintuitive: to keep more of my thinking, I had to let the capture step get noticeably stupider.

I want to be fair to the other side, because there is a real objection here. Capture that records everything and organizes nothing just relocates the problem. A pile of undifferentiated lines is not a second brain; it is a junk drawer, and a junk drawer you cannot search is arguably worse than not capturing at all. That is true, and I am not arguing against organization. I am arguing against doing it at the wrong time. Curation, structure, linking, deleting the two a.m. thought that did not survive contact with morning, all of that is real work and all of it deserves a place. Its place is later, at a desk, where I have minutes and not a second and a half. The mistake is collapsing two jobs with two completely different latency budgets into one screen and one moment.

The reason this matters for shipping, and not just for note-taking, is that the same friction shows up everywhere I work alone. The idea for the fix to a bug, the realization about why a feature is not landing, the one sentence that finally explains the product, none of these arrive on a schedule and most of them arrive when my hands are full. As a solo developer I do not have a meeting where someone writes my ideas on a whiteboard, and I do not have a colleague who remembers the thing I said in the hallway. If I do not catch it in the first second, there is no backstop. The friction in capture becomes, very directly, friction in what I manage to build, because the things I never recorded are things I never act on.

I have stopped being precious about the storage end as a result. Plain lines, timestamped, in a format I will still be able to read in ten years, is enough for the bottom of the system, and I would rather have a boring durable store and a fast front door than a beautiful database with a slow one. If I have to choose between a system that captures in one second and organizes clumsily, and a system that organizes brilliantly and captures in five, I take the first one without thinking, because the first one keeps the raw material and the second one loses it. You can always build a better reader on top of lines you actually kept. You can never retroactively capture the thought you let drain away while deciding where to put it.

None of this is a productivity hack, and I am suspicious of the genre. It is closer to an accounting correction. For years I was counting the wrong cost. I measured my note system by how it stored and retrieved, when the dominant cost was sitting upstream of both, in the half-second of friction I had never thought to measure. Once I started measuring that number and protecting it, the rest of the system got simpler, not more complex, because most of what I had been adding was structure that the fast layer was paying for and the slow layer should have owned.

So the whole claim, restated as plainly as I can: a thought you cannot capture in about a second is already gone, the cost of that loss is total and silent, and the only way to keep more of your own thinking is to make the moment of capture too dumb to ask you any questions. Optimize the second. The shelves can wait.

What I cannot see is your version of this. When a thought hits you in the middle of something else, what is your real capture latency, one second or ten or never, and do you even notice the ones that get away?

I build Simple Memo on my own: a one-tap iOS app that gets a thought out of my head and into my email in about a second, before I can lose it. I write here every few days about the parts of building solo I had to get wrong first.

iOS 26's SpeechAnalyzer on a live mic: the 5 things the docs don't tell you

Simple Memo — Tue, 16 Jun 2026 11:23:29 +0000

This is a condensed version. The full write-up — with the complete SpeechSession, the AudioBufferConverter, and the SFSpeechRecognizer → SpeechAnalyzer migration table — lives on the original post, and the runnable sample is on GitHub (MIT).

iOS 26 replaces SFSpeechRecognizer with SpeechAnalyzer + composable modules. The new model is nicer — an orchestrator you attach modules to, optimized for longer on-device audio, no "enable dictation in Settings" requirement. But if you follow the WWDC sample to wire it to a live microphone, you can end up with code that compiles and produces no text. Here are the five things that cost real time.

The mental model

mic ─► AVAudioEngine.installTap ─► AVAudioConverter ─► AnalyzerInput
                                                          │
                                    SpeechAnalyzer([ SpeechTranscriber ])
                                                          │
                            for try await result in transcriber.results
                                result.text (AttributedString) / result.isFinal

SpeechAnalyzer coordinates; you attach a SpeechTranscriber. Audio goes in as AnalyzerInput; results come out of an AsyncSequence.

guard let locale = await SpeechTranscriber.supportedLocale(equivalentTo: .current) else {
    throw Failure.localeNotSupported
}
let transcriber = SpeechTranscriber(
    locale: locale,
    transcriptionOptions: [],
    reportingOptions: [.volatileResults],   // partial text WHILE speaking
    attributeOptions: []                     // add .audioTimeRange for per-word timing
)
let analyzer = SpeechAnalyzer(modules: [transcriber])
let analyzerFormat = await SpeechAnalyzer.bestAvailableAudioFormat(compatibleWith: [transcriber])

1. You must convert the audio buffer (the #1 trap)

AVAudioEngine's input node format (often 48 kHz, hardware-dependent) usually does not match SpeechAnalyzer.bestAvailableAudioFormat(compatibleWith:). Feed a mismatched buffer and you get a clean compile and zero transcription — no error. Run every buffer through AVAudioConverter first.

let converter = AudioBufferConverter()   // capture locals; never touch self in the tap
let input = audioEngine.inputNode
let micFormat = input.outputFormat(forBus: 0)

input.installTap(onBus: 0, bufferSize: 4096, format: micFormat) { buffer, _ in
    guard let converted = try? converter.convert(buffer, to: analyzerFormat) else { return }
    builder.yield(AnalyzerInput(buffer: converted))
}
audioEngine.prepare()
try audioEngine.start()

2. The model downloads on first use — handle offline

Transcription is on-device, but the language model is a system-shared asset that may not be installed yet (it doesn't count against your app bundle). A first run with no network can't download it, so handle that state explicitly instead of failing silently.

let installed = await Set(SpeechTranscriber.installedLocales.map { $0.identifier(.bcp47) })
if !installed.contains(locale.identifier(.bcp47)) {
    if let request = try await AssetInventory.assetInstallationRequest(supporting: [transcriber]) {
        try await request.downloadAndInstall()   // has .progress for a UI
    }
}

3. Volatile vs. finalized results

reportingOptions: [.volatileResults] gives fast partials while the user is still speaking; result.isFinal marks committed text. Show volatile dimmed, replace it on a final, persist only finals. result.text is an AttributedString.

for try await result in transcriber.results {
    let piece = String(result.text.characters)
    if result.isFinal { finalizedText += piece; volatileText = "" }
    else              { volatileText = piece }
}

4. There is no Custom Vocabulary

SFSpeechRecognizer had contextualStrings to bias toward known terms. SpeechAnalyzer, as of iOS 26.0, exposes no equivalent. If your domain is full of proper nouns or jargon, budget for that gap now.

5. watchOS: SpeechAnalyzer isn't there — but voice input still is

SpeechAnalyzer ships on iOS, iPadOS, macOS, visionOS and tvOS 26 — not watchOS. That doesn't mean "no voice on the Watch": you fall back to the system dictation UI, which hands back finished text (you lose volatile results, time ranges, and your own tap).

// watchOS — the system handles dictation and returns text:
TextFieldLink(prompt: Text("Speak or type")) {
    Image(systemName: "mic.fill")
} onSubmit: { text in send(text) }

A note on latency (with the conditions attached)

The most-cited SpeechAnalyzer latency figure is a WWDC25-era developer-forum report of ~14s+ to the first result on an iPhone 16 Pro (iOS 26.0 beta, Xcode beta 5). On shipping iOS 26.5, on an iPhone 16e — the non-Pro A18, the least powerful A18 device — time to the first volatile result is ~0.3–0.5s on a warm start (model installed, locale allocated). First-ever launch is different (it downloads the model once), so budget for that path separately and show progress.

This is a first-party measurement (time-to-first-volatile-result), not a controlled head-to-head — different device, shipping OS vs beta. Measure on your own device and publish device + OS + metric alongside the number. The likely takeaway: the beta-era latency was a preheat/config/beta issue, not a hardware limit — on-device transcription runs primarily on the Neural Engine, the same 16-core unit across the whole A18 family.

Swift 6 concurrency footnote

The tap closure runs on a real-time audio thread. Under complete strict concurrency, capture only locals (the continuation, the target format, a fresh converter) and never touch a @MainActor object inside the tap — then it compiles without @unchecked Sendable.

Full code and the migration table: github.com/simplememofast/ios26-speechanalyzer-live-mic (MIT). Corrections from real device builds welcome via PR.

iOS 26 SpeechAnalyzer: what I learned wiring it to a mic

Simple Memo — Tue, 09 Jun 2026 13:25:07 +0000

import AVFoundation
import Speech

@Observable
@MainActor
final class LiveTranscriber {
    // Two strings on purpose. One is rewritten constantly, one is permanent.
    private(set) var volatile  = AttributedString()   // the gray, live guess
    private(set) var committed = AttributedString()   // finalized text, never rewritten

    private var analyzer: SpeechAnalyzer?
    private var transcriber: SpeechTranscriber?
    private var inputBuilder: AsyncStream<AnalyzerInput>.Continuation?
    private var analyzerFormat: AVAudioFormat?
    private var resultsTask: Task<Void, Never>?
    private let engine = AVAudioEngine()

    func start(locale: Locale = .current) async throws {
        let transcriber = SpeechTranscriber(
            locale: locale,
            transcriptionOptions: [],
            reportingOptions: [.volatileResults],   // opt in to live partials
            attributeOptions:  [.audioTimeRange]    // each run carries its audio span
        )
        self.transcriber = transcriber
        analyzer = SpeechAnalyzer(modules: [transcriber])
        analyzerFormat = await SpeechAnalyzer.bestAvailableAudioFormat(compatibleWith: [transcriber])
        try await ensureModel(for: transcriber, locale: locale)   // download once, if missing

        let (stream, continuation) = AsyncStream<AnalyzerInput>.makeStream()
        inputBuilder = continuation

        resultsTask = Task {
            do {
                for try await result in transcriber.results {
                    if result.isFinal {
                        committed += result.text
                        volatile = AttributedString()       // clear the guess
                    } else {
                        volatile = result.text              // replace, don't append
                    }
                }
            } catch { /* surface to the UI; a thrown result ends the stream */ }
        }

        try await analyzer?.start(inputSequence: stream)
        try startMic()   // installs the tap, converts buffers, yields AnalyzerInput
    }
}

That is the entire spine of the live dictation I wired into the iOS app I build by myself. Forty-odd lines, no third-party packages, running fully on-device on iOS 26. It took me about a day to write and the better part of a week to stop getting wrong. This post is the week, not the day.

The class is short because SpeechAnalyzer carries the weight. But "short" hid four traps that the WWDC talk and the sample code skate past, and every one of them cost me real hours. I'll walk the spine first, then open up each trap with the code that actually fixed it.

Reading the spine

SpeechTranscriber is the module that turns audio into words. I configure it with reportingOptions: [.volatileResults], which is the single line that makes the experience feel live. Leave it out and you only get finalized text, in chunks, after the recognizer has heard enough context to be confident. With it, you get a stream of fast, throwaway guesses that tighten as more audio arrives.

SpeechAnalyzer(modules:) is the session. You hand it an array of modules; here that is just the one transcriber, though a SpeechDetector for voice-activity can ride alongside it. The analyzer does not produce results itself. Each module owns its own results sequence, which is why my for try await loop reads from transcriber.results and not from the analyzer.

bestAvailableAudioFormat(compatibleWith:) returns the PCM format the model wants to be fed. Hold onto that thought; it is the second trap.

Then AsyncStream<AnalyzerInput>.makeStream() gives me a stream and a continuation. I feed audio in through the continuation; the analyzer reads from the stream. analyzer.start(inputSequence:) begins the session, and startMic() opens the tap that pushes buffers in.

That is the happy path. Here is where I actually spent the week.

Volatile results are a UI problem, not a recognition one

The first time I ran it, the transcript stuttered and doubled. "the the quick the quick brown the quick brown fox." I had reached for the obvious move and appended every result to one string.

The fix is the two-string split at the top of the class. A volatile result is a guess about the same span of audio the recognizer is still chewing on. It is meant to replace the previous guess, not extend it. A final result is the recognizer committing: this span is settled, it will never be revised. So volatile text gets assigned, final text gets appended, and the moment a final arrives I clear the volatile buffer so the same words don't show up twice.

if result.isFinal {
    committed += result.text          // permanent, append
    volatile = AttributedString()     // the guess is now redundant
} else {
    volatile = result.text            // transient, overwrite
}

In the UI I render committed in the normal text color and volatile in gray, and I insert the live text at the cursor so a memo grows in place while I talk. The gray is not decoration. It is a promise to the reader that those words might still change, and it is the difference between an interface that feels honest and one that feels broken when a word flips a half-second after it appeared. result.text is an AttributedString rather than a String precisely so the framework can hang this kind of metadata off the runs, including the audioTimeRange I asked for.

The microphone's format is not the analyzer's format

This is the trap that ate the most hours, because it fails silently. The tap delivers buffers in the input node's hardware format. The analyzer wants the format that bestAvailableAudioFormat handed back. Feed it the wrong one and you don't get an error. You get nothing, or you get garbage, and you sit there wondering whether the model is broken.

The microphone tap has to convert every buffer before it goes in:

private func startMic() throws {
    let input = engine.inputNode
    let micFormat = input.outputFormat(forBus: 0)
    guard let analyzerFormat, let converter = AVAudioConverter(from: micFormat, to: analyzerFormat) else {
        throw TranscriberError.noUsableFormat
    }

    input.installTap(onBus: 0, bufferSize: 4096, format: micFormat) { [weak self] buffer, _ in
        guard let self, let converted = self.convert(buffer, with: converter, to: analyzerFormat) else { return }
        self.inputBuilder?.yield(AnalyzerInput(buffer: converted))
    }

    engine.prepare()
    try engine.start()
}

AnalyzerInput(buffer:) is the envelope the stream carries. The tap closure runs on an audio thread, so I keep it cheap: convert, yield, done. Nothing else belongs in there. I learned that the hard way too, by doing string work in the closure and watching the audio glitch.

"On-device" still means "download once"

On-device is the headline, and it is true: nothing I record leaves the phone, and because there is no metered speech API behind it, a user can talk all day and my server bill stays exactly zero, which for a solo dev with no backend is the entire reason this feature was even thinkable. But "on-device" is not the same as "already on the device." The language model has to be present, and the first time a given locale comes up it may not be.

func ensureModel(for transcriber: SpeechTranscriber, locale: Locale) async throws {
    let wanted = locale.identifier(.bcp47)
    let supported = await SpeechTranscriber.supportedLocales
    guard supported.contains(where: { $0.identifier(.bcp47) == wanted }) else {
        throw TranscriberError.localeUnsupported
    }
    let installed = await SpeechTranscriber.installedLocales
    if installed.contains(where: { $0.identifier(.bcp47) == wanted }) { return }

    if let request = try await AssetInventory.assetInstallationRequest(supporting: [transcriber]) {
        try await request.downloadAndInstall()   // this is the "Preparing…" state the user sees
    }
}

Two checks, not one. supportedLocales answers "can this device ever transcribe this language" — at the time of writing the list runs to forty-some locales, from en_US to ja_JP to yue_CN. installedLocales answers "is the model on disk right now." Only when a locale is supported but not installed do I ask AssetInventory to fetch it, and that download is what surfaces as a "Preparing…" label in the app.

Here is the part I genuinely like as an app author, not just an engineer: those models are shared system assets, not part of my bundle. My download size on the App Store did not move a kilobyte when I shipped this. The model lives in system storage, gets shared across every app that uses it, and updates itself out from under me when Apple improves it. I am used to features that cost binary size or cost cents-per-call. This one costs neither, and that combination is rare enough that I went back and re-read the docs twice to make sure I wasn't missing the catch.

The catch, such as it is, is availability. On a device or OS that can't run it, SpeechTranscriber.isAvailable is false, and the right move is to hide the microphone entirely rather than show a button that does nothing. Typing still works; the voice affordance simply isn't offered. Degrading by hiding beats degrading by erroring.

Two transcribers, and I'm not certain I chose right

There are actually two transcription modules in the framework. I shipped with SpeechTranscriber, which is tuned for clean, lower-overhead recognition. There is also DictationTranscriber, which adds punctuation and leans into conversational structure — the kind of thing you'd want for composing a long message out loud.

Read that back and you can see my doubt. A memo app is arguably closer to "composing a message" than to "command recognition," which is the textbook case for DictationTranscriber. I went with SpeechTranscriber because my memos are short, often fragments, and I'd rather under-punctuate a three-word note than have the model guess sentence boundaries that aren't there. But I hold that choice loosely. It is the first thing I'll A/B if people tell me the transcripts read like a transcript instead of like a note.

What I'd change after shipping it

The bug that survived longest into production was a lifecycle one, and it is worth flagging because it is counterintuitive. Finishing the input stream does not finish the session. Calling continuation.finish() just tells the analyzer no more audio is coming; the analyzer stays alive, holding resources, waiting. To actually wind down you have to call a finish method on the analyzer itself:

func stop() async {
    engine.stop()
    inputBuilder?.finish()
    try? await analyzer?.finalizeAndFinishThroughEndOfInput()  // flush, then close for real
    resultsTask?.cancel()
}

finalizeAndFinishThroughEndOfInput() flushes whatever audio is still in flight into final results before it closes, so you don't lose the last word someone spoke. I had the engine.stop() and the stream finish() from day one and assumed that was teardown. It wasn't, and the leak only showed up after a few dozen start/stop cycles in a long session.

The other thing I'd revisit is backpressure. An AsyncStream will buffer if the analyzer falls behind the microphone, and under sustained fast speech that buffer grows. I haven't been bitten by it yet, but I've made a note to bound the stream and drop the oldest buffers rather than the newest if I ever am, because in dictation the freshest audio is the audio you most need.

The converter I hand-waved

I skipped the body of convert(_:with:to:) above so the mic section would read cleanly. Here it is, since it is the piece most likely to trip you up. It is a one-shot pull through AVAudioConverter:

private func convert(_ buffer: AVAudioPCMBuffer,
                     with converter: AVAudioConverter,
                     to format: AVAudioFormat) -> AVAudioPCMBuffer? {
    let ratio = format.sampleRate / buffer.format.sampleRate
    let capacity = AVAudioFrameCount(Double(buffer.frameLength) * ratio) + 1024
    guard let out = AVAudioPCMBuffer(pcmFormat: format, frameCapacity: capacity) else { return nil }

    var supplied = false
    var conversionError: NSError?
    converter.convert(to: out, error: &conversionError) { _, status in
        if supplied { status.pointee = .noDataNow; return nil }
        supplied = true
        status.pointee = .haveData
        return buffer
    }
    return conversionError == nil ? out : nil
}

The fiddly bit is the input block. AVAudioConverter pulls input rather than taking it, so you hand it the buffer once with .haveData, then answer .noDataNow on the next pull so it doesn't spin asking for more. The + 1024 on the capacity is slack for the resample; size it too tight and the conversion truncates. None of this is exotic, but it is exactly the kind of plumbing the headline API hides, and it is why "wire it to a mic" turned out to be the hard half of the sentence.

If you've shipped SpeechAnalyzer against live audio, I want to compare notes on one thing specifically: did you stay on SpeechTranscriber, or did DictationTranscriber read better for free-form notes? That's the one decision I still can't defend with data.

I'm a solo iOS developer building Simple Memo. I write here every few days about the unglamorous parts of shipping alone, usually when an Apple API surprises me. The voice input this code grew into is documented on its own page.

Further reading: I later expanded these notes into a complete reference with the full SpeechSession, the AudioBufferConverter, and an SFSpeechRecognizer to SpeechAnalyzer migration table: the full SpeechAnalyzer guide.