Skip to main content
Vibing With Kerim Experiments in AI Coding

Back to all posts

Porting

Published on by P. Kerim Friedman · 3 min read

I often get asked if it would be possible to port FINAL|FINAL to Windows or Linux. The answer is complicated.

Open Source

FINAL|FINAL is licensed under the AGPL. That means anyone can fork it, modify it, and distribute their own version. I genuinely hope someone does. I’d love to see a version that runs on Windows or Linux.

Having said that, it isn’t as simple as asking Claude to write you a version for your platform. Let me explain why.

You Have to Use It

While the feature list on the website gives you a sense of what the app can do, the devil is in the details. Unless you actually use the app, you can’t understand how these features interact with each other. For instance, “focus mode” doesn’t just hide the sidebars — it interacts with annotation visibility, paragraph highlighting, and editor state. None of this is obvious from just reading the docs.

To port the app well, you’d need to use it daily for a real writing project on macOS. You’d need to internalize how the pieces feel together, not just how they’re listed separately. A porter who skips this step will build something that looks like FINAL|FINAL but behaves wrong in all the subtle ways that matter. If someone vibe-coded a product like this, without paying attention to the details, it would do more harm than good. As I’ve documented in this blog, I’ve worked hard to make sure that the app is solid and reliable. (Though I still have more work to do on that front.)

It’s Not Just the Chrome

The obvious barrier is the interface. The app’s shell is built with Apple’s own tools, so that part clearly needs to be rewritten from scratch for another platform. What people don’t realize is that the testing infrastructure is equally platform-specific.

I’ve written about this in several posts: Smoke Tests explains the test suite I use to catch regressions, Debugging covers the systematic workflow I follow when something breaks, and XcodeBuild MCP describes how I’ve automated the whole process so that the AI can run tests without my supervision. All of this runs through Apple’s testing tools.

Testing isn’t decoration on this project — it’s central to how development works. The app has many interacting features, and the test suite is what makes it possible to change one thing without accidentally breaking three others. Without an equivalent testing setup on another platform, a port would be fragile from the start and increasingly difficult to maintain as features evolve. Anyone serious about porting would need to rebuild this infrastructure first, before touching the UI.

What IS Portable

The good news is that significant parts of the architecture are already cross-platform. The two editors — Milkdown for WYSIWYG and CodeMirror for source mode — are pure web technology. They run in a browser view today and could run in any browser view tomorrow. The database layer is SQLite (GRDB), which runs everywhere. And the external integrations — Zotero over HTTP, Pandoc via the command line — use standard protocols that work on any operating system.

A realistic approach would probably be something like Electron or Tauri wrapping the existing web editors, with a new native shell handling the sidebar, project management, and database layer. That’s still a substantial project, but at least you wouldn’t be starting from zero.

If You Want to Try…

Forks are welcome. That’s the whole point of choosing the AGPL. I would be thrilled to see FINAL|FINAL running on other platforms, and I’m happy to answer questions from anyone who wants to try. But please stay in contact with me as you do this. Thanks.