Developer settings
Hidden tools for installing past releases and bisecting regressions
The Developer settings panel is a hidden tab in Settings that lets you install an arbitrary past release of nixmac. It's intended for bisecting regressions — most users will never need it.
Enabling the panel
The panel is hidden by default. To turn it on:
- Open Settings → General.
- At the bottom of the panel, tap the version number seven times.
- After the seventh tap, a Developer item appears in the Settings sidebar.
You can disable the panel from inside Developer (or from the version row in General) — once off, the sidebar item disappears.
Installing a past release
Inside the Developer panel:
- Enter a version that exists as a published release — for example
0.21.0. Look atgit tagin darkmatter/nixmac for valid values. No leadingv. - Click Install.
What happens under the hood:
- The signed bundle is downloaded from
releases.nixmac.com/<version>/nixmac.app.tar.gz. - The minisign signature is verified with the public key embedded in the production release.
- The current
.appbundle is atomically replaced with the requested version. - nixmac relaunches into the freshly-installed bundle.
This is the same code path the production auto-updater uses, so signing and bundle-swap behavior match exactly.
Pinning behavior
While a version is pinned, the silent update check on launch is suppressed — nixmac will not auto-jump back to the latest release while you bisect. The panel shows the active pin and a Resume auto-update button to clear it.
Click Resume auto-update to allow the auto-updater to move you back to latest at the next launch.
Limitations
- Apple Silicon only. Past Intel-Mac bundles are not published.
- Release builds only. A locally-built debug binary returns a clear error from the install command, because the auto-updater plugin isn't registered in development mode.
- No version listing. You enter the version manually; there's no in-app browser of historical releases.
Why this exists
When a regression slips into a release — for example, a TCC permission change that breaks darwin-rebuild — the fastest way to find the bad commit is to walk back through past releases in the working app and observe which one the bug started in. This panel makes that walk a one-click operation rather than a manual download / verify / replace dance.
If you're not actively bisecting, leave the panel disabled.