2026 Notarization & App Store Upload on Multi-Region Remote Macs
notarytool, Stapler, Transporter Egress & Retry Playbook

About 23 min read · MACCOME

Release engineers and iOS leads who move archives, notarization, and Transporter uploads to remote Macs across Singapore, Japan, Korea, Hong Kong, US East, and US West most often fail on notary queues, keychain context, egress networking, and retry policy, not on “how to code-sign.” This article delivers six release-runbook friction points, a matrix for where to run notarization versus upload, three metrics you can align with on-call, a non-interactive notarytool example plus Stapler preconditions, and a six-step runbook. Read it with the Fastlane and certificate sync, reproducible clean builds, and multi-region rental guide articles—the first two protect signing consistency; this one closes the loop on Apple notary services and App Store Connect egress.

Six reasons notarization and uploads fail “randomly” at night

Apple’s notarization path depends on toolchain versions, available credentials, and TLS quality to Apple endpoints. Remote desktops add screen-lock sessions, proxies, and corporate egress policies. Track the six items below beside your CI retry histograms. If you have not pinned regional roles yet, read the multi-region guide first.

  1. Keychain and session context: Interactive login and non-interactive SSH sessions do not see the same keychain items; automation without explicit unlock or partition flags wastes hours on “works locally, flaky in CI.”
  2. Submit versus poll timing: After notarytool submit returns an ID, you must poll info; aggressive polling under high cross-region RTT amplifies rate-limit perception, while slow polling stretches release windows.
  3. Disk and temp space: Notarization unpacks and repacks artifacts; root volume headroom and temp directory placement can surface as read errors before obvious “disk full” messages—the same family of issues as DerivedData contention in the reproducible-build article.
  4. Stapler preconditions: Paths differ for .pkg, .dmg, and app bundles; skipping steps yields Gatekeeper behavior in QA that diverges from production.
  5. Transporter versus API uploads: The GUI helps manual retries but is harder to audit; API fits pipelines but must align JWT lifetime, issuer ID, and private key paths with Fastlane’s secret governance.
  6. Cross-region “who clicks Ship”: APAC daytime plus US-West night stacks with mismatched on-call timezones shows up as higher failure rates—an organizational issue masquerading as tech noise.

Pair these six with HTTP status distributions, retry counts, and pass rates for the same artifact on different hosts to replace “run it again” with actionable egress and parameter changes.

Matrix: which remote Mac egress should own notarization versus upload

Use the table in procurement reviews: compare who is easier to debug when things fail and which columns map to audit fields, not raw speed. Align peak-machine fields with the budget-governance article where applicable.

DimensionBuild host in the artifact home regionDedicated “release node” for upload and human gates
Network pathGit/registry pulls align with notary egress; fewer duplicate cross-ocean transfersShort, single-purpose path; good for Transporter and manual confirmation
Failure attributionBuild and notary logs share one host contextRequires explicit mapping from artifacts to upstream pipeline IDs
Keychain policyTied to CI users and daemon models; best when long-livedCan use upload-only accounts to reduce exposure; avoid mixing certificate views with signing hosts
Timezone and humansStrong for unattended nightly batchesPrefer regions that overlap on-call hours to reduce “cannot reach desktop” blocks
Disk and 1TB/2TBHolds DerivedData, archives, and notary temp; size for peak weeksMay use smaller disks if cleanup is strict; disk-shaped failures remain common without policy
Rental mixMonthly baseline plus short peaks around releases (per multi-region guide)Short rentals can cover upload spikes without long idle cost

Three metrics to put on the runbook and in YAML

Collect these on internal dashboards; numbers below are illustrative placeholders your team should replace with baselines.

  1. Notary poll interval (NPI): Replace a flat 5s notarytool info loop with exponential backoff (for example 5s→10s→20s, cap 60s) and align max wait with the release window. When cross-region RTT exceeds ~180ms, overly tight polling feels like throttling even when the service is healthy.
  2. Upload recovery window (URW): Track attempts required for Transporter or API uploads with the same artifact and egress IP. If URW climbs while Apple’s status page is green, inspect corporate proxies and MTU before re-signing.
  3. Disk safety margin before stapling (DSM): For volumes where you will run xcrun stapler staple, keep free space ≥2.5× the archive size including temp partitions; otherwise clean caches and archives under the reproducible-build checklist before retrying.

Across 2025–2026 Apple continues to consolidate notarization and upload tooling on the Xcode CLI path; mixing Xcode versions without pinning xcode-select and notarytool versions recreates classic “CI versus desktop drift.”

bash
# Non-interactive notary submit (replace TEAM_ID, secrets, and paths; never commit keys)
xcrun notarytool submit ./dist/MyApp.pkg \
  --apple-id "[email protected]" \
  --password "@keychain:AC_NOTARY_PASSWORD" \
  --team-id "XXXXXXXXXX" \
  --wait

# App Store Connect API key profile (preferred alignment with Fastlane issuer)
# xcrun notarytool store-credentials --keychain "notary-profile" ...
# xcrun notarytool submit ./dist/MyApp.pkg --keychain-profile "notary-profile" --wait
info

Tip: On remote desktops prefer a keychain profile or CI-injected read-only key paths instead of plaintext passwords in shell history; keep rotation cadence aligned with the Fastlane article.

Six-step runbook from signed archive to shippable artifact

Assumes signing and archive already succeed; if not, return to the Fastlane and reproducible-build articles first.

  1. Freeze Xcode and CLI: Record xcode-select -p and xcrun notarytool --version on the target remote Mac in the release ticket to avoid surprise switches on ship day.
  2. Pick egress: Choose build-host versus release-node per the matrix and store IP, region triple, and rental fields on one row with the multi-region template.
  3. Submit and poll: Use non-interactive flags, poll with NPI backoff, download logs before blind retries.
  4. Staple and verify: Run stapler staple where required and spot-check with spctl; log command hashes in the ticket.
  5. Transporter or API upload: Pick one path consistently; for APIs document JWT expiry, private key permissions, and retry policy beside your CI secret table.
  6. Postmortem fields: Log URW, NPI ceiling hits, and DSM triggers quarterly alongside buy-vs-rent and budget articles to decide on short-term peak rentals during release weeks.

M4 versus M4 Pro: IO is often the first bottleneck on the notary path

When telemetry shows slow notary log downloads, jittery temp directories, or faster runs on a local laptop, adding CPU rarely shortens end-to-end time. Return to DSM and cache strategy from the multi-project pool article: prioritize same-region artifact paths, sufficient disk headroom, and stable egress before jumping to M4 Pro for heavier parallel simulators or parallel notary jobs. Remote Macs matter because they turn this chain into contractual regions and rental terms, not because they replace a laptop one-for-one.

Why “it worked once on my laptop” is not a production strategy

Relying on personal laptops for notarization and upload creates hidden cost under compliance reviews, handoffs, and 24×7 release windows: keys live in personal keychains, egress varies with location, and failures do not map cleanly to CI tickets. Moving notarization and upload into a remote Mac pool aligned with regional strategy makes egress, disk, and rental terms auditable and pairs well with long-lived automation such as OpenClaw Gateways in the same region.

Generic cloud desktops or ephemeral VMs can run CLIs but often break graphical session, USB, and keychain semantics, burning coordination time in release weeks. MACCOME offers Mac mini M4 and M4 Pro physical nodes across Singapore, Japan, Korea, Hong Kong, and US coasts with flexible rental terms suited for dedicated build, notarization, and upload egress. Align public rate pages with the matrix row first, then wire NPI, URW, and DSM into your dashboards.

Pilot: keep signing fixed for two weeks, vary only egress and retry parameters on one artifact-home remote Mac—most “mystery failures” collapse to a small set of explainable classes.

FAQ

Should notarization run before or after the Fastlane certificate article?

Stabilize signing and profiles first, then notarize and upload. Keep the Fastlane and certificate sync article open beside rental rates so region and term stay on one row.

How do I pick regions and egress?

Read the multi-region rental guide and record whether build, notary, and upload share a host in your review pack.

Where are billing and access answers?

Visit the Help Center for onboarding and common billing notes.