How CodeDraft works
CodeDraft is a fast, dark macOS text editor built around drafts. This page explains its two modes and walks through every feature in plain language.
Two modes
CodeDraft works in one of two modes. It picks the right one for you automatically based on what you open.
One clean page
You get a single page to write on. This is the normal mode for quick notes, snippets, and scratch code. Every draft feature below is on.
All draft tools — auto-save, naming, tags, and search — work here.
A full file tree
When you unzip an archive, unpack an .app, or open a folder, CodeDraft shows the whole file tree in the right column so you can jump between files. Right-click any row for New File, New Folder, Rename, Duplicate, Move to Trash, Get Info (size, dates, permissions, owner, tags), or Reveal in Finder — full file management without leaving the app.
You enter project mode automatically. Here the draft features are turned off, because you are editing real files on disk — not scratch notes.
Draft features
Drafts are CodeDraft's heart. In draft mode the app saves, names, tags, and finds your notes for you — so you never have to think about files or folders.
Auto-save to drafts
Whatever you type saves itself to your drafts folder as you go. You never get asked to save, and you never lose work.
Smart naming
A new draft is named from its first line and given the right file ending for its language, all on its own.
Auto-tags & classify
The app reads each draft on your Mac and adds tags by itself, so your notes sort into groups without any effort.
Typo-proof search
Type a few rough, even misspelled words and CodeDraft still finds the right draft. The search runs fully offline.
Silent close
Close a draft and it is already saved to your folder. No "Save changes?" pop-up ever appears.
Paste & run
Paste a snippet and the app spots its language right away, names it, and saves it — ready to run in one click.
Title-bar rename
Rename a draft from the title bar and the file on disk follows. The title, Recents, and editor all update together.
⌘K — Search Drafts
If CodeDraft has one feature the whole app was really built to justify, this is it. Drafts have no folders to browse and no names you chose yourself — so finding one again had to work by feel, not by filing. This got more design and engineering time than anything else in the app.
Works from anywhere in the app
Press it, start typing — no menu, no click. A Spotlight-style panel drops in, ranks as you type, and Return jumps you straight into the result, cursor and all.
The story
A normal project has a file tree you organize by hand, so a fuzzy filename matcher is enough — you already half-remember the path. A draft has neither: it's an auto-named scratch note, one of maybe hundreds, and the thing you remember is never the filename. It's a stray keyword, a typo, half a phrase in the wrong order, or just the general idea of what the file was about. A plain substring filter fails at all four of those. So instead of one matching algorithm, ⌘K runs an ensemble — exact title, title-prefix, contains, token-prefix, subsequence compactness, preview-contains, and trigram similarity are each scored and summed, so one strong signal wins even when the others come up empty. A fourth layer of on-device semantic embeddings sits on top of that, gated so it only engages once the lexical signals already suggest relevance. All of it runs fully on-device, model-free where it can be — no network round-trip, which is also why it's instant.
Where it earns its keep
A stray keyword, not a filename
You remember the curl command had "Bearer token" in it somewhere — you never remember what you named the file. Type the phrase, not the name, and it still surfaces.
Typos don't break it
Type "kubernets" or "recieve" and the draft you're thinking of still comes up — exact spelling was never the requirement.
Half-remembered, wrong order
Type "parse json" for a file actually named json-parser.py — word order doesn't matter, only that the pieces are there.
Search the idea, not the words
Type "sort algorithm" and a draft titled quicksort.swift that never uses those two words together still surfaces — the semantic layer understands the concept, not just the letters.
Writing & editing
The tools you use while you type.
Editor grid
An optional graph-paper grid of square cells, colored to match your theme.
Reformat code
Press Ctrl+Opt+F to unfold a squished, minified blob into clean, readable lines. One undo puts it back.
Clickable links
Any URL in your text gets underlined automatically. Cmd+click one and it opens in your browser — no need to select and copy it first.
Multi-cursor
⌘-click anywhere to drop an extra caret, or press ⇧⌘L to select every match of the current word at once (there's an "Add Next Match" command in the palette too). Then type — every caret edits at the same time.
Bracket-pair highlight
Put your caret next to any ( { [ or its matching ) } ] and the paired bracket flashes instantly — works in both directions, so it doesn't matter which side of the pair you land on.
Ligatures on by default
Coding fonts that ship ligatures (Fira Code, Cascadia Code, and friends) render them right away — ->, !=, and >= merge into their single-glyph arrows automatically, no setting to find and flip. Fonts without ligatures (SF Mono, JetBrains Mono) are unaffected.
Syntax highlighting
Fast, accurate color for 79 languages across 306 file extensions, built in with nothing to install — Swift, Python, Rust, Go, TypeScript, SQL, Terraform, and dozens more. It also recognizes dotfiles and no-extension files by name or shebang: .bashrc, .zshrc, Dockerfile, Makefile, Gemfile, nginx and SSH configs all light up correctly with no setup.
Minimap
A tiny scaled picture of the whole file sits on the right edge and keeps pace as you scroll. Click or drag anywhere on it to jump straight there. Run a find and every match lights up as a tick on the strip, the current one taller and brighter, so you can see where all your matches are before you even step through them. It also reads the file's shape — headings, MARK: comments, function and class declarations, even main/entry points — and labels them right on the map, Xcode-style, so you can spot the structure of a huge file at a glance.
Find & replace
We studied a lot of editors' find bars before building this one — VS Code's is the one that got out of the way the most, so that's the model we followed, then went further. One find bar, whether you press the toolbar search button or ⌘F. A live match count, regex support, matches lit up in the text and on the minimap, and replace that keeps your capital letters. Under the hood it's a byte-by-byte search over the buffer, not a string scan, so it stays fast no matter the file size. ⌘G and ⇧⌘G walk to the next and previous match. Find All opens a clickable list of every match with its line number — click to jump. This one feature got more polish than almost anything else in the app.
Markdown read mode
Open a Markdown file and a book icon appears in the toolbar. Press it — or ⌃⇧⌘R — to swap the raw text for a clean, comfy reading page: generous line height, a proper heading hierarchy, and a warm daylight paper page by default — even when the rest of the app is dark — because long-form prose reads best on light. The toolbar streamlines too: it drops the code and file controls and leads with just the three things that matter while reading — read mode, the theme colour toggle, and Pin on Top. It stays live as you edit — no separate preview to refresh. Press ⇧⌘F to cycle the reading font through three setups: Mixed (New York serif body, San Francisco sans headings — the default), all-Serif (New York throughout), and all-Sans (San Francisco throughout). Pair it with Pin on Top and you've got a clean, distraction-free page for reading documentation while you work — the page stays put above whatever else you're doing.
Open, run & convert
CodeDraft opens far more than plain text — and can run or unpack it too.
One-button run
One button runs your script with the right interpreter found for you, or reopens an office doc in its own app — always saving first.
Open anything
Drag and drop any archive, Office file, or binary and it opens in a second — then you can run it.
Unpack & repack
Many modern files are really just ZIP archives. CodeDraft unzips them, lets you edit inside, then zips them back up.
Office docs to text
Word, Excel, PowerPoint, and PDF turn into plain text and CSV you can read, search, and edit.
Peek inside any binary
Open a database, image, or program and CodeDraft shows it as a hex and text dump, with its magic bytes and structure laid out.
Workspace & looks
How the app feels around your text.
Twelve dark themes
Twelve calm dark looks, and the whole window tints to the color of the theme you pick.
Pin on top
Float a small editor above any other app — handy to paste a command, copy a value, or fix small things in a loop.
Menu-bar favorites
A menu-bar icon opens files fast — drop one onto it to open, pin your favorites, and browse recent files.
Stays fluid on huge files
A 1 GB file opens in about 62 ms using roughly 20 MB of RAM — the file is never fully loaded, just memory-mapped, so opening, scrolling, and searching all stay fast no matter the size. How it works ↓
Jump back & forward
Ctrl+Cmd+Left and Ctrl+Cmd+Right retrace your steps through the file — every jump from Find, Find Results, or Go to Line is remembered, just like a browser's back button.
Lock a file
Toggle a file to read-only right from the app — it locks in Finder too, so it stays protected everywhere, not just here.
Copy path, reveal & share
Right-click the title bar for Copy Path, Copy Name, Reveal in Finder, or Share — the standard macOS share sheet (AirDrop, Messages, Mail, and anything else installed) for the file you're editing.
Under the hood
CodeDraft's editor is built on CoreNG, a clean-room text engine written from scratch to replace the old CotEditor-derived core (TextKit + NSDocument). You're technical, so here's the honest, no-marketing version of why it exists and how it actually works.
Why we rewrote the core
The old core loaded a file into memory as one Swift String and handed it straight to NSTextStorage — no streaming, no viewport, no large-file mode. Above roughly 100 MB it simply froze: syntax highlighting stalled, layout blocked the main thread, and there was no way out short of force-quitting. Rather than patch TextKit, CoreNG is a ground-up rewrite with a written behavioral contract and a numbered set of hard performance gates (P1–P12) that every build must clear before it ships — measured end-to-end on a 1 GB test file, through the real viewport, not synthetic micro-benchmarks.
Ten modules, one job each
How a huge file stays fast
Opening a file just memory-maps it — nothing is read up front, and edits go through the same piece table, so inserting or deleting text never moves the rest of the file.
memchr bounded scan
Jump to the nearest checkpoint, then scan at most 2,048 lines directly on the mapped memory — the same primitive that gives grep its speed.
How search works
In-buffer find runs on raw UTF-8 bytes, not grapheme clusters — no Unicode segmentation overhead — streaming the mapped buffer in 4 MiB windows, so cost scales with matches found, not file size.
⌘K Draft Search is a different problem — a half-remembered name, not a path — so it runs an ensemble of signals instead of one algorithm, each scored and summed so a strong signal wins even when the others come up empty:
Keyboard shortcuts
Every built-in shortcut, grouped by what it does. All of these also live in the Command Palette (⌘P) if you'd rather search than memorize.
Essentials
Find & Multi-cursor
Lines & Code
Navigation
View & Appearance
Window & Misc
Mouse gestures worth knowing: ⌘-click empty text drops a multi-cursor caret; ⌘-click a link opens it; double-click inside a quoted string or bracket pair selects the whole enclosed content; ⌘ + scroll zooms the editor font.
FAQ
Questions we actually get asked.
Will the code go on GitHub?
Honest answer: no plan to. Not out of secrecy — the actual reasoning is that the case for "publish it publicly on GitHub" was built for a collaboration model that AI coding assistants have quietly made optional.
Open source's real value was never the license text — it was the protocol: a public repo plus Git let a stranger read your code, fix a bug, and hand the fix back as a pull request. That protocol needed the code to be public, because the collaborator was a person who had no other way in.
An AI agent doesn't need the code on GitHub to read it, understand it, extend it, or fix it — it needs access to the codebase, which it already has, locally, the same way this app's own development happens. The collaborator-onboarding problem that GitHub solved for humans is solved differently now. That's the whole argument — not that open source is wrong, just that its reason for existing has moved.