The macOS client
What Abliteration on macOS is: a native ARM64 build for Apple Silicon (with a Universal path on Intel), signed by Catyonic OU and notarized by Apple, using Metal for two to five times CPU throughput on M-series chips.
Short answer
The macOS client is a native Mac app for both Apple Silicon (M1, M2, M3, M4) and Intel Macs. It is signed by Catyonic OU and notarized by Apple, so it opens on first launch without any Gatekeeper warning. On Apple Silicon it uses Metal automatically for inference, which is two to five times faster than the CPU path a Windows machine would take on the same model. It ships as a sandboxed bundle with its data under ~/Library/Containers/, registers the abliteration:// URL scheme through the standard macOS mechanism, and speaks to abliteration.org through the same local HTTP bridge on 127.0.0.1:47821 that the Windows client uses.
Detailed explanation
A native Mac app. The macOS client is a real Cocoa app, not a Windows port running through a compatibility layer. Its window uses standard macOS chrome, its keyboard shortcuts follow Mac conventions (Cmd, not Ctrl), it lives in the Applications folder like any other Mac app, and it participates in macOS-level features (universal Cmd+Q, quarantine, Launch Services) the way macOS expects apps to.
Apple Silicon and Intel. The download is a single build that runs natively on both Apple Silicon and Intel Macs. On Apple Silicon the app runs as ARM64 code on the chip’s own cores, with no Rosetta involved. On Intel Macs it runs as x86_64 code on the CPU cores. The behaviour is identical either way; the performance is not, and this is what Metal changes.
Metal on Apple Silicon. Apple Silicon chips share one pool of RAM between the CPU cores and the GPU cores on the same die. That “unified memory” architecture means a model loaded into memory is instantly available to Metal, Apple’s low-level compute API, without the copy step a discrete GPU would need. The app turns Metal on by default whenever it detects an M-series chip, and inference offloads to the GPU cores. Same model, same quantization: a 7B Q4 file that reads at eight to twelve tokens per second on the CPU cores of an M1 Air reads at thirty to forty with Metal on. There is a Settings > Hardware toggle if you ever want to compare, but you should leave it on. Intel Macs stay on the CPU path by default; the AMD GPUs shipped in those machines can technically run Metal but the memory-model difference makes the gain much smaller. See Apple Silicon acceleration and Slow generation on an older Intel Mac.
Signed and notarized. Every macOS release is signed with a Developer ID certificate issued to Catyonic OU, and every release is submitted to Apple’s notary service before it goes on the download page. That combination is what lets macOS open the app without the “unidentified developer” wall. The first time you open a fresh copy, macOS may show a brief “Apple checked it for malicious software and none was detected” confirmation; that is standard notarized-app behaviour, and it does not recur.
Sandboxed on disk. The Mac build is a sandboxed app, so its writable area sits under ~/Library/Containers/org.abliteration.models/Data/Library/Application Support/Abliteration/. Models, chats, attachments, and settings all live there. The sandbox keeps everything Abliteration writes isolated from other apps, and a fresh install of a new version does not touch the container, so updates preserve your library and your settings by design. See Where Abliteration keeps your data.
Bridge only from Applications. The local HTTP bridge at 127.0.0.1:47821 is subject to the macOS sandbox, and the sandbox allows the loopback listener only once the app is running from /Applications. Launched from outside Applications, the bridge does not start and the catalog on abliteration.org sees no signal. This is a characteristic of the Mac sandbox, not a bug, and once the app is in Applications it stays cleared for every subsequent launch. See The site says “install the app” even though I have the app on macOS.
Deep links. The abliteration:// URL scheme is registered through the app bundle’s Info.plist, which Launch Services picks up the first time the app is launched from Applications. Clicking an “Open in app” link on the catalog from any Mac browser routes the URL into the running instance, or launches the app if it is closed. The legacy infrahuman:// scheme is registered too. See Deep links.
Updates. Copies installed from the Mac App Store update themselves silently in the background whenever a new release ships, usually within a day of a release passing Apple’s review; the next time you open the app it is already the new version. Copies installed from the direct .dmg on the site are a manual swap: a fresh download replaces the old app in place, and because your data lives in the container it survives the swap untouched. A built-in “Update available” prompt for the direct .dmg channel is on the near-term roadmap; until it ships, Mac App Store is the simplest path to silent background updates on macOS. See Updates - how new versions arrive.
Menu bar behaviour. Closing the window sends Abliteration to the menu bar - a small sphinx silhouette next to the battery, Wi-Fi and system icons. The main window disappears, the app keeps running, and the local HTTP bridge keeps answering requests. Click the sphinx to see the bridge status, the currently loaded model, and to reopen the window, start a new chat, or Quit. Only Quit (⌘Q) actually terminates the app. See Menu bar and tray for the full menu.
Themes. The app follows the macOS light or dark appearance automatically, including the Auto setting that tracks sunrise and sunset. See Switching light and dark theme.
Why it matters
For local models, “runs on the Mac” is not enough. The Mac client is built for the two things that make a Mac worth choosing for this work: the unified-memory architecture that Metal turns into real inference speedups, and the standard notarized-bundle contract that means installing a new tool takes a few seconds and asks nothing of you. Everything else, chats, deep links, hardware detection, the bridge, is the same program the Windows client runs, on a schedule that is catching up.
In Abliteration specifically
The performance you should expect on an M-series Mac is closer to a dedicated NVIDIA workstation than to a same-year Intel MacBook Pro. A base-spec M1 Air with 16 GB of RAM comfortably outruns a top-spec 2019 Intel MacBook Pro with 32 GB on the same 7B model, because Metal on unified memory does what a CPU cannot. If you have both machines to hand, put the same file on each and watch the tokens-per-second reading during a response, that number is the whole story.
The bridge does not know whether the visitor came from Windows or the Mac; it answers the same JSON. The catalog on abliteration.org treats both clients the same way, and the “CONNECTED” plate turns green from either.
Related
- The Windows client - the same program, the differences that matter
- System requirements - what the Mac needs to run this
- Apple Silicon acceleration - what Metal is doing on M-series chips
- Slow generation on an older Intel Mac - honest expectations for pre-2020 Intel Macs
- Menu bar and tray - how Abliteration lives in the menu bar and keeps the bridge running
- Where Abliteration keeps your data - the sandboxed container path
- The site says “install the app” even though I have the app on macOS - why the bridge needs the Applications folder
- Deep links - the
abliteration://URL scheme on Launch Services - Updates - manual today, in-app soon