CodeEditorView: a TextKit 2 code editor view in SwiftUI

A native editor view instead of a wrapped web view

Most apps that need code editing on Apple platforms have two bad options: embed a web based editor, which brings a JavaScript runtime and a bridge, or build nothing and hope the user leaves the app. CodeEditorView takes a third route and provides a SwiftUI view implementing a code editor for iOS, visionOS and macOS, with a visual style inspired by Xcode and an implementation based on TextKit 2, the current text system in Apple's frameworks. TextKit 2 matters because it is the engine the system text views use, so selection, undo and input handling behave the way a native app expects. The audience is a Swift developer who needs editable code inside their own app and is willing to build the rest of the editor experience around it.

What the view actually implements

The feature list in the README is short enough to quote in full because each entry is a real editing capability. Syntax highlighting is supported with configurable themes. Inline message reporting shows warnings, errors and similar diagnostics inside the text, with an inline view on the right hand side of the screen, as in Xcode, which pops up into a larger overlay for more information. Bracket matching highlights the bracket corresponding to the one under the cursor, and matching bracket insertion types the closing bracket for you. The current line is highlighted, a minimap on the right gives an outline of the edited text, and the common code editing operations are available. That is a coherent editor for a narrow purpose: reading and lightly editing code inside an app, rather than a full IDE.

Themes and the state you bind to the view

Usage is a single SwiftUI view with bound state for the text, the cursor position and the messages:

import SwiftUI
import CodeEditorView
import LanguageSupport

struct ContentView: View {
  @State private var text:     String                    = "My awesome code..."
  @State private var position: CodeEditor.Position       = CodeEditor.Position()
  @State private var messages: Set<TextLocated<Message>> = Set()

  @Environment(\.colorScheme) private var colorScheme: ColorScheme

  var body: some View {
    CodeEditor(text: $text, position: $position, messages: $messages, language: .swift())
      .environment(\.codeEditorTheme,
                   colorScheme == .dark ? Theme.defaultDark : Theme.defaultLight)
  }
}

Three observations from that snippet. The editor is driven by bindings, so your app owns the text and the position and can persist or inspect them. Diagnostics arrive as a set of TextLocated<Message> values, which means your app decides what counts as a message rather than the editor running a compiler. And the theme is injected through the environment, with a built in light and dark pair, so a host app that already manages its own colour scheme can match the editor to it.

macOS gets identifier info and completion, and only macOS

The platform split is the most important boundary in the package. On macOS, CodeEditorView also supports displaying information about identifiers, such as type information and documentation provided in Markdown, and code completion. The design choice here is deliberate and, in my view, correct: that support is independent of how the underlying information is computed. A common choice is a language server speaking the Language Server Protocol, but nothing in the package requires it, so you can plug in whatever analysis you have. The catch is that this functionality will eventually also be supported on iOS, and today it is not, so an iOS or visionOS app cannot show type information or completion through this view. The demo images make the same point: the macOS screenshot shows the default dark theme with inline messages on the right, while the iOS one shows the default light theme.

Getting the package and running the demo

CodeEditorView is distributed as a Swift package. The repository carries Package.swift and Package.resolved at the top level, the sources under Sources/ with tests under Tests/, the package documentation under Documentation/ with the entry point at Documentation/Overview.md, and a Playgrounds/ directory for trying things out. The README does not give a shell command for adding the dependency, so the place to look is the package documentation and the Swift Package Index listing the project links to. To see it working, the author points at a separate repository, CodeEditorDemo, which is a cross-platform demo app. Since the package is still at version 0.x, the sensible first step is to add it to a scratch project and point it at the demo app's setup rather than wiring it into a shipping codebase on day one.

Pre-release status is the author's own statement

The status section is unusually blunt and worth quoting rather than paraphrasing: the author considers the package still to be of pre-release quality, and at this stage it is mostly a set of known bugs, which is what prevents it from being a 1.0. That is a fair description of a component with no 1.0 promise, and it tells you what to plan for. Budget for API movement on the SwiftUI side, keep the integration behind a thin wrapper of your own so the blast radius of a change is one file, and pin to a specific version rather than tracking main. The release history shows the same pattern of steady work: 0.15.3 in January 2025 with assorted improvements, 0.15.4 in April 2025 adding language configuration for Cabal, and 0.16.0 in August 2026 released as a kitchen sink release, the name that usually means many features landed at once.

Licence and maintenance

The licence is the permissive one. The README states that the code is distributed under the Apache-2.0 licence, with the copyright line reading Copyright 2021..2025 Manuel M. T. Chakravarty and the licence file at the repository root. Apache-2.0 carries an explicit patent grant and requires that modifications carry notices, which is a small cost for a component you embed in an app. On maintenance, the last push to the main branch was on 2026-10-17, which is recent work, and the newest release, 0.16.0, was published on 2026-08-10. The project is not archived and the author ships a demo app and package documentation alongside the code, so the effort is real even though the version number says otherwise. The repository also carries a .spi.yml file, the Swift Package Index manifest, which is how the package is indexed for discovery.

Editorial conclusion

Adopt CodeEditorView when your SwiftUI app needs to show and lightly edit code on iOS, visionOS or macOS and you would rather build on TextKit 2 than embed a web editor, and pin to a tagged version rather than tracking main. Do not adopt it for an iOS or visionOS app that needs identifier information or code completion today, since that part is macOS only, and do not treat it as an IDE, because it is a view rather than a toolchain. Verify first that the version you depend on exposes the bindings you need, text, position and messages, that your theme choice matches the colour scheme your app already manages, and that the language analysis you plug in on macOS is one you are willing to ship, since the package deliberately leaves that part to you.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. mchakravarty/CodeEditorView on GitHub
4. README
5. Releases