Something changed at v0.7.0, and I can describe it precisely: I stopped opening Xcode in the morning.
For months, the routine was fixed. Coffee, Xcode, texspark’s source, chase whatever broke yesterday. The book — the entire reason texspark exists — got the leftovers: an evening hour here, a guilty weekend session there. The tool was eating the work it was built for.
Somewhere around v0.7.0, the ratio flipped.
Once the big architecture settled, my days became writing days. But here’s the part I didn’t expect: the writing became the QA department. Hours of real manuscript work put the editor into situations no test plan would have invented — and out came the bugs. Small ones. Strange ones. The kind you only meet at paragraph three hundred: a fold that misbehaves in one specific nesting, a scroll that drifts by a hair after a particular build sequence, an outline entry that’s right in every way except one. Each one small, each one irritating, each one findable only by actually living in the app.
So the rhythm now is: write, hit something odd, note it, keep writing. Fix the batch when it’s worth a detour. The commit log shows it — June was a wall of commits at hours I’m not proud of; July is a steady trickle of small, weird, satisfying fixes. Meanwhile the manuscript’s word count, flat for weeks, has started climbing like it finally got permission.
I won’t pretend texspark is finished. v0.7.0 is not v1.0; the roadmap still has real items on it. But there’s a threshold every tool-building detour eventually meets: the moment the tool recedes into the background and only the work remains — surfacing just often enough to hand you a bug report written in your own manuscript.
Three chapters down, twelve to go. The editor works. Back to the book — which is, it turns out, also the test suite.
Leave a Reply