emacs-builds: signed, native-compiled Emacs.app bundles for macOS

Five channels, and the one built for people who are careful

The badges at the top of the README point at five different release channels, and the distinction between them is the most useful thing the project documents.

There is a stable release, a pretest build, a nightly build from the master branch updated every night, a monthly build from the master branch updated on the 1st of each month, and a known good nightly.

That last one is unusual and worth understanding. The known good nightly is not a tag but a list, maintained in issue #7, of recent nightly builds which have been actively used by a living being for at least a day or two without any obvious issues. The wording is deliberately cautious, and the project says it plainly: nightly builds of Emacs are for the most part just fine, but if you don't like living too close to the edge, that issue is where you find something more recent than stable that has survived actual use.

The release naming also tells you how the channels are built. The stable release in the recent list is Emacs-31.1, published on 2026-08-25, while the nightly entries carry a date and a commit hash, such as Emacs.2026-10-18.2b0acc9.master, published on 2026-10-19. So a stable release is an upstream version number and a nightly is a date plus a short SHA plus the branch, which means you can trace any nightly back to a specific upstream commit.

The last push to the repository was on 2026-10-20, and the default branch is main. The project is not archived, and with nightlies shipping daily the volume of published artefacts is high even though the repository itself is small.

What is in the bundle, and what it is patched with

The feature list describes an application bundle that carries its own dependencies rather than relying on Homebrew to assemble them.

It is a self-contained Emacs.app application bundle with no external dependencies. Native compilation is supported through gccemacs, and you need the Xcode Command Line Tools to use it in Emacs, which has been available since the Emacs 28.x builds.

The native integrations are the reason a self-contained bundle is worth building rather than using a package manager version. Native JSON parsing, native XML parsing via libxml2, and SVG rendering via librsvg. Various image formats are supported via macOS native image APIs, which means image handling goes through the operating system rather than through a bundled library. There is also Xwidget-webkit support, giving access to an embedded WebKit-based browser through the M-x xwidget-webkit-browse-url command, and dynamic module loading.

Three patches are included, and they come from the emacs-plus project: fix-window-role, system-appearance and round-undecorated-frame. The first two are listed against the emacs-28 patch directory and the third against emacs-29, which tells you the patch set tracks upstream version changes rather than being pinned to one release.

The build itself is transparent and public through the use of GitHub Actions, allowing anyone to inspect the git commit SHAs, the full source code and the exact commands used to produce a build. That claim is the strongest one in the feature list, and it is what distinguishes this from a binary dump of unknown provenance.

Emacs.app is signed with a developer certificate and notarized by Apple, so Gatekeeper does not treat it as an unsigned application. The application bundle is produced by build-emacs-for-macos, and the Emacs source is fetched from the emacs-mirror/emacs GitHub repository.

Installing through the Homebrew tap, and the five casks

The manual route is the Releases page, with a separate link for the latest stable release. The Homebrew route goes through a tap at jimeh/homebrew-emacs-builds, and it offers one cask per channel.

The stable cask:

  brew install --cask jimeh/emacs-builds/emacs-app

The pretest build:

  brew install --cask jimeh/emacs-builds/emacs-app-pretest

The nightly, which is a build of Emacs from the master branch updated every night:

  brew install --cask jimeh/emacs-builds/emacs-app-nightly

The monthly build, from the same branch but updated on the 1st of each month:

  brew install --cask jimeh/emacs-builds/emacs-app-monthly

And the known good nightly, taken from the list in issue 7:

  brew install --cask jimeh/emacs-builds/emacs-app-good

That last one is the channel the project recommends to people who want recent but not bleeding edge, and it is a rare idea: a distribution channel that is defined by observed usage rather than by a date or a version number.

Since 2024-11-30 all builds include both Apple Silicon, arm64, and Intel, x86_64, artifacts, so the architecture question is no longer a factor when you pick a build. The system requirements are macOS 11 or later for builds produced after 2024-11-30, and for builds before that date macOS 13 Ventura or later for Apple Silicon builds and macOS 12 Monterey or later for Intel builds.

That version split is worth noting if you are restoring an old build from a backup, because the same artefact name can have a different minimum system version depending on when it was produced.

The emacs command, and why a cask install opens the GUI

There is a small awkwardness in the CLI story, and the README addresses it directly.

When you install through the Homebrew cask, CLI usage is set up automatically by exposing an emacs command. The catch is that it will launch Emacs into GUI mode. To have emacs in your terminal open a terminal instance of Emacs instead, add this alias to your shell setup:

alias emacs="emacs -nw"

For a manual installation the situation is different. The builds come with a custom emacs shell script launcher for use from the command line, located next to emacsclient in Emacs.app/Contents/MacOS/bin. That custom script makes sure to use the main Emacs.app/Contents/MacOS/Emacs executable from the correct path, ensuring it finds all the relevant dependencies within the Emacs.app bundle, regardless of whether it is exposed via PATH or symlinked from elsewhere.

The reason that matters is the self-contained nature of the bundle. If you symlink the emacs binary into your PATH, the process needs to find the resources and the shared libraries that live inside the app bundle, and a naive launcher would look for them next to the symlink. The custom script resolves the bundle path first, which is what makes a manual install behave the same as a cask install.

To use the manual launcher you add the bin directory to your PATH, and the README gives a guarded form of that for an app in /Applications:

if [ -d "/Applications/Emacs.app/Contents/MacOS/bin" ]; then
  export PATH="/Applications/Emacs.app/Contents/MacOS/bin:$PATH"
  alias emacs="emacs -nw" # Always launch "emacs" in terminal mode.
fi

The if test is there so the PATH entry is only added when the app is actually present, which keeps a shell configuration from referring to a directory that does not exist. And if you want the terminal emacs to launch a GUI instance instead, the note says not to use the alias from that example.

A repository that is mostly configuration, not source

The top level of the repository is worth looking at, because it explains what kind of project this is.

There is no source tree for Emacs itself, no build script for the editor and no C code. What is there is a .github/ directory holding the workflows, a .gitignore, a .pinact.yaml for pinning GitHub Actions dependencies to specific commits, AGENTS.md and CLAUDE.md, the README, an img/ directory, a lefthook.yml for git hooks, a mise.lock and a mise.toml.

The absence of source is the point. The Emacs source is fetched from the emacs-mirror/emacs repository, and the actual application bundle is produced by build-emacs-for-macos, which is a separate project by the same author. What this repository holds is the workflow that pins a specific upstream commit, applies the patch set, invokes the builder, signs the result, notarizes it and publishes it.

That is why the transparency claim is credible. Because the workflow is the source, you can read exactly which commit was fetched, which patches were applied and which commands ran, and the .pinact.yaml exists to make sure the actions themselves do not drift.

The presence of AGENTS.md and CLAUDE.md alongside lefthook.yml suggests a workflow where both human and automated contributors are expected, and the mise files pin the tool versions used locally so that a contributor and the CI run the same tooling.

The build process section is cut off in the text available, so the exact command sequence is not readable here, but the feature list already names the two projects that do the work, and the release artefacts themselves carry the commit SHAs, so the provenance of any given build is recoverable from the release name.

Editorial conclusion

emacs-builds suits a macOS Emacs user who wants a native-compiled build with a clean installation and no Homebrew package manager dependency in the way, and the transparency of the build is the strongest argument for it. It does not suit you if you need a specific configuration, because the bundle is a fixed set of features and patches with no build-your-own route described here, and it does not suit you on a machine older than macOS 11. Before you install, pick a channel deliberately, since the nightly cask tracks the master branch every night, and read the known good nightly list in issue 7 if you want something more recent than stable without living on the edge.

Frequently asked questions

Official sources

1. Issues
2. jimeh/emacs-builds on GitHub
3. Project website
4. README
5. Releases