I implemented a pretty simple iOS/macOS text editor using TextKit 2, and it was astonishing how many hacks, workarounds and manual implementations were needed to support even the most basic features.
That codebase is the polar opposite of a finely crafted pen, and the ugliness all comes from the API.
That is exactly it. You know what an engineer you are making a system as complex as that? I don't know your codebase but I'm quite aware of TextKit and I can see what a hard and consuming job you must have done. I wish I could see your editor too.
Thanks—I might return to it and open source it soon… It was a pre-Claude Code project, and it was hard to feel any momentum. It's basically a note-taking tool for capturing quick one-off notes in Markdown, but it stores a lot of surrounding metadata (location, any current calendar events, device type, etc) in the YAML front matter. It feels like it would be even more relevant in this era, but there's a lot of work to do on the UI.
I actually built a fully featured text editor with Codex last month for a GUI toolkit I was building from the scratch. It worked quite well. You should give it a try. Perhaps you can offload much of the refinements to the llms now
I am surprised- I reimplemented Notepad for Windows CE and it was pretty much a wrapper around a standard Windows control. It was just a couple of pages of MFC code I believe.
It probably depends on what you're trying to do; I needed Markdown styling and Markdown-aware behaviors (e.g. when you hit return after a list item, indent the same amount and add a new list marker), context-aware nesting (hit Command-[/] to indent/outdent), hotkeys for heading levels, and so on. Between keeping the attributed text styles correct, properly grabbing the right text ranges to operate on, and doing it all in undoable transactions, it became a handful.
That codebase is the polar opposite of a finely crafted pen, and the ugliness all comes from the API.