# kitlangton/Hex: the legacy Swift voice-to-text Mac app, and what the Rust rewrite changes

> Hex is a press-and-hold dictation tool for Apple Silicon Macs that transcribes on-device and pastes into whatever field has focus. The Swift repository is now a preserved legacy line; new work happens in the Rust rewrite.

**kitlangton/Hex** — Legacy Swift Hex app. Try the Rust rewrite at hex.kitlangton.com; new source at github.com/anomalyco/hex.

- Repository: https://github.com/kitlangton/Hex
- Website: https://hex.kitlangton.com
- Stars: 2,897 · Forks: 225
- Language: Swift
- License: MIT
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/en/projects/kitlangton-hex

## What Hex does, and who the Swift repository is still for

Hex is a dictation utility for macOS. The README describes the interaction in one line: press and hold a hotkey to transcribe your voice, and the result is pasted wherever you are typing. There is no window to switch to and no clipboard step to perform by hand. The app records while the key is down and starts transcription when you release it.

The people this fits are those who write in fields that do not belong to a single application: issue trackers, chat clients, editors, terminals. Because Hex pastes into whatever holds focus, it does not need integrations with any of them. The cost of that design is the accessibility permission, which is what lets it type into other applications.

The repository itself is a different question from the app. The README opens by saying the author rewrote Hex in Rust, that the new source lives at anomalyco/hex, and that this repository preserves the original Swift app, its history, and its releases. The last push was on 2026-08-27, which lines up with the v0.8.5 release on the same day. So the code is not abandoned in the sense of being archived, but the README is explicit that current development is elsewhere. Anyone arriving here should read the project as a maintained artifact rather than an active codebase.

## Press-and-hold versus double-tap lock recording

Hex ships two recording modes, and the difference matters more than it first appears. In press-and-hold mode you hold the hotkey while speaking and release it to start transcription. That is the mode for a sentence or two. The second mode is a double-tap on the hotkey, which the README says locks recording. You then speak for as long as you want and tap the hotkey once more to begin transcription.

The lock mode exists because holding a key while composing a paragraph is uncomfortable and because some keyboards will not report a held key reliably over long intervals. If your dictation is usually longer than a breath, the double-tap path is the one to configure first. The README does not describe a maximum recording length, so the practical ceiling is whatever the underlying transcription engine and your machine's memory allow.

Both modes depend on the same global hotkey, which you configure after launch. There is no documented per-application hotkey, so if you want different behaviour in different apps you would be changing the single setting, not maintaining profiles.

## Installing the legacy Swift build and dictating your first sentence

The README gives two installation paths. The first is a direct download of the legacy Swift build from the project's S3 bucket. The second is Homebrew, which is the one worth scripting if you manage several machines. The cask name is kitlangton-hex, not hex.

```bash
brew install --cask kitlangton-hex
```

After the install completes, launch Hex from Applications. On first run you will be asked for two permissions: microphone access so the app can record, and accessibility access so it can paste the transcribed text into other applications. The README states both requirements plainly. If the paste step does nothing while recording works, accessibility is the permission to check first.

Next, set a global hotkey. The README does not prescribe a default, so pick a combination that does not collide with your editor or window manager. Then test the press-and-hold mode: hold the hotkey, say a short sentence, release. The transcription process starts on release, and the text should appear in the field that had focus when you began.

One constraint is stated in the README with emphasis: Hex is currently only available for Apple Silicon Macs. There is no Intel build in this repository, and the Homebrew cask will not give you one.

## Two on-device transcription engines, and what the README leaves open

The Swift app supports two transcription backends, both running on the machine rather than in a cloud service. The first is Parakeet TDT v3, which the README says is reached through FluidAudio. The second is WhisperKit, from argmaxinc. Because both run locally, audio does not leave the Mac for transcription, which is the main reason to prefer this class of tool over a hosted dictation API.

The README names both engines but does not explain how to choose between them, whether both are bundled, or how model weights are downloaded and where they are stored. That is the thinnest part of the documentation. A reader deciding whether to install Hex cannot tell from the README alone which engine will run by default, how large the download is, or whether switching engines requires a reinstall. Those answers would have to come from the application itself or from the linked upstream projects.

The architecture underneath is the Swift Composable Architecture, which the README cites as the framework the app is built with. That choice shapes the repository layout: Hex/ holds the application target, HexCore/ holds the separable logic, and HexTests/ holds tests against it. Anyone reading the source to understand the transcription flow should start in HexCore rather than in the SwiftUI layer.

## Where the legacy Swift app is the wrong choice

The clearest limitation is hardware. Apple Silicon only, stated in the README. If you are on an Intel Mac, this build is not for you at all.

The second is platform. The related searches around this project include people asking for a Windows version of Hex voice-to-text. Nothing in the repository provides one. Hex is a macOS application built on SwiftUI and the Swift Composable Architecture, and the rewrite is also described as a Mac-facing project with its own site. A Windows user has no path here.

The third limitation is project direction. The README says to use anomalyco/hex for the Rust beta, for new features, and for current development, and that issues specific to the legacy Swift app can still be reported in this repository. That means bug reports about the Swift build are in scope, but feature requests are not. If your reason for adopting Hex is a feature that does not exist yet, this repository is the wrong place to wait.

Finally, the permission model is a real cost. An app that types into arbitrary applications needs accessibility access, and that is a broad grant. If your environment forbids it, Hex cannot paste, and pasting is the whole point.

## Hex against the macOS dictation you already have

The obvious alternative is macOS built-in dictation, and the difference is in where the transcript goes and how the session is controlled. System dictation is available without installing anything and without an accessibility grant, because the operating system already has the privileges it needs. It is also tied to the system's own model and settings rather than to a choice between Parakeet and Whisper.

Hex differs in two ways. It gives you a hold-to-talk gesture that works identically in every application, and it lets the transcription run through engines the README names specifically: Parakeet TDT v3 via FluidAudio, and WhisperKit. Whether that produces better text for your accent and vocabulary is not something the README claims, and it is not something this article can assert. The honest framing is that Hex trades an install and two permissions for control over the engine and a consistent hotkey across apps.

There is also the rewrite itself as an alternative to this repository. The Rust version at hex.kitlangton.com is described as a beta, and its source is at anomalyco/hex. Choosing between the two is a question of whether you want the preserved Swift line with its release history, or the newer codebase the author is actively working in.

## Maintenance, releases and the MIT licence

The repository is not archived, and the most recent release, v0.8.5, carries the same date as the last push, 2026-08-27. Before that, v0.8.4 landed on 2026-07-19 and v0.8.3 on 2026-07-09. That is a steady cadence through mid-2026, but the README's own framing is that this line is preserved rather than developed, so a reader should treat the release history as a record of a finished sequence rather than a promise about the next one.

If you do contribute, the release process is unusually explicit. Changesets drive it. For an automated, non-interactive changeset the README gives this command:

```bash
bun run changeset:add-ai patch "Fix clipboard timing"
```

For a human-written one, `bunx changeset` creates a fragment under .changeset/, and `bunx changeset status --verbose` shows what is queued. The README notes that releases fail fast when no changesets are pending, and that the release tool bumps package.json and Info.plist, regenerates CHANGELOG.md, and feeds the result to GitHub and Sparkle. The root CHANGELOG.md is mirrored into Hex/Resources/changelog.md by `npm run sync-changelog` so the in-app sheet matches the published releases. Anyone patching this repository should expect to run that pipeline rather than tag a release by hand.

The licence is MIT, stated in the README and in the LICENSE file, and package.json repeats it for the tooling. MIT is permissive: it allows reuse and redistribution with the licence text retained. That is a statement about the licence, not advice about your situation; if you plan to redistribute a modified build, read the LICENSE file yourself.

## Conclusion

Adopt the legacy Swift app if you want on-device dictation on an Apple Silicon Mac today and you accept that the repository preserves it rather than develops it: the last push was on 2026-08-27. Do not adopt it if you are on Intel hardware, on Windows, or if you need new features, because the README points those users at the Rust rewrite at hex.kitlangton.com and anomalyco/hex. Before installing, verify three things: that your Mac is Apple Silicon, that you are willing to grant both microphone and accessibility permissions, and which of the two transcription engines you intend to run, since the README names Parakeet TDT v3 through FluidAudio and WhisperKit as separate on-device options.

## FAQ

### Is kitlangton/Hex still being developed?

The README says the author rewrote Hex in Rust and that current development, new features, and the beta live at anomalyco/hex, while this repository preserves the original Swift app, its history, and its releases. The last push to this repository was on 2026-08-27, the same date as the v0.8.5 release.

### Does kitlangton/Hex run on Intel Macs or Windows?

No. The README states that Hex is currently only available for Apple Silicon Macs, and nothing in the repository provides a Windows build. The app is a macOS SwiftUI application built with the Swift Composable Architecture.

### Which transcription engines does the legacy Swift Hex use?

The README says the Swift version supports Parakeet TDT v3 through FluidAudio and WhisperKit for on-device transcription. It does not document how to choose between them or how the models are downloaded.

## Sources

- [kitlangton/Hex on GitHub](https://github.com/kitlangton/Hex)
- [License: MIT](https://github.com/kitlangton/Hex/blob/main/LICENSE)
- [Project website](https://hex.kitlangton.com)
- [README](https://github.com/kitlangton/Hex/blob/main/README.md)
- [Releases](https://github.com/kitlangton/Hex/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/en/projects/kitlangton-hex
