Building a Native macOS Writing App With SwiftUI and Local AI

Writers Studio started as a side project to solve a personal frustration: tracking continuity across a 70,000-word manuscript. Eighteen months later, it became a shipping macOS app with AI entity extraction, a worldbuilding dashboard, and 8-format export. Here is what went into building it — and why going native was the right call.

Why Native macOS Instead of Electron

Most writing apps today are Electron wrappers or web apps. That's fine for many use cases, but writers working with manuscripts of 100,000+ words notice the difference. Memory usage, text rendering speed, and system integration (Spotlight, iCloud, Focus modes, keyboard shortcuts) all suffer in non-native environments.

Writers Studio is built entirely with SwiftUI for the interface and SwiftData for persistence. The result: snappy text editing even on large documents, tight macOS integration, and a small memory footprint compared to Electron-based alternatives.

SwiftData for Manuscript and Worldbuilding Storage

The app manages manuscripts with full lifecycle states (Planning, Draft, Revision, Final, Archived), series grouping, chapter management, and a worldbuilding system with 12 entity categories — characters, locations, items, events, organizations, and more. Each entity has structured profile fields and relationship tracking.

SwiftData handles all of this with iCloud sync built in. No custom sync engine, no server — just Apple's framework doing what it was designed to do. The tradeoff is that you're locked into Apple's ecosystem, but for a macOS-only app targeting serious writers, that's an acceptable constraint.

Local and Self-Hosted AI: More Than One Path

Privacy is a real concern for fiction writers. Unpublished manuscripts are sensitive intellectual property. Many writers are uncomfortable sending their drafts to cloud AI services — and rightfully so.

Writers Studio supports OpenAI, Anthropic, Gemini, Ollama, and user-managed servers that provide the supported OpenAI-compatible model, chat, and streaming endpoints. The cloud providers use the writer's own API keys in the Direct edition or a managed subscription path in the App Store edition. Ollama remains the simplest fully local option: it can run entirely on the writer's Mac with no internet dependency or per-request cost.

The AI features include entity extraction (proposing structured character profiles, location entries, and timeline events from manuscript text), continuity checking (detecting contradictions across chapters), and general writing assistance. They work with Ollama and with a compatible server the writer manages. Ollama can keep the entire workflow offline; a self-hosted server receives requests directly from Writers Studio and is governed by the writer's own network and privacy controls.

8-Format Export: ePUB to Final Draft

Export was a surprisingly large engineering effort. Writers Studio exports to ePUB, PDF, DOCX, Final Draft (.fdx), Markdown, HTML, RTF, and plain text. Each format has its own quirks — ePUB requires valid XHTML and a specific package structure, Final Draft uses a proprietary XML schema, and DOCX is essentially a zip archive of XML files with its own relationship model.

The Final Draft export specifically fills a gap in the market. No other fiction writing app exports to .fdx, which is the industry standard for screenwriting. This makes Writers Studio viable for screenwriters who want worldbuilding and AI features but need to deliver in Final Draft format.

Shipping as an Indie Developer

Writers Studio ships as two variants from a single codebase: a Direct edition sold through the website with lifetime licensing, and a live Mac App Store edition with a free download and optional AI subscriptions. The Direct edition uses LemonSqueezy for payment and a custom Cloudflare Worker for license activation.

The app is code-signed with a hardened runtime, sandboxed, and notarized by Apple. It went through the full security review process — something that matters for an app handling unpublished manuscripts.

What I Would Do Differently

If I started over, I would invest in a paginated text editor earlier. The jump from a simple text view to a page-based layout that handles headers, footers, and page breaks correctly was the single hardest piece of the project. I would also build the export pipeline first and the editor second — understanding the output formats shapes the internal document model in ways that are painful to retrofit.