Implementing Swift 6 in Neon Vision Editor

Lessons, Friction, and Architectural Reality

Swift 6 is one of the most significant shifts in the Swift ecosystem in recent years, bringing stricter concurrency rules, stronger compile-time safety, and a fundamentally different approach to managing shared state. While these changes promise more reliable and maintainable applications, adopting them in an existing codebase is rarely a simple version bump.

In the development of Neon Vision Editor, my native code editor for macOS, iPadOS, and iOS, migrating toward Swift 6 exposed a wide range of challenges — from Sendable diagnostics and MainActor isolation to architectural decisions affecting editor, Git, AI, and remote-session workflows. This article explores the lessons learned, the obstacles encountered, and the practical solutions that emerged during the transition to Swift 6.

Swift 6 is often presented as a clean evolution of Swift concurrency. For smaller applications or greenfield projects, that may largely be true. For a native editor like Neon Vision Editor — a cross-platform SwiftUI/AppKit code editor with asynchronous syntax highlighting, multi-window workflows, and large-file handling ambitions — the reality was considerably more complex.

The migration forced me to confront architectural assumptions that had quietly accumulated over time.

Neon Vision Editor was intentionally designed around a lightweight philosophy: native Apple frameworks, minimal…