hear is a native CLI for macOS speech recognition, and -d is the flag that matters

Without -d, the session dies at about 500 characters

The default behaviour of the tool is a network call, and the page is candid about the cost. Running `hear` with no arguments transcribes live input from the microphone or the default audio device, and the `-d` flag is what restricts recognition to on-device capabilities. Without it, data may be sent to Apple servers, which as of writing in 2026 have a hard limit of roughly 500 characters before quitting. That is a short ceiling for dictation and a very short one for a transcript. The file path has the same shape:

hear -d -i /path/to/someone_speaking.wav > transcribed_text.txt

So the flag is not a privacy nicety bolted onto a working default; it is the difference between a tool that finishes a paragraph and one that stops mid sentence. Format coverage is the other half of the file story: anything CoreAudio supports should work, and the page names WAV, MP3, AIFF, AAC, CAF and ALAC as examples, so there is no separate decoder to install and no format flag to discover.

On-device mode only works in Siri locales

The flag that keeps your audio local has a coverage limit the page does not explain. It states that, for some reason, only those locales supported by Siri work with `-d`. No cause is offered, and no list is given, so the practical effect is that the safest mode is unavailable in some regions while the mode that talks to Apple remains available everywhere. Combined with the character ceiling, this leaves a narrow operating envelope: the locales where you can transcribe privately are not the locales where you can transcribe at length. If your language is not among the Siri-backed ones, the choice is between a server path with a few hundred characters and no private path at all.

The Homebrew route needs a full Xcode install

There are two ways in, and they cost very different amounts. The download is a zip of roughly 50 KB containing an ARM and Intel 64-bit binary for macOS 13 or later, Developer ID signed and notarized by Apple. Homebrew builds from source, and the page states that a full installation of Xcode is required for it:

brew tap sveinbjornt/hear https://github.com/sveinbjornt/hear
brew install sveinbjornt/hear/hear

Xcode is a multi-gigabyte install for a 50 KB utility, so the tap exists mainly for people who already keep Xcode around. The Makefile declares no dependencies to speak of, which is consistent with a hand-rolled `xcodebuild` invocation rather than a packaged formula. If you are installing on a fresh machine, the zip is the cheaper route and it is also the only one that arrives signed.

build_unsigned is a Debug configuration, not just an unsigned one

The build targets are named after signing, and the naming hides a second difference. `build_unsigned` invokes `xcodebuild` with `-configuration "Debug"` plus `CODE_SIGN_IDENTITY=""`, `CODE_SIGNING_REQUIRED=NO` and `CODE_SIGNING_ALLOWED=NO`, while `build_signed` switches to `-configuration "Release"`, adds `-parallelizeTargets` and requires signing to be allowed. Both targets first create the build directory and set the `com.apple.xcode.CreatedByBuildSystem` extended attribute on it, and the output lands in `products/`. The documented developer command is `make build_unsigned`:

make build_unsigned

So anyone building from source to test a change is running a Debug binary, not merely an unsigned Release one, and the default `all` target chains that same Debug build.

sudo install.sh writes into two system directories

Installing from the zip takes one command, run as root:

sudo bash install.sh

By default it puts the binary in `/usr/local/bin` and the man page in `/usr/local/share/man/man1/`, so the script needs write access to both and the page does not describe a prefix override for a different location. The script ships inside the download rather than being fetched separately: the Makefile's archive target assembles a directory named after the program and version, copies in the built binary, `man/hear.1` and `install.sh`, zips it with symlinks preserved, and then deletes the staging directory. The separate HTML man page linked from the top of the README is generated from that same source by `man/man2html.sh` through the `man` target.

An abort is fixed by right-clicking the binary

The troubleshooting section is one paragraph long and it addresses a specific failure. If running the binary leads to an abort signal, the advice is to run it by right-clicking it in Finder and selecting Open, which is expected to open the binary with your terminal client and prompt for the required permissions. That is the Gatekeeper dance for an unsigned local build, and it lines up with the build targets: a binary produced by `build_unsigned` carries no signature, so the first launch is expected to be blocked until the user grants microphone access and friends through the Finder path. A binary from the signed and notarized 0.8 zip does not need this step, which is the practical argument for downloading rather than compiling.

Test coverage stops where macOS permissions stop

There is a test entry point and an admission attached to it. Tests run from the repository root with:

bash test/test.sh

The Makefile wires a `test` target that chains a clean, an unsigned build and a `runtests` step, and the comment above `runtests` says more extensive tests cannot be written because of missing permissions from macOS. That is an accurate description of the constraint and also a measure of the coverage: the parts of the tool that matter most, microphone capture and on-device recognition, are exactly the parts a test harness cannot exercise without the same permission prompts a user has to click through manually. The repository carries `test/`, `assets/` and a `products/` directory at the top level, and the Makefile keeps the generated HTML man page out of the archive by shipping `man/hear.1` as plain text instead.

Three tags in fourteen months, and master moved past 0.8

The release rhythm is slow and the branch is ahead of it. Tag 0.6 is dated 2025-05-29, 0.7 on 2025-11-09, and 0.8 on 2026-04-29, roughly five and a half months between each, while the most recent push to the default branch `master` is dated 2026-08-30 with no 0.9 tag behind it. The Makefile still carries `VERSION := "0.8"`, which is what the archive target names the zip after, so a local build of current `master` produces an archive labelled with the previous release. The top-level tree also mixes toolchains: the project is Objective-C with `hear.xcodeproj/` committed, yet a `hear.rb` sits beside `src/`, and `CHANGES.md` and `TODO.md` are the only places the recent work is described.

Editorial conclusion

hear suits anyone on macOS 13 or later who wants to dictate from a terminal or batch-transcribe audio files with no Python environment and no separate model download. It does not suit long recordings on the default path, since anything not forced on-device risks the roughly 500 character ceiling that applies when Apple servers are involved, and the locales where `-d` works are narrower than the set Siri supports elsewhere. Before relying on it, check that your locale is one of the Siri-backed ones, prefer the signed 0.8 zip over a source build unless you have all of Xcode, and remember that the newest tag is 0.8 from 2026-04-29 while the last push to `master` is dated 2026-08-30.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. Project website
3. README
4. Releases
5. sveinbjornt/hear on GitHub