CodeEditSourceEditor is a tree-sitter backed editor view for Swift

An editor view, not a text view, with tree-sitter doing the parsing

The problem is that a plain text view in a Swift app gives you nothing but characters, and every feature a code editor is expected to have, from highlighting to diagnostics, has to be built on top of it. CodeEditSourceEditor is that layer, described as an Xcode-inspired code editor view written in Swift and powered by tree-sitter, built for CodeEdit, the app the project belongs to. The feature list is the one a modern editor is expected to have: syntax highlighting based on the provided theme, code completion, find and replace, text diff, validation, current line highlighting, a minimap, inline messages carrying warnings and errors, bracket matching, and more. The intended user is a developer building an editing surface inside a Swift application rather than a person who wants an editor application, since the package is a view, not an app.

Two APIs, one for SwiftUI and one for AppKit

The package exposes two ways to create an editor, SwiftUI and AppKit, and the SwiftUI side is described as providing extremely customizable and flexible configuration options, including two-way bindings for state like cursor positions and scroll position. The AppKit API is also available, which is what makes the package usable from a plain AppKit application rather than only from a SwiftUI one. The state object is the interesting part of the design, because it holds the cursor position, the scroll position and the find panel text, and everything in it is two-way, so you can update those values from your own code and the editor follows. The configuration object is separate again, carrying appearance and behaviour, which is where the theme, the font and the indentation option live.

The SwiftUI usage example shows the whole configuration surface

The README's usage example is a single SwiftUI view that wires up the pieces, and it is worth reading as an API reference in miniature. The text is a plain binding, the state is a SourceEditorState held in a @State property, the theme, the font and the indent option are separate state, and the editor is constructed with a language, a configuration carrying appearance and behaviour, the state binding, and a list of coordinators:

import CodeEditSourceEditor

struct ContentView: View {
    @State var text = "let x = 1.0"
    
   /// Automatically updates with cursor positions, scroll position, find panel text.
    /// Everything in this object is two-way, use it to update cursor positions, scroll position, etc.
    @State var editorState = SourceEditorState()
    
    /// Configure the editor's appearance, features, and editing behavior...
    @State var theme = EditorTheme(...)
    @State var font = NSFont.monospacedSystemFont(ofSize: 11, weight: .regular)
    @State var indentOption = .spaces(count: 4)

What the example demonstrates is that the interesting part is not the editor itself but the extension points. A coordinator is a class you implement, and it is handed the underlying controller so it can read the cursor positions and the current text and write back into the text view. The example autocompletes Hello to Hello world as you type, which is a small trick standing in for a large class of behaviour.

Coordinators let you inject behaviour without touching state

The TextViewCoordinators API exists for what the README calls more complex features that require access to the underlying text view or text storage. The claim is that you can inject custom behaviour into the editor as events happen without having to work with state or bindings, and the example implements a coordinator with two methods, one that prepares the coordinator and one that is called when the text changes. Inside that callback the code walks the cursor positions, works out the five characters before the caret, and if they spell hello it replaces the range at the caret with a space and an exclamation mark. The mechanism is a direct handle on the text view, which is also the risk: the same handle lets you break the editor's own state if you are careless.

One dependency, and the language list lives elsewhere

The dependency table is short, which is a good sign for a package that sits inside an app. There is a single entry, SwiftTreeSitter, sourced from ChimeHQ on GitHub and credited to Matt Massicotte, and the README thanks him for the work. The language support question is answered somewhere else, though. The README points at an issue on the CodeEditLanguages repository, issue 10, for information on which languages are currently supported, which is a reasonable arrangement given that the language grammars are packaged separately, but it does mean the set of supported languages is not something you can read off this repository. The repository itself follows the standard Swift package shape, with a Package.swift, a Package.resolved, Sources, Tests, an Example directory, a .swiftlint.yml for lint configuration and a .spi.yml for Swift Package Index publishing.

The project says outright that it is not production ready

There is an important notice box near the top of the README, and it is worth reading before anything else. The README states that CodeEditSourceEditor is currently in development and is not ready for production use, asks you to check back later for updates, and says contributors are welcome as the features are built out. That is a much clearer signal than a version number, and it should shape your expectations. The recent tags are v0.15.2 from 2025-09-16, v0.15.1 from 2025-08-25 and v0.15.0 from 2025-08-18, all in the zero series, while the last push to the repository was on 2026-10-18, so work continues on the main branch even though the tags have not moved much since the summer of 2025. The licence is MIT, with the text in the LICENSE.md file at the root.

It is one component in a family of CodeEdit repositories

The related repositories section places this package in a larger structure, and understanding it helps you decide what to depend on. There is CodeEdit, the main application, CodeEditTextView, which supplies the underlying text view that this package is built on, and CodeEditLanguages, which holds the language definitions and the supported language list the README points at. That layering is the practical argument for the coordinator API. If you need to change the text view itself, the package below handles that, and the language set is a separate concern that can change without a version bump here. The Example directory in this repository holds a CodeEditSourceEditorExample project, so the quickest way to see the component working is to read that example rather than to set up a host application from scratch.

Editorial conclusion

CodeEditSourceEditor suits a Swift developer building a code editing surface who wants tree-sitter backed highlighting, completion and diagnostics rather than a plain text view, and who is prepared to work on a component the project itself marks as in development. It does not suit a production app that needs a stable editor today, because the README states plainly that it is not ready for production use. Before adopting, check the supported language list in the CodeEditLanguages issue that the README points to, read the TextViewCoordinators documentation for the extension points, and note that the last push to the repository was on 2026-10-18 while the newest tagged release is v0.15.2 from 2025-09-16.

Frequently asked questions

Official sources

1. CodeEditApp/CodeEditSourceEditor on GitHub
2. License: MIT
3. Project website
4. README
5. Releases