- Isolate the signing lane — a dedicated login keychain (or file keychain) for CI plus API key storage beats mixing developer laptops with production notarization.
- Split build vs. attest — keep heavy
xcodebuildon memory-sized runners; parknotarytool submit, polling, andstapler stapleon smaller, storage-aware nodes with stable egress. - Parallelize by queue, not vibes — add a second M4 before you overspend on M4 Pro unless unified memory pressure or disk bandwidth shows up in traces.
Why Treat Notarization as Its Own Rentable Stage?
Linux runners still own most of 2026 CI: containers, linters, and fast unit tests love cheap x86 or ARM VPS fleets. The moment you need Apple code signing, notarytool, ticket stapling, or notarized .pkg distribution, you are back on macOS with hardware-backed identities and Apple’s attestation APIs. Treating that slice as a rentable pipeline—instead of a one-off MacBook login—cuts queue time, reduces credential sprawl, and makes rollbacks predictable when Apple changes gatekeeper rules mid-quarter.
Next step: decompose macOS into build, signing, and upload/staple workers so each tier scales independently. Learn more: storage, parallel roles, and cross-region artifact sync
notarytool, Keychains, and Non-Interactive Runners
Modern teams standardize on notarytool for submission and status polling instead of older altool flows. The operational trick is pairing it with a runner-only keychain that stores distribution certificates and, where allowed, App Store Connect API credentials—never the same keychain your engineers use for iMessage attachments. On rented Macs, run uploads under a service user or a locked-down SSH account, export logs to your central CI sink, and rotate API keys on the same cadence as cloud IAM roles.
-
Unlock once, automate safely — use
securityimport with ACLs that allow/usr/bin/codesignandnotarytoolwithout GUI prompts. - Separate identities — Developer ID for direct distribution vs. Mac App Store certificates should live in different keychain files to prevent accidental cross-signing.
- Watch PATH drift — launchd jobs and SSH sessions often disagree on PATH, which breaks packaged CLIs right when a release tag fires. Learn more: Node LTS, permissions, and PATH drift on remote Mac
From Ticket to Staple: What the Distribution Runner Actually Does
After notarytool submit returns success, Gatekeeper still needs the stapled ticket on disk images and many .pkg installers—especially for offline-first enterprise installs. The distribution stage should download Apple’s log bundle when troubleshooting, run xcrun stapler staple on the final artifact, then publish checksum manifests alongside whatever object storage or CDN front you already use. Keep this stage close to the artifact store so you are not shuffling multi-gigabyte bundles across oceans twice.
JP / KR / HK / SG vs. US West for Upload-Heavy Pipelines
| Concern | Asia-Pacific edge (JP/KR/HK/SG) | US West |
|---|---|---|
| Operator RTT (typical) | Best for APAC HQs | Best for US/EU hybrid teams |
| Large artifact egress | Pair with APAC object storage | Strong when US buckets already anchor truth |
| Follow-the-sun queues | Handoff window overlaps EU morning | Handoff overlaps APAC evening |
| Compliance narrative | Pick the country whose residency story matches revenue | Same rule—document data location per runner |
Parallel Matrix: M4 16GB / 24GB vs. M4 Pro + 1TB / 2TB
Notarization is rarely CPU-saturated; it is sensitive to disk headroom (logs, temporary zip staging) and network stability. Heavy compile farms are the opposite—they hammer unified memory and Xcode indexes. Use the matrix below when you are sizing two runners that can work in parallel instead of one oversized box.
| Runner role | M4 16GB | M4 24GB | M4 Pro + 1TB | M4 Pro + 2TB |
|---|---|---|---|---|
Primary xcodebuild + tests |
1 lane, tight on Simulator + SwiftUI previews | Comfortable dual lane for mid apps | Parallel schemes + large modules | Same as 1TB unless artifacts huge |
| Dedicated notary + staple worker | Enough if SSD < 70% full | Headroom for concurrent DMG jobs | Overkill CPU; useful if co-located with builds | Choose when nightly archives fill 1TB |
| Cost-aware expansion path | Add 2× M4 before first Pro | Split seat vs. queue lanes | Consolidate choked compile graphs | Media / monorepo caches |
Operational Checklist Before You Flip “Production”
Let queue depth drive rentals: when the gap from “archive ready” to “stapled publish” breaches your SLO, parallelize the slow hop—usually upload/staple—not another compile core. Timestamp each stage in CI logs so upgrades map to real wait-time cuts.
-
1
Record
notarytool historyoutput nightly and alert on spikes in rejection reasons. - 2 Mirror Apple’s minimum CLI versions on the runner image so upgrades are deliberate, not accidental Homebrew drift.
- 3 Keep stapled artifacts immutable: write-once object keys with version suffixes beat overwriting “latest” blobs.
FAQ
Run the Pipeline Where macOS Is Native
This workflow depends on tight integration between codesign, Apple’s notary APIs, and stapler-friendly filesystem behavior—something macOS on Apple Silicon delivers without fragile VMs. A Mac mini M4 idles around a few watts yet keeps enough unified memory bandwidth for concurrent compile agents, while Gatekeeper, SIP, and FileVault give you a saner trust boundary than typical Windows build images for high-value signing keys.
That stability means fewer midnight pages and lower TCO than bespoke towers. If you want notarization to feel as boring as unit tests, quiet Apple Silicon is the shortest path—and Mac mini M4 is still the easiest on-ramp to wire once and ship on every release.