From the start of this project months ago, I was intransigent about one thing: document everything in the process of building it. And this time is no difference.

Today, I’m really confident about the choice I made for this app; of it being a companion app to Xcode, this was especially true when I did my research and found that implementing my vision is really possible technically with AppKit and the macOS Accessibility API. This is why, today I’m introducing a new name for this project and a new homepage.

Autographe is now XCommander.

From now on, all the build log will be there, and I’ll no longer publish blog posts and projects updates here. I migrated all the blog posts written here to the new website, because they are part of the app DNA, but still; I’ll try to keep this domain name alive, at least for my inner nostalgia.

By the way: if you happen to know me, you know that I’m a bit allergic to LLM content and especially coding with LLMs or letting them do my work. But I’m not a web designer, and getting help from an LLM to implement the website’s CMS custom template was the only option for me to see my vison alive. I’m very happy with the result.

See you there.

The last incarnation was a programmers text editor macOS app. Autographe now is a “companion app” to Xcode.

More than three months and still nothing to show!

Yes, already morer than three months into this project and still there’s nothing to show. Of course, I could have just fired some LLM and asked it to at least do the MVP for me, but that’s not in my agenda. I’m doing this project to explore, learn, practice and have fun. Do you find “coding” using an LLM fun?

Autographe started as a prose writers macOS app. I always dreamed to be a writer (lol) and I thought to myself this project will be huge: many writers want to enter the flow state asap, so why not give them a similar experience to Spacemacs in a gorgeous macOS shell? Folks who use Vim/Emacs all the time know about the productivity gains we get with a keyboard first text editor.

While doing my exploration of the subject, I hit the first major roadblock: text editing. I never thought there’s so much computer science involved in text editing. Compared to it, doing iOS apps is like playing Legos. I was so naive.

Text editing is HARD!

Text editing is very hard, and early on, that was the crazy thing that kept my fire on to develop the app; I liked the challenge more than anything else, partly because I didn’t have a real appreciation of the hard parts, being naive served me well during this phase.

I’ve read articles that proved that Text Rendering Hates You, that Text editing hates you too, that text editing is a Craft and hence needs long time to get right. But the ignorant that I was kept digging, till I read the xi-editor retrospective by Raph Levien, and there I realized that maybe I should learn from the pros and just stop my crazy endeavor, because after all, I’m not 15 anymore and I don’t want to spend five years building a text editor just to get to the same conclusions.

Briefly, this is what happened:

• I started by researching text editing technically, in general.
• Then I did some research on what the Apple/macOS ecosystem has to offer: TextKit 2, the most complete text engine ever made, that is 30 years old and needs basically a PhD. to get the hang of it.
• I started to identify the feature set I wanted, then some tiny projects to explore what interacting with TextKit 2 really meant. Then soon after that I got a window that has a text editing pane inside, and I could programmatically do one or two glyph manipulation inside it. The realization: why not doing the extra mile and build a programmers text editor?!
• Autographe’s new incarnation now is a programmers text editor that aims to have the sole of Doom Emacs/Spacemacs and the shell of a native macOS app.
• Yes, source code rendering is much simpler because there’s not big glyph manipulation as everything is monospaced; but it has its own complexity: syntax highlighting and semantic navigation (ok we have Tree-sitter), code intelligence (ok we have LSP), code building and running (ok let’s start just with Swift and SwiftPM).
• Wiring those libraries/tools into a simple AppKit window wasn’t simple, but I got a working POC. I was so happy.
• Time to do some polish then. And that was the time the complexity of text editing hit me again: even with premade libraries and tools, making them work to get a simple feature of what a good text editor has is a lot of work. Surfacing Tree-sitter tree into TextKit2 is a lot of work, making the app core communicate seamlessly with an LSP server (SourceKit-lsp for starters) via JSON-RPC has its own quirks, and implementing text editing idioms that we take for granted (adding closing brackets automatically, smart indenting code.. etc) need to be implemented.
• I was very tired. Took some rest (two or three days), then just to change a bit, I started exploring text editing in pure C! Why? Because Tree-sitter is in C, and C must have the most battle tested libs and APIs out there; so I said to myself maybe it will be easier! Well, not at all, because GUI in C, which has nothing to do with text editing, is totally a whole new story. What about Rust and “cosmic-text”? I was clearly with no compass at this phase and finally thought of abandoning my dream project.

What about Xcode?

I took some rest, two days. I live in Sète - France, a beautiful Mediterranean town, so it wasn’t that hard to go for a lovely walk in town or go swimming at the beach with the family.

I do mostly Swift/SwiftUI development, and I do it in Doom Emacs not Xcode. I never liked Xcode as many Apple platforms developers; but my Autographe endeavor taught me to respect established programmers editors. All of them. And Xcode was one of the legends in this space.

Back to my desk, I fired Xcode to try to feel how its text editing experience was (hey, I know a bit or two about text editing internals now!), I loaded one of my projects, activated Vim mode and started playing; then something clicked in my head: why creating a brand new editor when we have Xcode itself? I mean, maybe I can develop my whole Doom Emacs/Spacemacs UX around Xcode as a plugin? My eyes were wide open, and enthusiasm was back!

After a couple of Web searches I learned that Xcode plugins is a thing of the past, no more a thing since Xcode 8!

But the search led me to something I heard of, but never touched directly: The Accessibility API. I know that Apple put enormous efforts into accessibility, and this is not new, it was since the NS days. What I didn’t know, and this one was mind blowing for me (I still consider myself new to the Swift/Apple ecosystem), was the fact that we can drive whole apps with the Accessibility API!

That was just huge for me, and reading more about it, I discovered that even Xcode is open to that API and hence theoretically I can drive some of its functionality with the accessibility API to mimick the keyboard driven workflows of Doom Emacs/Vim/Spacemacs.

Imagine if I could develop a simple macOS app, that is loaded in the background (like Alfred), and it awaits that Xcode is in front to activate itself, and when I hit the Which-key, the app should give me the bottom panel like Spacemacs’s as an overlay on top of Xcode itself, then if I tap some key combination like which-key b b it triggers a project build, as if I hit Command b!

I now have a clear exploration to do, and if it sounds feasible and sound, I believe it will be the last incarnation of Autographe: augmenting the Xcode experience instead of rolling my own.

Its amazing how starting actually working on a planned software product, could change ones beliefs about that product. For Autographe, it was me realizing how much I enjoy programming in Swift and how much I wanted -without knowing it- a programmers text editor that mimics my current Doom Emacs setup while leveraging the full power of a native macOS app all for Swift development.

I started working on Autographe as being the writers desktop app, and it was a lot of fun and learning. Diving especially into the text manipulation layer and knowing a thing or two about SourceKit LSP (since I work exclusively on Doom Emacs) made me realize that I already know/have the basic building blocks of a native Swift text editor! So I said to myself why not give it a shot, especially that I’m a firm believer in building products that solve our own problems; and Autographe as a writers app is far less a tool I will use extensively compared to it being my dream Swift text editor.

So, at this stage of development, and given the modular architecture I’ve put from the start, it wasn’t that hard to actually convert the current codebase to a Swift editor with all the modal and keyboard-first niceties I’ve developed, the result is an amazing MVP that convinced me to make the heretical decision: building my own text editor!

Autographe -as a project- is now a Swift/code editor with the soul of Doom Emacs and the body of a native macOS app. It will be modal, workspace oriented, and built around the pillars of the Swift ecosystem (SourceKit LSP code intelligence, SwiftPM, xcodebuild etc..) Autographe is built for a specific persona: the Swift hacker who uses swift beyond iOS development (server code, CLIs, emmbedded and WASM), who finds Xcode heavy, and wants a gorgeous native tool that is rooted in the Emacs/Vim culture.

Autographe will not be a fully fledged IDE, even if LSP gives us many cool code intelligence features. Xcode already is the best IDE for Apple specific development. Autographe is lite by conviction; it will be a trimmed out Doom Emacs/Vim version with native performance and leveraging the Swift ecosystem command line tools to get things done, instead of bloating the UI with point-and-click complex workflows.

Last but not least: I’ll craft it on my own, no AI assistance, because I want to build my own tools and put into them my own personality, all while taking the time to learn. And for the final product, there will be no AI tools for code assistance; I want to encourage Swift developers to give their craft more importance by doing it themselves, I’m sure it will be better for them and for the ecosystem.

Let’s do it!

Concretely the MVP can:

1. Open, edit, and save a Markdown file: real multi-line editing with a visible and correctly-placed cursor.
2. Move and edit modally: a working NORMAL/INSERT distinction and enough of the SPC leader keymap to feel like Doom Emacs’s.
3. Render prose beautifully: proportional shaping (if the expression is right) of text, not a rigid character grid, and basic Markdown syntax styling.
4. Save invisibly to git: every save creates a background snapshot, the writer could also save (read commit) milestones, or special forks of his work, all without seeing any of git’s intricacies.
5. Stay out of the way: which-key hints and a discoverable command palette, for minimal writer-tool latency.

Everything else is post-MVP and explicitly out of scope. I name the boundary now as my north star to ship as fast as I can. The discipline of a named MVP is what lets a solo founder ship, and this very five-point roadmap will keep me ruthless about scope.

Speaking of “shipping fast”; I’m not in a hurry to get the product out in the traditional way, because the aim is also for me to learn while building, and boy there are things to research and learn about; both in regards to the tech stack and the writers craft. For example, some of the technical questions I want to answer before or while building the app:

• How text editors are built and do I need to start from scratch?
• What should I research before start building: I know that text rendering and editing is hard, I’ve read one or two things on the subject once, but how come we already have so beautiful and efficient text editors since decades? There have to be some known “knowns” to start from.
• Will the core of the app be a simple combination and orchestration of some libraries or will I have to dive deep into text manipulation specific data structures and algorithms?
• Autographe needs low latency as a feature so that the gap between keystrokes and pixel is imperceptible, but how to model all of that the right way from the start?
• How should I approach modal editing à la Doom Emacs and Spacemacs: will it be a state machine? How will that map to the gui level I’ll be using?
• how much “work” is already handled at he OS and framework levels? How much do I need to build myself?

At this stage, the question list has no limit, every question has layers of related questions.

Honestly, the vision is blurry; there are plenty of prose text editors, not all of them are successful commercial products, prose writers have already their favorite tool, the technical domain is hard!

Certainty of death? Small chance of success? What are we waiting for?

— Master Gimli

Exciting times ahead. Let’s get into it.

Why yet another desktop app for writers, isn’t there enough of them?

The software development industry has gone absolutely crazy with AI. Developers of all levels are using LLMs to produce code to the detriment of their hard-won skills. Not long before, we were arguing about, and almost shy talking about the myth of the 10x programmer; today everyone and his dog is developing apps, they are effectively a 100x developers in terms of the amount of code produced.

Autographe is like an antidote for me, an attempt to preserve my software craftsmanship and stay true to my values: producing software crafted by a human for humans. I want to do it “à l’ancienne”, no Claude, no Codex, no Cursor, no LLMs, just me and my hands.

That was you, what about writers?

I’ve always wanted to be some sort of writer, but never got the time nor energy to work it out. Fortunately I read a lot; and as a reader, I’ve learned that writing is a huge intellectual endeavor that comes way before the styling aspect of it, that most readers are going to judge. Unfortunately, AI enshittification made its effect on so many writers (or pseudo-writers should I say), and the results, even at this early point of AI history are so bad: masses of text that are banal, generic and shapeless.

What made things worse is that writing apps started including AI services. Writers can now be more productive (more text in less time!) thanks to AI! This is insane! I don’t want to read “productive” writers text, I want them to take their time!

So Autographe will be my response to today’s prose writing tools, an app that:

• empowers true writers to write in their own words in their keyboard
• is local-first: no remote server
• no AI, with intuitive file based organization
• has a clean design optimized for flow: writers will write, the app will disappear while they write
• offers real productivity with a modal-first editing (à la Emacs and Vim)
• has intuitive version control powered by Git: for writers, not for developers
• markdown based

Autographe for writers is what Emacs or Vim is for developers

A macOS app, built for maximum snappiness, and true/genuine writers happiness.

AI usage is eroding craft, I’m building an antidote for myself and for writers who feel the same. I’m very excited and honored to start this project. No growth hacking for this one, no build-in-public bullshit, I’ll take my time to work on it, get feedback, optimize and use it myself. If some day, a dozen writers are happy with it, I’ll consider myself a hero.

Autographe is text written by your own hand.

اللهم لا علم لي إلا ما علمتني إنك أنت العليم الحكيم.

اللهم لا فهم لي إلا ما فهمتني إنك أنت العليم الحكيم.

ربي اشرح لي صدري ويسر لي امري واحلل عقدة من لساني يفقهوا قولي.

اللهم اجعل عملي كله صالحاً ، واجعله لوجهك خالصاً ، ولا تجعل لأحد من خلقك فيه شيئاً.

اللهم آمين ، و صلى اللهم و سلم على نبينا محمد وعلى آله وأصحابه ومن تبعهم بإحسان إلى يوم الدين.

وسيم