DEV Community: Simple Memo

How I chose a note format future-me and an LLM can both read

Simple Memo — Tue, 18 Aug 2026 13:14:59 +0000

I am not going to tell you which note format I settled on until the end. I want to show you how I picked it, because the decision is reusable and the answer probably isn't. I have kept notes as a solo developer for about three years, and for most of that time they had exactly one reader: a slightly tired version of me, three weeks later, trying to remember why I changed something. Then the second reader showed up. Now I paste my own notes into Claude and Cursor as context two or three times a week, and the model reads them cold, with no idea what any of my private shorthand meant. The day I started doing that, some of my formats quietly fell apart.

So I did the boring thing and ran an actual decision instead of drifting into a habit. Here is the whole thing, axes and weights and rejected options included.

Two constraints, ranked before I looked at any format:

Capture friction comes first. A format I won't use at the end of a bad day is worth nothing, no matter how elegant it reads.
Machine-legibility comes second. The notes have to survive being pasted into a model with zero cleanup, or the second reader gets nothing.

The five formats I actually weighed

Freeform prose. Just write paragraphs. Lowest possible friction going in: you type what you think. The cost shows up later. Future-me can't skim a wall of prose, and a model handed three months of undated paragraphs struggles to tell where one thought ends and the next begins. It reads everything as one blurry context.

Per-note structured metadata. Every note gets a small header: a title field, tags, a type, a date, maybe a status. This is lovely to query and genuinely nice for a machine, which likes named fields. But the friction is brutal at exactly the wrong moment. To write one line about a bug, I first have to decide its title and its type and its tags. Most nights I just wouldn't, and an unwritten note beats a well-formatted one zero times out of a hundred.

Full Zettelkasten. Atomic notes, stable IDs, dense links between them. In theory the richest structure of the five, and the only one that builds a real graph. In practice it asks me to do link-maintenance forever, and I already ran this experiment and quit it. I hand-kept around 1,400 Luhmann-style IDs for three years and then deleted every one of them, and my notes got better, not worse. That result is still fresh, so Zettelkasten started this round with a scar.

Timestamped one-liners. Plain text, one thought per line, each line beginning with a date and a concrete noun or verb. 2026-03-14 fixed cold-start regression: moved the keychain read off the launch path. No header, no fields, no links. It looks almost too simple to count as a system.

Question-and-answer notes. Each note is a question with an answer underneath, like a private FAQ. Wonderful for the notes that are genuinely questions. Terrible ceremony for the eighty percent that are just an observation I want to park before it evaporates.

Which axes actually decide it?

I scored the five on the five things I care about. Low, medium, high — where for maintenance cost, low is good.

Format	Capture friction	Machine-legibility	Future-me skimming	Graph / link value	Maintenance cost
Freeform prose	Low	Low	Low	Low	Low
Structured metadata	High	High	Medium	Medium	Medium
Zettelkasten	High	Medium	Medium	High	High
Timestamped one-liners	Low	High	High	Low	Low
Question-and-answer	Medium	High	Medium	Low	Medium

The table alone doesn't pick a winner, because the columns are not worth the same. A format that scores high on graph value and high on friction is not a tie against one that scores low on both — it depends entirely on how much I weight friction. Which is the actual decision.

How I weighted the axes

I gave capture friction more weight than everything else combined. This is not a principled information-theory stance. It is a fact about me: I am one person, I capture at the worst moments, and any friction at capture time doesn't make my notes tidier, it makes them not exist. So friction dominates.

Machine-legibility came second and it is the axis that changed since last year. A note is now something a model reads, and models turn out to have a clear preference that surprised me: they do not need my metadata nearly as much as they need my ordering and my verbs. A timestamp gives a model sequence for free. A leading verb gives it the topic of the line without a tags field. Plain dated lines read to a model almost like a commit log, and models are very good at commit logs.

Future-me skimming came third, maintenance cost fourth as a penalty, and graph value came dead last. That last one is the deliberate, uncomfortable trade I want to name out loud: I am choosing a format that will never build me a navigable web of linked ideas. I am giving up the graph on purpose. I decided I almost never actually traverse a knowledge graph; what I actually do is search for a line and read the twenty lines around it. So I optimized for the thing I do, not the thing I once imagined I'd do.

A concrete example of the weighting doing real work. Structured metadata scored high on machine-legibility and I was tempted, because a model does love a clean type: bug, tags: [ios, launch] header. But run it through the weights and it collapses: the header buys a little legibility I mostly already get from the verb, and it costs friction on the one axis I refuse to spend on. A format can be objectively richer and still lose, because the axis it wins is the axis I priced cheap and the axis it loses is the one I priced above everything. Writing the weights down first is what stopped me from being seduced by the format that demos best.

Does the machine really change the answer?

It is worth being honest about how much the second reader actually moved the decision, because it would be easy to overstate it. Three years ago, with only future-me reading, I would probably have landed on timestamped lines anyway — skimmability and low friction were already pulling that way. What the model added was a second, independent vote for the same format, and it retired one candidate I might otherwise have kept flirting with. I used to assume that the day notes became machine-input, I'd need more structure, not less. The opposite happened. The model reads my least-structured format the most comfortably, because plain dated lines look like exactly the kind of sequential, terse log that these systems were trained on oceans of. The machine didn't ask me to build it a schema. It asked me to stop building one.

What I actually picked

Timestamped one-liners. Plain text, one thought per line, each line led by a date and a concrete noun or verb, no per-note structure at all. The lines accumulate in a folder of dated markdown files, and that folder is the whole system. There is no schema to remember and nothing to maintain.

It won capture friction outright, which was most of the weight, because writing a note is just typing a line. It won machine-legibility for a reason I didn't predict before I tested it: when I paste a month of these lines into a model, I paste them raw, no cleanup, and the model handles them better than it handled my old structured notes, because the timestamps give it order and the leading verbs give it topics. It won future-me skimming because a column of dated first-words is the most skimmable thing I've ever kept. It lost graph value completely, and I let it, because that was the trade I'd already decided to make.

Why did the other four lose?

Structured metadata lost on the only axis I refused to compromise: it taxes the moment of capture, and taxed capture is skipped capture. Zettelkasten lost because I had already paid its maintenance cost for three years and written about deleting every one of those IDs; choosing it again would have meant un-learning my own result. Question-and-answer lost because it's a great format wearing the wrong uniform for daily use — I kept it, but only as a thing I reach for deliberately, not as the default. Freeform prose lost on both readers at once: unskimmable for me, unsegmentable for the model.

None of these are bad formats. They lost against my specific weights. Someone who traverses a real graph every day, or who queries structured fields constantly, should weight the axes differently and would correctly pick something else. That's the point of showing the weights instead of just the answer.

The checks I'll run in three months

A decision journal is worthless if you never check it, so here is how I'll know I chose wrong. Did I stop capturing? If the friction of even a dated line turns out to be too much on bad days, the format failed at its one job. Did a paste into a model need cleanup? If I find myself reformatting notes before they're useful as context, machine-legibility wasn't as high as I scored it. And did I ever badly want a link I didn't have? If I keep reaching for a connection between two lines and the flat format can't give it to me, then I underweighted graph value and I owe myself a rematch.

A few questions I had to answer first

Won't a model prefer clean structured data over plain lines? I assumed yes and was wrong in practice. For long-context pasting, ordering and short topical verbs did more work than named fields, and they cost me nothing to produce. A model reading dated lines reconstructs the structure it needs; it does not need me to pre-chew it.

Isn't plain text going to rot without a system? It would if it had no anchor. The timestamp is the system. Every line is findable by date and by its first word, which is all the retrieval I've ever actually performed on my own notes.

What about tags? I don't add them at capture time, because that's the friction I'm avoiding. When I need a category, I search for the verb. The leading word is a tag that costs nothing to write.

If you keep notes for both a human and a machine now, I'd like to know: what is the one piece of structure you add at capture time that has actually paid off later when you fed the notes to a model — and what did you add once, feel clever about, and end up ripping out?

I build a small iOS app by myself, and most of it is an argument that the moment of capture should cost almost nothing. I write here every few days about the parts of doing that alone that I'm still getting wrong. If you're curious where these dated lines eventually land, it's here.

I hate marketing. Here are six things I did anyway.

Simple Memo — Fri, 14 Aug 2026 13:09:00 +0000

Six short pieces from my notebook this month, all about marketing. I have shipped a small iOS app by myself for about fourteen months, and marketing is still the job I schedule last and finish worst. These are not tactics. They are the notes I wrote to myself after each attempt, so that next-me would stop making the same face at the word.

The word is the problem, not the work

I kept freezing on the task called "marketing." So I renamed it. Now my calendar says "tell one honest person one true thing," and I do it without the dread.

The rename mattered more than any tactic. "Marketing" carries a picture: a funnel, a growth curve, someone louder than me winning. "Tell one person one true thing" carries a different picture, which is just a message I already know how to write. Same activity, on most days. The difference is that one of the two framings makes me open the laptop.

I think the aversion a lot of builders feel is not to the act but to the costume. We imagine we have to become a person who says "growth hack" without wincing. We don't. The work underneath is closer to writing a good commit message: say what changed, say why it matters, keep it short. I can do that. I could never do the costume.

What counts as marketing when you hate the word?

For a week I logged everything that touched a stranger's awareness of the app, and then sorted it by whether it felt like "marketing" or not. The results embarrassed me.

Answering a question in a forum, honestly, without linking anything: felt like being a person, counted as marketing. Fixing a confusing sentence in the App Store description: felt like editing, counted as marketing. Writing a plain post about a bug I caused: felt like confession, was probably my best marketing all month. Meanwhile the thing that felt the most like Marketing, a scheduled promotional post, did approximately nothing.

The lesson I wrote down: the parts that work rarely feel like marketing, and the parts that feel like marketing rarely work. If a task makes me feel like a salesperson, that is weak evidence it is worth doing. If a task just makes me feel useful to one specific human, that is where the signal has been.

The launch is a coin, the habit is a wage

I have launched loudly and I have shown up quietly, and I finally sat down to compare what each actually returns.

	The loud launch	The quiet habit
Effort shape	One big spike, then nothing	Small, daily, boring
Time to feedback	Same day, then silence	Slow, then compounding
Who it reaches	People who like launches	People who have the problem
How it feels	Exposed	Almost invisible
What it leaves behind	A spike in a chart	A searchable trail

The loud launch is a coin flip: sometimes it lands, mostly it doesn't, and either way you learn little because the crowd that shows up for launches is not the crowd that keeps a tool. The quiet habit is a wage. It pays badly per hour and reliably over months, because each honest post or answer sits there and keeps getting found. I have stopped hoping for the coin. I show up for the wage.

Say the boring true thing before the clever one

My best-performing sentence this year was not clever. It was: "It sends the note as an email and there is nowhere to file it." That is the whole product, stated flatly.

I spent months trying to find a clever line, an angle, a hook that made a note-to-email app sound like a movement. Every clever line I wrote made the thing sound like more than it is, and people who arrived on a clever line left disappointed by the honest reality. The boring true sentence did the opposite. It set an expectation the app could actually meet, so the few people it drew in stayed.

I think clever marketing is a tax you pay later, in refunds and churn and one-star reviews that all say "not what I expected." Boring-and-true is the cheaper long game. Describe the thing so plainly that the only people who come are the ones it will actually fit.

Does talking about the work count as marketing?

I was not sure, so I ran a small test: for a month I wrote publicly about the mechanics of building alone, with no pitch attached, and I watched what happened to the app I never mentioned by name.

What happened was quiet and real. A handful of people found the app by following the trail of posts back to the person who wrote them. Nobody bought because of a call to action, because there wasn't one. They bought because they had read enough of my thinking to trust that the tool was built by someone who thought about the problem the way they did. I wrote more about that trade-off in an earlier note on what building solo takes from you.

So yes, talking about the work is marketing, and it is the kind I can sustain, because it does not require me to sell. It only requires me to be useful in public and let people draw their own line back to what I make.

The part I still get wrong

I under-market, and I know it, and knowing it has not fixed it. I will build a feature for three weeks and mention it once, quietly, on a Tuesday, and then feel obscurely virtuous about not being pushy.

That is not humility. It is a comfortable way to avoid the discomfort of repetition. The honest truth is that most people who would like the thing have not heard of it, will not hear of it once, and will not remember it the first time even if they do. Marketing that hates repeating itself is just a hobby that produces posts. I am trying to say the same true things more than once without feeling like a fraud, and I am not there yet. If you have made peace with repeating yourself, I would like to know how.

A few questions I had to answer for myself

Do I need a big audience for any of this to work? No. Every good outcome I traced this month came from one person reading one thing, not from reach. A small trail that the right person can follow beat a big spike every time.

Isn't "just be honest" naive advice? It would be if honest were easy. It is not. Saying the plain, unflattering truth about a small product takes more nerve than saying something clever, which is exactly why so little marketing does it.

What would I do first if I were starting over? Write the one boring true sentence that describes the product, put it everywhere, and stop reaching for the clever version. Then answer questions in public until people know my face.

I will keep writing these next month. There is a seventh piece already forming, about the difference between being visible and being findable, but it is not done thinking yet.

I'm a solo developer, and Simple Memo is the little iOS thing I make and, it turns out, have to market: one tap turns a thought into an email you have already sent. I write here every few days about the awkward parts of doing every job alone. It lives here.

The worst time to organize a note is the moment you take it

Simple Memo — Tue, 11 Aug 2026 13:29:33 +0000

I watched myself do it again last Tuesday. I caught a fix worth remembering, opened a note, and then spent the next ninety seconds deciding which folder it belonged in, what to tag it, and whether it was really a "task" or a "reference." Having the thought took about one second. Filing it took ninety. By the time I was done, the fix I had actually wanted to write down had gone soft at the edges, and I was no longer sure I had it right.

That ninety seconds is the thing I want to argue about. Not because it is long, but because of when it lands: at the exact instant I can least afford it.

Here is the claim, and I will spend the rest of the post earning it. Capture and curation are two different jobs with opposite requirements, and almost every note tool I have used quietly asks me to run both at once. That is the mistake. Do them together and you get the worst of each: capture slow enough that thoughts slip away, and curation done in a one-second window with none of the context that makes it worth doing.

What the tools actually ask of you

Open most capture flows and count the decisions before the thought is safe. Pick a notebook. Choose a project. Add tags. Set a type. Maybe a due date. Each of those is defensible on its own. Together they turn "write this down" into a small triage meeting, and they schedule that meeting for the one moment you are guaranteed to be busy: mid-thought, mid-task, mid-something.

The thing the apps get wrong is that they treat the tags and the folders as free, as if slotting a note into structure were part of writing it. It is not. It is a second, heavier job wearing the first job's clothes. And it is a job you are catastrophically bad at right now, because you are holding a thought in working memory and every keystroke spent on metadata is a keystroke not spent holding it.

I have measured the cost of interruptions like this on myself before, and it is not linear. A fifteen-second interruption that cost me forty minutes of re-entry taught me that the price of a context switch is not the switch, it is the climb back. Organizing at capture time is a context switch you volunteer for, on purpose, every single time you have an idea.

Why does doing both at once cost double?

Because you are running curation blind.

Curation is the act of deciding where a thought belongs and what it connects to. That decision is only good when you have information: what else is in the vault, what this relates to, whether it is still true next week. At capture time you have exactly none of that. You are deciding a note's permanent address at the one moment you know the least about it. So you either guess, and build a structure full of confident wrong guesses, or you stall for ninety seconds trying to guess well, and lose the thought you came to save.

There is a reason a thought you cannot capture in about a second is already gone. The window is that short. Anything you bolt onto the front of capture is spending a budget that was never yours to spend.

So the tax is double. You pay it once in lost thoughts, because capture got slow. You pay it again in a junk taxonomy, because curation got done at the worst possible time by the least informed version of you.

The split I actually run

Two jobs, two modes, and I keep them physically apart so I cannot cheat.

	Capture	Curation
When	The instant a thought lands	Once a week, deliberately
Where	Phone, wherever I am	Laptop, at a desk
Time budget	About one second	Ten to fifteen quiet minutes
Mindset	Dumb, fast, no judgment	Slow, full of judgment
Allowed actions	One line, append it, done	Read, connect, rename, discard
What kills it	Any decision at all	Skipping it for a month

Capture is append-only. One line, one action, timestamped by the world instead of by me, no folder, no tag, no type. The whole point of the tool I build for myself is that it opens in about a quarter of a second and turns a line into a saved, sent record before I have finished the thought. There is no place to put a tag because I removed the place to put a tag. That absence is a feature.

Curation is a separate act I do later, on a different device, on purpose. Once a week I sit down at the laptop, read the week's raw lines in a plain markdown vault, and decide what graduates: what becomes its own note, what links to what, what was noise and gets deleted without ceremony. Now I have context. Now the judgment is worth something, because I am reading a thought next to the six thoughts that arrived after it.

The device split does real work. If capture and curation lived in the same app on the same screen, I would drift into tidying at capture time out of sheer proximity. Making curation happen somewhere else raises the friction just enough that I stop trying to do it in the checkout line.

Where this breaks, and who should ignore me

I owe you the cases where I am wrong, because a rant that only flatters its own thesis is just a mood.

Dumb capture wins for a solo dev with a curation habit. It stops winning the moment your inbox is shared. If an untriaged item blocks a teammate, then "I'll sort it Sunday" is not discipline, it is a dropped handoff, and some structure at capture time is the price of not being the bottleneck. Team queues and personal inboxes are different animals, and I am only defending the personal one.

It also breaks if you never actually curate. An append-only inbox you never revisit is not a system, it is a landfill with timestamps. The whole split is load-bearing on the back half. If you know yourself well enough to know the Sunday pass will not happen, then a little structure at capture time is a hedge against your own neglect, and that is a fair trade. I am not making it, but I see it.

And there is a volume line somewhere. Capture a handful of lines a day and an unstructured inbox stays scannable. Capture two hundred and it does not, and you will want some coarse bucket at the door just to keep the Sunday pass finishable. I have not hit that line as a team of one. If you have, your mileage is honestly different, not wrongly different.

A couple of questions I get

Isn't a dumb inbox just inbox-zero with extra steps? No, and the difference is the timestamp. Inbox-zero is a pressure to clear. The dated line has no pressure at all, because nothing is overdue and nothing is unfiled, it is just a log. I am not racing a counter to zero. I am reading a week.

What if the one-second capture saves garbage? It saves some, and I delete it on Sunday in about the time it would have taken to tag it on Tuesday. The asymmetry is the point: deletion is cheap and late and well-informed; tagging is expensive and early and blind. I would rather throw out ten cheap lines than misfile one expensive one.

The one line I want from you

I am curious where other people draw the exact border, because I suspect mine is slightly wrong and I cannot see which side.

So, concretely: what is the one thing you let yourself do to a note at the moment you capture it, and what is the one thing you had to forbid yourself from doing because it kept eating the thought? A single allowed move and a single banned one. I want to see where the line lands for work that isn't mine.

Simple Memo is an iOS app I build by myself: type one line and it is a sent email before your thumb leaves the screen, with nowhere to file it and nothing to tag. I post here every few days about the mechanics of doing this solo. You can find it on the App Store.

The iOS sandbox turns 18: the ways out, oldest first

Simple Memo — Tue, 04 Aug 2026 13:31:24 +0000

2008: the App Store opens, and every app you install is handed a sealed container it cannot reach out of. Eighteen years later, I still spend real time choosing the right sanctioned way to move one line of text between two iOS apps. This is that history, told oldest method first, by someone who has shipped most of it.

I build a small iOS app on my own, and its entire job is to get a thought you just typed out of itself and somewhere useful before you lose it. That makes "getting data out of the sandbox" less an abstraction for me than the whole product. So I have opinions about every door Apple has cut into that wall, and I know roughly when each one appeared.

TL;DR

iOS has never let two apps share a filesystem. Every method below is a specific, Apple-sanctioned door punched through the sandbox wall, added one at a time.
The doors moved in one clear direction over eighteen years: from invisible and automatic toward explicit and user-consented.
Real file-level sharing did not exist until 2014. Everything before iOS 8 moved strings, not files.
In 2026 I ship exactly two of these mechanisms, and they solve opposite problems.

Why was moving data ever hard?

On a desktop, "share data between two programs" is barely a sentence. Any process can read a file in your Documents folder, so the shared filesystem is the integration. iOS threw that assumption out on day one. Each app lives in its own container directory, walled off from every other app's storage, with no ambient shared folder and nothing resembling a common drive. The default is isolation, and it is a security feature, not an oversight.

So on iOS, "share data" has never been one thing. It has always been a narrower question: which specific, blessed bridge do I use to move this particular payload from my container into somewhere another app or the user can reach? The rest of this piece is those bridges, in the order Apple shipped them, and what each one was actually good for.

2009: strings escape first

Three ways out landed close together in iOS 3.0, and all three moved text, not files.

The first was the clipboard. UIPasteboard gave every app read and write access to a shared pasteboard, so a user could copy in app A and paste in app B. It was the crudest possible transfer and also the most universal, and for years it was completely silent: an app could read whatever you last copied without you knowing. Hold that thought, because it comes back to bite the whole model in 2020.

The second was custom URL schemes. An app registered something like myapp://, and any other app could hand it a small payload by opening that URL. It worked, and it was fragile in every direction. Any app could claim any scheme, so there was no ownership and no trust, and you could only pass what fit in a URL. It was duct tape, but it was the first way one app could deliberately poke another.

The third was email, through MFMailComposeViewController in the MessageUI framework. On the surface it is just a mail compose sheet you present inside your app. Underneath it is the strangest and most durable bridge on this list, because it is the only one that does not require the destination app to exist on the device at all. The data leaves the device entirely, lands on a server, and sits in a format that will still open in forty years. I will come back to why that turns out to matter more than it looks.

2010 to 2012: files start to move

iOS 3.2 (2010) gave us UIDocumentInteractionController, better known as the "Open in..." menu. For the first time you could hand a whole file to another app, matched by its type, and let the user pick a target that had registered for it. It was one-way, always user-initiated, and it copied the file into the other app's container rather than sharing it. But it was the first time the unit of transfer was a document instead of a string.

iOS 5.0 (2011) added something quieter that mattered enormously later: NSFileCoordinator and NSFilePresenter, which arrived alongside iCloud document storage. Their whole reason to exist is the idea that two processes might touch the same file, and that they need to take turns so nobody reads a half-written mess. Nobody demoed this at a keynote. It became load-bearing three years later.

iOS 6.0 (2012) standardized the mess of "Open in..." into UIActivityViewController, the share sheet. Instead of every app inventing its own export menu, there was now one system menu, and apps registered activities into it. It was still one payload at a time and still something the user had to start, but it turned a scattered set of one-off handoffs into a single, discoverable gesture that every iOS user now knows by heart.

2014: the year the sandbox grew real doors

If this history has a hinge, it is iOS 8. Three things shipped together that finally made file-level sharing real.

App Extensions let your code run inside another app's context: Share extensions, Action extensions, the Today widget, Document Provider extensions, and custom keyboards. Your app was no longer confined to its own window. App Groups gave your own apps and their extensions a genuinely shared container directory, the first sanctioned place two pieces of your own software could read and write the same files. Apple's own guidance came with a warning attached: when you write to that shared container, you must do it "in a coordinated manner to avoid data corruption." That is exactly why the sleepy 2011 file-coordination API suddenly showed up in everyone's code.

The third piece was iCloud Drive together with UIDocumentPickerViewController and security-scoped bookmarks. For the first time, an app could, with the user's explicit grant, reach into a folder living in another app's iCloud space and write there, then persist that permission across launches with a bookmark. This is the birth of the modern "append a line into another app's folder" path. I took that exact write path apart layer by layer in a separate teardown; here the point is smaller. Before 2014 it was not possible, and after 2014 it was the sanctioned way.

2015 to 2017: links grow up, files become visible

iOS 9 (2015) fixed the original sin of custom URL schemes with Universal Links: verified https links that open your app if it is installed and fall back to your website if it is not. Because the link is a real web address you have proven you own, another app can no longer quietly claim it. The 2009 duct tape finally grew an identity.

iOS 11 (2017) made the filesystem itself visible. The Files app and UIDocumentBrowserViewController gave users a place to see and navigate documents across apps and cloud providers, and the document picker got simpler to adopt. The sandbox was still standing, but now there was a shared, user-facing surface, folders, that several apps could point at and a person could actually reason about.

2020 to 2022: the tide turns toward consent

Then the direction reversed. iOS 14 (2020) made reading the pasteboard raise a banner, so the oldest and most invisible bridge on this list became the most conspicuous one. Apps that had been quietly sniffing the clipboard for years got caught on camera overnight.

iOS 16 (2022) went further with an explicit "allow paste" prompt and UIPasteControl, so an app reading the pasteboard without clear user intent now needs permission, and 16.1 added a per-app paste setting. For a decade Apple had spent its energy adding ways to move data. Now it was spending energy adding friction to the ones that moved data without you noticing. The wall was not getting shorter. The gates were getting louder.

Here is the whole eighteen years on one screen:

Year (iOS)	Mechanism	What it moves	Who starts it	First-class in 2026?
2009 (3.0)	UIPasteboard	A string or blob	User copies	Yes, but policed
2009 (3.0)	Custom URL schemes	A small URL payload	Either app	Superseded by Universal Links
2009 (3.0)	MFMailComposeViewController	A whole message, off device	User confirms send	Yes
2010 (3.2)	UIDocumentInteractionController	One file, by type	User picks "Open in"	Mostly folded into the share sheet
2011 (5.0)	NSFileCoordinator	Safe access to a shared file	Your code	Yes, under the hood
2012 (6.0)	UIActivityViewController	One payload, anywhere	User opens share sheet	Yes
2014 (8.0)	App Groups container	Files, between your own apps	Your code	Yes
2014 (8.0)	iCloud Drive + document picker	Into a user-chosen folder	User grants, code writes	Yes
2015 (9.0)	Universal Links	An https route into your app	Either app	Yes
2017 (11.0)	Files app + document browser	Files, user-visible	User	Yes
2020–22 (14–16)	Pasteboard consent, UIPasteControl	Gatekeeping, not transport	User consents	Yes

So which of these do I still reach for?

Two of them, and they solve opposite problems.

The first is email, through MFMailComposeViewController, the bridge from 2009. I keep coming back to it because it is the only mechanism on the whole list that does not care whether the other app exists. The line leaves the device, lands in an inbox the user already checks every day, and sits there in a format nothing can deprecate. I wrap the send in a small offline queue so a failed attempt retries instead of evaporating, which is a whole design problem of its own that I wrote up as an offline-first outbox.

The second is the iCloud Drive document-picker path from 2014, for the case where the destination is a folder the user already owns on their own device. My app uses it to append a dated line to a Markdown vault, which is the one place Obsidian users tend to notice it, and the coordinated write is the only thing standing between "your note got appended" and "your file got corrupted."

Notice what the two survivors have in common. In both, the destination is the user's own storage or account, an inbox and a folder they control, not another app's private container. The bridges that tried to reach directly into someone else's sandbox are the ones I have quietly stopped using.

A few questions I get

Isn't email a strange way to move data between apps in 2026? It looks quaint right up until you notice it is the only mechanism here that works when the target app is not installed, works offline if you queue it, and leaves behind an artifact that will still open decades from now. Quaint and durable are not opposites.

Why not just use the clipboard for everything? Because after iOS 14 the clipboard is the most watched channel on the system. It is genuinely good for a user-initiated copy and genuinely wrong for anything your app does on its own. Treat the privacy banner as a design constraint you were handed, not a bug to route around.

Where do App Intents and Shortcuts fit? They are the newest door, and I left them off the timeline on purpose, because they move actions rather than just data and they deserve their own history. But they are plainly where the direction of travel points: user-authored automation over routes hard-wired by an app developer.

Where does this history go next?

The eighteen-year arc has one shape. Every generation of cross-app data movement added either user visibility or user consent to the generation before it. The invisible clipboard gave way to a discoverable share sheet, which gave way to an explicit document picker, which gave way to an outright paste prompt. Nothing on this list got easier to do silently. Almost everything got easier to do honestly.

If that trend holds, the next chapter is not another file API. It is intent, App Intents and Shortcuts and on-device models, working out where a piece of data should go and asking you to confirm, instead of an app quietly hard-wiring the route years in advance.

Which leaves me with a real question rather than a rhetorical one. What is the oldest cross-app mechanism you still ship in production, a custom URL scheme, an "Open in" handler, a raw pasteboard read, and what finally made you replace it, or decide that you never would? I am trying to sort out which of my own two survivors are principled choices and which are just habit wearing a nice coat, and your holdouts would help me tell the difference.

I'm the solo developer behind Simple Memo, an iOS app that turns a line you type into an email about a second later, and on the days I curate, appends that same line to a Markdown vault on iCloud. I write here about the unglamorous parts of building it alone. The vault side of that is documented at simplememofast.com/obsidian/.

Driving vs. delegating: I timed two ways of pairing with AI

Simple Memo — Fri, 31 Jul 2026 13:33:09 +0000

There are two ways I pair with an AI coding assistant, and for most of a year I could only have told you which one felt faster, not which one was. One afternoon in June I let an agent rewrite a 300-line module in about a minute, then spent the next two hours cleaning up after it. The size of that gap, and the fact that I had been ignoring it, is the whole reason I sat down to write this.

By driving I mean keeping my hands on the code. I write most of it, and the model works at the scale of a line or a function: a completion here, a "what's the signature for this API" there, a second read on something I already wrote. By delegating I mean the opposite posture. I describe a whole task, hand it off, walk away, and come back to review a diff I did not write. Same assistant, same me, same afternoon. Two completely different relationships to the code that comes out the other end.

TL;DR

Delegating a whole task to an agent is front-loaded speed and back-loaded cost. The diff lands in seconds, but the work just moves downstream into review, and review is exactly where the model's wrong assumptions hide. Driving is the reverse: slow to type, cheap to trust.
The axis that actually decides which one is faster is not task size. It is verifiability. I delegate when I can check the result faster than I could have written it, and I drive when checking is as expensive as authoring. The rest of this is me arriving at that one sentence the slow way.

What does "faster" even mean here?

The reason I could not answer the speed question for a year is that I was conflating two different clocks.

There is the clock that runs while the code appears. By that clock, delegating wins every time and it isn't close. I type three sentences of intent, and forty seconds later a diff touches six files. Driving cannot compete with that, and my nervous system knows it: a big diff scrolling past feels like progress in a way that writing one careful function never does.

Then there is the clock that runs until the code is actually correct and I trust it. That clock includes reading the diff, catching what the model quietly assumed, discovering the integration bug three days later, and re-explaining the constraint it ignored the first time. On that clock the ranking often flips, and the flip is invisible in the moment because the two clocks report at different times. Delegating bills you now and charges you later. I had been reading only the first invoice.

So the honest version of "which is faster" is a question about the second clock, and the second clock is dominated by one thing: how long it takes me to verify the output.

The two postures, side by side

Here is the comparison after tracking it deliberately across a few dozen tasks this spring, in a solo iOS codebase with no team to absorb the review load:

	Driving	Delegating
My role	Author, model assists	Reviewer, agent authors
Feels fast?	No	Yes, dangerously so
Where the time goes	Typing, up front	Review and rework, after
Mental model of the code	I hold it the whole time	I have to reconstruct it
Best at	Tasks where checking is as hard as writing	Tasks I can verify at a glance
Worst failure	I'm slow on work a model could have done	A wrong assumption ships past a shallow review
Cost visibility	Obvious and immediate	Hidden and deferred

The row I care about most is the last one. Driving fails loudly: I feel every slow minute, so I never over-trust it. Delegating fails quietly, and quiet failures are the expensive kind.

Where delegating clearly wins

When the task is cheap to verify, delegating is not just faster, it is obviously the right call, and I have stopped feeling clever about driving through work like this.

A new isolated SwiftUI settings screen is the clean example. The correctness is visible: I run it, I look at it, I tab through the fields. If the agent got the layout wrong I see it in five seconds, and the cost of being wrong is a re-render, not a corrupted file. Scaffolding a parser with a table of example inputs and expected outputs is another, because the examples are the check. So is a mechanical refactor, renaming a concept across forty call sites, where the compiler is a far better reviewer than I am and the agent is faster at the typing than I will ever be.

The pattern under all three is the same. The output carries its own test. I can look at the result and know it is right faster than I could have produced it, so handing off the production is pure profit. This is most of the surface area of a normal codebase, and pretending otherwise, insisting on writing every line by hand, is just craft nostalgia with a time cost.

Where driving quietly wins

Then there is the other kind of task, where the code is not the expensive part.

The expensive part is noticing the one wrong assumption, and you only notice it if you were already holding the whole model in your head. My Outbox is the case that taught me this. It is a small offline-first queue that retries failed sends, and I have written before about how carefully it has to behave when the network flaps and the app is backgrounded mid-flush. When I delegated a change to its retry path, the agent produced clean, plausible, well-named code that added jitter to the backoff exactly as I asked. It also, without mentioning it, moved a state write outside the lock that was the only thing keeping two retries from waking on the same tick.

That is not a bug you catch by reading a diff for style. You catch it by having spent a week inside the concurrency model months ago and feeling the wrongness before you can even articulate it. Reviewing that diff cost me more attention than writing the change would have, because to review it properly I had to rebuild the exact mental model that driving would have kept warm the entire time. The same held for the code that appends a line to another app's iCloud folder, where a subtle mistake in the coordinated-write path is silent until someone's note goes missing.

For that class of work, delegating does not save time. It just relocates the hard part from a place where I am strong, authoring with the model in my head, to a place where I am weak, spotting a buried assumption in someone else's plausible code.

So what is the actual rule?

For a long time I thought the axis was task size: small things by hand, big things to the agent. That is exactly backwards, and it cost me to learn it.

The real axis is verification cost. Delegate when you can check the result faster than you could write it. Drive when checking is as hard as writing. Task size barely matters; a 300-line SwiftUI view can be cheaper to verify than a nine-line change to a lock. What I am really doing when I choose a posture is comparing two numbers I can now feel without measuring: the cost to produce, and the cost to check. When check is much less than produce, I hand it off and don't look back. When check approaches produce, I keep my hands on the wheel, because the model's speed is buying me nothing I can safely accept.

This is also why the fashionable framing, "just get better at prompting and you can delegate everything," misses the point. The bottleneck was never how well I could specify the task. I can specify the Outbox change down to the last detail, and the review is still the expensive part, because an airtight spec does not make a subtle violation of it cheap to detect. The limit is verification, not instruction. It is the same reason I keep context, not prompts, at the center of how I work with a model: the leverage is in what the model and I can hold in common, not in the wording of the ask.

The trap I keep falling into

Knowing the rule does not make me immune to it, and I want to be honest about that rather than end on a tidy law.

The pull toward delegating is not really about speed. It is that a large diff feels like accomplishment, and driving feels like labor, and on a tired afternoon I will reach for the thing that feels like accomplishment even when the task is one I should be holding myself. I have shipped a quiet bug this way more than once, each time on a day when I let the good feeling of a fast diff stand in for the boring question of whether I could actually check it. The tell, when I catch it in time, is that I am about to approve a diff I could not have written, in a part of the system where being wrong is expensive. That specific combination is my signal to stop, close the diff, and drive.

So the two-way choice has become a one-question habit. Before I accept a handoff I ask whether I can verify this more cheaply than I could have built it. If yes, the agent keeps the work. If I hesitate, the hesitation is the answer, and I take the wheel back.

A few questions I keep getting

Isn't this just "use AI for boilerplate"? Close, but boilerplate is a proxy, and a leaky one. Some boilerplate is expensive to verify, such as security-sensitive glue, and some novel code is trivial to verify, like a pure function with obvious outputs. Verification cost is the real variable; "boilerplate" is just the case where it is usually low.

Doesn't delegating more make you worse at the hard parts over time? It is my honest worry. My hedge is that the hard parts, the ones where checking is as costly as writing, are exactly the ones the rule tells me to keep driving. If the rule holds, I stay sharp precisely where sharpness is load-bearing and offload only where it isn't.

Where does an agent's autonomy fit? Same axis, higher stakes. The more autonomously it runs, the more code accrues before I review, and the more verification debt piles up if I can't check it cheaply. Long autonomous runs are wonderful for verifiable work and quietly dangerous for the other kind, for exactly the reasons above.

The open question I actually want answered

Here is the thing I am still missing, and it is specific. When you delegate a real task to an agent, what is the single check you run before you trust the diff? Not "I read it carefully," but the concrete move: the test you write first, the invariant you assert, the one file you always open, the question you ask the model about its own output. My whole approach now rests on making verification cheap, and I am fairly sure the people who delegate well have a verification move I haven't stolen yet. I would rather learn yours than defend mine.

Simple Memo is the one-person iOS app I make: type a line and it lands in your email a second or so later, so the thought is caught before it evaporates. I post here every few days about what shipping solo keeps teaching me, this piece included. What I'm building lives at simplememofast.com.

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.