VimR: a macOS Neovim GUI built on six SwiftPM packages

The engine ships inside the app, not on your PATH

The engine travels with the application. NvimView, the SwiftPM module that wraps Neovim, is described as an NSView bundling everything needed to embed Neovim in a Cocoa app, the Neovim binary and its runtime files included. NvimApi sits on top of it as a synchronous and asynchronous API for Neovim. Nothing in that arrangement asks you to have an nvim installed already, and the top-level tree supports it: a `Neovim` entry sits beside `.gitmodules`, and the build recipe opens by pulling submodules.

Compiling it yourself is a different story. `brew bundle` installs dependencies the README calls build tools for Neovim, so a source build compiles the engine rather than fetching a ready one. Releases pin it too. The 2026-10-10 release list carries a build named `Universal neovim-v0.12.6-20261010.102856` right beside `v0.67.0-20261010.130648`, and that name is how a reader finds out which Neovim a given binary carries. The README gives no setting for pointing VimR at a different engine, so swapping Neovim versions means going back through the submodule and rebuilding.

Six SwiftPM packages, not one application target

Six directories in the repository are usable without the app around them. NvimView is the Cocoa embedding view. NvimApi is the API surface, synchronous and asynchronous. Commons holds shared utilities and helpers. Tabs is the tab bar component, Workspace handles workspace management, and Ignore does Gitignore-style pattern matching on top of davvid/wildmatch. Each one is linked from the README as its own tree path, which is the shape of a SwiftPM package rather than a folder inside a single app target.

That split matters for a specific reader. Someone writing their own macOS host for Neovim now has an embeddable view and an API to take, and someone who only wants ignore-pattern matching can take Ignore on its own. The stated reason for the split is more philosophical. The project describes itself as playing around with Neovim, playing around with the main idea of Redux architecture, and having fun, and its first bullet links the author's own Neovim fork. What the README does not hand you is the SwiftPM product name or a version for any of the six, so depending on one from a different project means reading the manifests yourself.

Building from source turns off notarization and plugin validation

Cloning the repository leaves you with two decisions to make. Install `homebrew`, then run these four lines in the project root:

git submodule update --init

xcode-select --install # install the Xcode command line tools, if you haven't already
brew bundle # install dependencies, e.g., build tools for Neovim
clean=true notarize=false trust_plugins=true ./bin/build_vimr.sh

The two flags on the last line are the decisions. `trust_plugins=true` skips the interactive package plugin validation for SwiftLint, which allows the build to proceed in a non-interactive shell. `notarize=false` skips the Apple notarization process and performs an ad-hoc signature instead. The README explains those two and leaves `clean=true` undefined, so a reader guessing at that variable is guessing. Output lands at `./build/Build/Products/Release/VimR.app`. If you would rather not go looking for it, `bin/` holds a second script that builds and overwrites the application in `/Applications`:

./bin/build_and_install_local_release.sh

Overwrite is the word to notice there. It is a developer convenience that replaces whatever is installed.

Releases ship signed Universal binaries, macOS 13 is the floor

Most readers never run that recipe. Pre-built Universal binaries, signed and notarized, are published on the Releases page. The latest is `v0.67.0-20261010.130648` from 2026-10-10, following `v0.66.1-20260920.105849` from 2026-09-20, and the last push is dated 2026-10-10, the same day as that release. Version numbers carry a build timestamp.

The requirement list is short and unforgiving: macOS 13.0 or later to run the app, Xcode 26 to develop it. There is no other platform in the recipe, since the view is an NSView in a Cocoa app and the build asks for Homebrew and the Xcode command line tools. Two files at the top of the tree, `appcast.xml` and `appcast_snapshot.xml`, go unmentioned, and so does the identity behind the released signature. The page says signed and notarized and stops there.

Ligatures off by default, previews that keep their scroll position

The feature list is short, and every item is a Cocoa affordance rather than a Neovim capability. Markdown preview is there, and a generic HTML preview that retains its scroll position when reloading, which is the sort of detail you only get from an editor somebody uses daily. The fuzzy file finder follows Xcode's Open Quickly, trackpad pinching zooms, two fingers scroll, and ligatures are off by default with a switch in the Preferences.

Two of those deserve suspicion from anyone deciding. A file browser that the README writes as (Simple) will not stand in for Finder's column view or a jump-to-file plugin. And a workspace model is only useful if you can find where it lives: no path, no file name, and no format appear in the README. The README's own hedge on the browser is the most honest line in the list.

No user-facing config file and no documented command line

What VimR cannot do, according to the repository, is as informative as the feature list. Everything at the top level is build or development machinery: `.swiftformat`, `.swiftlint.yml`, `Brewfile`, `.gitmodules`, `ci/`, `docs/`, `resources/`, `VimR.xcworkspace/`, and the six package directories. The one user-facing setting named anywhere is ligatures in the Preferences, and Preferences itself is not described.

There is no command line surface either. The command line tool appears as a single bullet with no flags, no subcommands, and no example invocation. The README routes documentation to the wiki at github.com/qvacua/vimr/wiki and development notes to `DEVELOP.md`, so the gaps are meant to be filled somewhere other than in the repository. On Linux or Windows the answer is simply no: the app is a Cocoa shell around an NSView, built with Xcode 26 and Homebrew.

MacVim and Neovide reach the same editor by other routes

The project is candid that it is not the only way to put a window around Neovim on a Mac. Its README asks why VimR exists when other Neovim GUIs for macOS already exist, links the Neovim wiki list of related projects, and answers with three reasons: playing around with Neovim, playing around with the Redux idea, and having fun.

The difference worth weighing is where the engine lives. VimR ships the Neovim binary and its runtime files inside the app and draws them through an NSView, then publishes the view and the API so another Cocoa app can do the same. Support here is informal, a Matrix chat room linked in the README, plus GitHub Sponsors.

Editorial conclusion

Adopt VimR if you write on macOS 13 or later, want a native window, trackpad gestures and previews around Neovim, and are content to run the engine version that ships in the release you download. Skip it if you build on Linux or Windows, or if you need VimR to use your own nvim build. Before the first install, check which Neovim a release carries: the build published on 2026-10-10 is named Universal neovim-v0.12.6-20261010.102856, and the last push was on 2026-10-10.

Frequently asked questions

Official sources

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