LockinRa for macOS

The local-first focus workspace — now on Apple silicon and Intel.

v1.9.0 · Current

Download

Apple silicon (M1–M4) Intel
v1.9.0 · arm64 273 MB · x64 278 MB · not notarized — see below

Not sure which? Apple menu → About This Mac. "Apple M1/M2/M3/M4" means Apple silicon; "Intel" means the other one.

Read this before you open it

This build is not notarized by Apple, so Gatekeeper blocks it the first time. You will see "Apple could not verify LockinRa is free of malware" or "LockinRa can't be opened because Apple cannot check it for malicious software." That message is about a certificate we do not have yet — it is not a finding about the app.

There are three ways past it. The first avoids the warning entirely.

1  Install from the terminal — no warning at all

The quarantine flag that triggers Gatekeeper is attached by whatever does the downloading. Browsers set it; curl does not. Download from a terminal and there is nothing to override, because nothing was ever flagged.

Step 1 · Download the script
curl -fsSL https://lockinra.xyz/install-macos.sh -o install-macos.sh
Step 2 · Read it first
less install-macos.sh
Step 3 · Run it
bash install-macos.sh

It picks the build for your chip, checks it against a SHA-256 published here rather than alongside the download, installs to Applications and verifies the signature. It never asks for sudo. Step 2 reads the script before you run it — please do; you should never run one you have not looked at, from us or anyone. It opens a pager, so press q to leave it; that is why these are three commands to copy rather than one.

2  Already downloaded the .dmg? One command

Drag LockinRa to Applications as usual, then:

xattr -dr com.apple.quarantine /Applications/LockinRa.app

That removes one extended attribute from one app. It does not modify LockinRa, and it does not turn Gatekeeper off for anything else on your Mac. Works on every macOS version.

3  Or use the system dialog

macOS 15 Sequoia and later. Apple removed the right-click → Open shortcut, so instructions telling you to use it — including the ones that used to be on this page — no longer work. The route now is:

  1. Double-click LockinRa, and dismiss the warning.
  2. Open System Settings → Privacy & Security.
  3. Scroll to Security. There is a line reading "LockinRa" was blocked to protect your Mac.
  4. Click Open Anyway and authenticate.

That line only appears after a blocked launch, so step 1 is not optional — this is the part that catches people out. On macOS 14 Sonoma and earlier, the old route still works: right-click the app → Open → Open.

If macOS says the app is damaged rather than unverified, that is a different problem and it is ours, not Apple's — it means the signature broke in the build. From v1.8.0 the release fails rather than shipping a bundle whose signature does not verify, so it should not happen again. If it does, tell us. You can check any copy yourself:

codesign --verify --deep --strict --verbose=2 /Applications/LockinRa.app

What "supported" had to mean first

Porting an Electron app to macOS is mostly free, which is exactly why bad Mac ports are common: the app runs, so it looks finished. The parts that are not free are the ones that touch the operating system directly — and each of these was a real defect, not a missing nicety.

Fixed for the Mac build
  • ⌘C, ⌘V, ⌘X, ⌘Z, ⌘A and ⌘Q. macOS reads keyboard equivalents from the menu bar. LockinRa had removed its application menu — correct on Windows, and on a Mac it means you cannot copy or paste anywhere in the app, including its own text fields.
  • Launching your apps. A .app is a folder, not an executable. Workspaces now hand it to LaunchServices, which is also what gives the app its Dock entry and its environment.
  • Finding your apps. The workspace picker reads your Applications folders instead of returning an empty list.
  • Run at login starts LockinRa hidden in the menu bar, rather than throwing a dashboard at you on every boot.
  • Now playing in the focus mini-player reads Music and Spotify — and never launches a player just to ask it a question.
  • Local AI finds Ollama wherever you installed it: the app bundle, Homebrew on either architecture, or a manual install.
Known limits
  • Window titles need Screen Recording permission. macOS treats another app's window title as screen content. Without it LockinRa still sees which app you are in, so app-level focus detection works and title-aware detection does not. It is asked for once, and refusing it degrades the feature rather than breaking the app.
  • The menu-bar icon is a colour tile, not a monochrome glyph. A template icon keeps only the silhouette, and the LockinRa mark is a filled square — it would render as a black block.
  • Gatekeeper blocks the first launch, because the build is not notarized yet. The terminal install avoids it entirely; otherwise it is one command or one trip to System Settings — see above. On macOS 15 and later, right-click → Open no longer works.
  • No auto-update yet. The .zip that makes updates possible ships from v1.8.0 onward, so a future version is the first that will be able to update itself.

Signing and notarization

The build is ad-hoc signed and not notarized. Ad-hoc signing is what lets it run at all: macOS refuses to execute an unsigned arm64 binary outright, so without it an Apple silicon Mac would report the app as damaged rather than merely untrusted. Notarization is the separate step that would stop Gatekeeper asking, and it requires a paid Apple Developer ID.

v1.8.0 changed how that signature is produced. The packaging tool signs a bundle with --deep, which Apple describes as a repair tool rather than a signing strategy — it chooses its own traversal order and does not reliably reach Mach-O binaries that are not registered as bundle code. Two of ours are exactly that: the SQLite native module the build swaps in for the right Electron ABI, and Electron's own crash handler. A bundle it declares signed could still fail strict verification, on a user's Mac, after everything looked green here. The release now signs every binary itself from the innermost outward, then fails the build if the result does not verify — so a Mac artifact whose signature is broken can no longer reach a download page.

The pipeline is already wired for a Developer ID identity and Apple's notary service, with the hardened runtime on. That last part is not a formality: the hardened runtime blocks the just-in-time compilation that both the browser engine and the on-device speech runtime depend on, so the app declares exactly the exceptions it needs — JIT, the microphone, and permission to ask Music and Spotify what is playing. Nothing broader.

When a certificate exists, the same build comes out signed and notarized and the extra click disappears. Nothing else about the app changes.

System requirements

Windows has an installer, an .msi and a Microsoft Store build. Linux has an AppImage, a deb and an rpm on the Linux page. Every file for every platform, with SHA-256 checksums, is on the downloads page.

← Back to lockinra.xyz