QuartzControl ships as a finished program. It lives on the project’s releases page, which carries one file per system for every version.
Which form belongs to which system
| System | Form | Note |
|---|---|---|
| macOS, Apple Silicon | .dmg or .zip | drag QuartzControl into “Applications” |
| macOS, Intel | .dmg or .zip | same build, different architecture |
| Linux, x86_64 | AppImage or .deb | make the AppImage executable, or install the deb |
| Linux, arm64 | AppImage or .deb | likewise |
| Linux, Flatpak | .flatpak | x86_64 and aarch64 — see below |
The file name states the architecture, x64 included.
macOS refuses the first launch
QuartzControl is only ad-hoc signed and not notarised — a signature Apple recognises and notarisation would both need a Developer ID certificate. Gatekeeper, macOS’ launch check, therefore refuses the first start, saying Apple cannot verify QuartzControl. Two ways around it:
Allow it in System Settings
Launch it once and close the message. Then go to System Settings → Privacy & Security, click Open Anyway in the Security section and confirm with your login password. The button stays there for about an hour after the refused launch. This is the way without a terminal; the context menu (right-click → Open) stopped being one in macOS 15.
The second way removes the quarantine flag macOS attaches to downloaded files:
xattr -dr com.apple.quarantine /Applications/QuartzControl.app
Both apply to the finished packages and to a build of your own alike.
Linux
An AppImage has to be made executable (chmod +x), then it runs. A deb installs like any
other package.
The Flatpak runs in a sandbox and is allowed into the user’s home by default — which is where
projects and vaults live. If a content folder points
via a link to another drive, the sandbox cannot see it; that
needs a one-off flatpak override --filesystem=… for the path.
Why the Flatpak is built twice
It is the one Linux target that cannot be cross-built: its builder needs the runtime, SDK and BaseApp of the target architecture and compiles git from source. AppImage and deb come off one machine for both architectures; the Flatpak needs one machine each — an x86_64 Flatpak only comes off an x86_64 machine, an aarch64 Flatpak only off an aarch64 one.
Updating
QuartzControl does not update itself. A new version is downloaded and put over the old one — into “Applications” on macOS, as a new AppImage or package on Linux.
That is a deliberate omission rather than a gap still to be filled: self-updating would have to verify packages signed with a certificate, and there is no such certificate here.
It does tell you, though. When a newer version exists, a line at the very top of the start page names the new number next to your own and links to it (2.1). It downloads nothing and changes nothing — it points. Downloading and replacing stay manual; the section above describes how.
Three things all called “update”
The notice at the top of the start page is about the program. Under 7.3 – Updates, by contrast, QuartzControl checks whether there is anything new for the Quartz core and for a project’s plugins — that concerns the website. Neither replaces anything by itself: the program not at all, the core and plugins at the press of a button.
On macOS: “Always Allow”, twice
On the first access to stored credentials after every update, macOS asks again whether this version may use the Keychain — usually twice in a row, because QuartzControl is not signed with a developer certificate. Answer Always Allow both times. If you deny it, QuartzControl tells you so, and after a restart the question comes back.
The projects stay where they are. They do not belong to QuartzControl, and a new version finds them again through the same list — where that lives is under 8.3 – Where the data lives.