The local-first focus workspace — now on Apple silicon and Intel.
v1.9.0 · CurrentNot sure which? Apple menu → About This Mac. "Apple M1/M2/M3/M4" means Apple silicon; "Intel" means the other one.
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.
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.
curl -fsSL https://lockinra.xyz/install-macos.sh -o install-macos.sh
less install-macos.sh
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.
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.
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:
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
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.
.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..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.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.
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.