CodeEdit for macOS: a native Swift editor that is not ready for production

What CodeEdit is trying to fix on macOS

Most editors in use today, the README argues, rely on Electron or other cross-platform frameworks, which limits how far they can use system resources. Xcode gives a native experience, but it targets Apple platforms, so a developer working on a Go service, a Rust CLI or a Python backend on a Mac does not get the same native feel. CodeEdit is the project's answer to that gap: a code editor written entirely for macOS, in Swift, with a stated commitment to stay open source and free. The README frames the goal as staying lightweight like TextEdit while scaling up toward something closer to Xcode when needed, and it says the project follows Apple's human interface guidelines. The intended audience is macOS users who care about native behaviour more than cross-platform parity. If you work across Windows and Linux too, the macOS-only design is a mismatch from the start.

How the Swift and SwiftUI codebase is organised

The repository is an Xcode project rather than a Swift Package. The top level holds CodeEdit.xcodeproj, and the source is split across CodeEdit/, CodeEditUI/, OpenWithCodeEdit/, Resources/, DefaultThemes/ and ProductIcons/. Tests live in CodeEditTests/ and CodeEditUITests/, with CodeEditTestPlan.xctestplan tying them together, and there is a .swiftlint.yml at the root for lint rules. Documentation has its own Documentation.docc/ directory, which is the DocC format Xcode uses. The README lists the feature surface as syntax highlighting, code completion, project find and replace, snippets, terminal, task running, debugging, git integration, code review and extensions. That list describes intent, not a shipped checklist; the README's own warning says the app is in development. The README also notes the project spans multiple repositories and points contributors at a project board and a current-iteration view instead of the issues tab, which is a reasonable signal that work is organised across repos rather than in one backlog.

Installing CodeEdit and opening a first project

The README does not document a Homebrew formula or a command-line installer. It directs readers to the pre-release versions on the GitHub releases page, so the practical route is to download a release build, or to build from source with Xcode. The latest release listed in the repository metadata is v0.3.6, published on 2025-08-26. To build from source, clone the repository and open the Xcode project:

git clone https://github.com/CodeEditApp/CodeEdit.git
cd CodeEdit
open CodeEdit.xcodeproj

After that, pick a scheme in Xcode and run the app. The repository contains CodeEditTestPlan.xctestplan, so the test plan is available in the project for running the unit and UI test targets. Once the app is running, the README's feature list is the map: open a folder as a project, use project find and replace, and try the terminal and task running panes. Because the README explicitly says CodeEdit is not yet recommended for production use, treat this as a test drive and keep your existing editor installed alongside it. Note that the README gives no rollback or uninstall instructions, and no migration path for settings from another editor.

The production-readiness warning is the real limitation

The most important line in the README is the warning block: CodeEdit is currently in development and not yet recommended for production use. That is the project's own statement, not an outside judgement. It means the sensible use is test-driving pre-release builds and reporting issues, which the README explicitly invites. The release cadence supports that reading: v0.3.4 on 2025-04-08, v0.3.5 on 2025-07-09, v0.3.6 on 2025-08-26. These are point releases on a 0.3 line, not a 1.0. Anyone who needs a stable editor for paid client work, regulated environments or a team-wide standard should not make CodeEdit that editor yet. There is also a platform constraint that no amount of maturity will remove: this is a macOS-only application, so it cannot be the single editor for a team that also runs Linux or Windows machines. The README does not document a plugin compatibility layer with other editors, so extension expectations should be set by what the project itself ships.

CodeEdit compared with VS Code and Xcode

The README's motivation names the difference directly. Editors built on Electron or other cross-platform frameworks are limited in how far they can use system resources, while Xcode is native but aimed at Apple-platform projects. CodeEdit takes the native route and drops the cross-platform requirement, which is the opposite trade from VS Code: VS Code accepts a web-technology runtime to run everywhere and carry a large extension ecosystem, while CodeEdit accepts macOS-only reach to stay in Swift and AppKit/SwiftUI. Against Xcode the split is different. Xcode is Apple's IDE for Apple-platform targets; CodeEdit's stated aim is to give developers working on projects not written for Apple platforms the same native macOS experience. So the choice is not which editor is better in the abstract. If you need one editor on macOS, Linux and Windows, or you depend on an extension you already use elsewhere, CodeEdit is the wrong tool today. If you specifically want a native macOS editor for non-Apple codebases and you are willing to run pre-release software, it is aimed at you.

Maintenance, releases and what the MIT licence means here

The repository is not archived, and the last push was on 2026-08-18, so work has continued recently. The most recent tagged release, however, is v0.3.6 from 2025-08-26, which is roughly a year before that last push. That gap between commits and tagged releases matters if you depend on release builds rather than the main branch: recent work may not be packaged for download yet. The project holds a weekly community meetup on Discord every Saturday at 3pm UTC, per the README, and the contribution guide points to a project board and a current-iteration view for finding work. Upgrade cost is the usual pre-1.0 cost: the README does not document a stable configuration format, a settings migration path or an extension API compatibility guarantee, so expect to re-check behaviour after each release rather than assume it carries over. The licence is MIT, which is permissive and places few conditions on reuse or redistribution; the repository ships LICENSE.md at the top level. This is a description of the licence, not legal advice, and anyone redistributing the app should read that file rather than rely on a summary.

Who should test CodeEdit and who should wait

CodeEdit is a reasonable thing to install if you are a macOS developer curious about a native Swift editor, or a Swift developer who wants to contribute to editor internals in AppKit and SwiftUI. The README makes the contribution path concrete: read CONTRIBUTING.md, find work on the project board, and use the current-iteration view to see what is in scope. It is a poor fit if you need a dependable daily editor now, if your team standardises on one editor across operating systems, or if your workflow depends on an extension ecosystem this project has not documented. The honest summary is that CodeEdit is a project to follow and test, not one to standardise on. Its own README says as much, and that candour is more useful than a feature list.

Editorial conclusion

CodeEdit is for macOS developers who want to test and shape a native Swift editor, and for Swift contributors who want to work on AppKit and SwiftUI editor internals. It is not for anyone who needs a dependable daily driver right now, because the README states it is in development and not recommended for production use. Before adopting it, check the latest pre-release on the releases page, confirm the licence file in the repository, and read the contribution guide and project board if you plan to send patches rather than only file issues.

Frequently asked questions

Official sources

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