The platform team opens a migration review, and leadership asks one question: "If we move from GitHub Actions to self-hosted Mac nodes, how much developer efficiency do we actually gain?" — If the answer is "builds got a bit faster," the meeting usually ends without a decision. In 2026 we helped several iOS, Flutter, and React Native teams run controlled before/after experiments. After moving to self-hosted Mac nodes — office Mac minis, bare-metal colo, or Cloud Mac machines running your own runners — the biggest gain was rarely compile time itself. It was queue and idle wait dropping toward zero. Below we answer "how much" with four reproducible metric categories, three real-world benchmark tables, a two-week migration checklist, and a rough ROI formula you can plug your own numbers into.
Quick Answer: How Much Efficiency Do You Gain?
| What you care about | Managed macOS runner (before) | Self-hosted Mac node (after) | Typical improvement |
|---|---|---|---|
| Push to all-green PR checks (end-to-end) | 42–68 minutes | 9–16 minutes | ~70%–80% shorter |
| Queue wait per job | 15–45 minutes | 0–2 minutes | Near zero |
| Single Archive build | 11–14 minutes | 8–11 minutes | ~15%–25% (with cache hits) |
| TestFlight builds per release night | 1–2 builds | 3–5 builds | ~2–3× throughput |
| Passive developer wait per week | 3–6 person-hours | 0.5–1.2 person-hours | ~75% reduction |
In one sentence: the main efficiency gain is waiting, not a faster compiler. Self-hosted nodes pull scarce macOS capacity out of a shared queue, then persistent DerivedData turns those numbers into something repeatable.
If your team already feels the pain during release week — long Slack threads asking "is CI green yet?" — these ranges will look familiar. If queue time is already low, scroll to Case C below before you buy hardware.
What to Measure Before You Talk About "How Much Faster"
Many teams finish a migration and conclude "it did not help much" because they only looked at job duration inside GitHub Actions. They ignored queue time and the hours developers spend waiting in Slack. Capture two weeks of baseline data before you switch, and two weeks after. Track at least four numbers:
- Queue wait: seconds from
job queuedtojob started, reported as P50 and P95 - PR feedback loop: time from the last push to all required checks green
- Release-window throughput: successful TestFlight uploads inside a fixed four-hour window
- Passive waiting hours: sample developers ("how long did you wait on CI today?") or infer from PR comment timestamps
Export options: subtract GitHub API created_at from run_started_at, or add a workflow step that writes queue seconds to an artifact. Migrate without a baseline and you will struggle to justify ROI to anyone who signs purchase orders.
| Metric | How to collect | Signal migration worked |
|---|---|---|
| Queue P95 | Actions API or custom step | Drops from >20 min to <3 min |
| PR feedback P50 | PR event timestamps | Falls by >50% |
| Cache hit rate | DerivedData directory size + build logs | Rises from <20% to >60% |
| Concurrent job failure rate | Share of failed jobs when multiple jobs hit one machine | Below 2% after directory isolation |
Treat queue latency as a first-class SLO, not a footnote. When P95 queue time exceeds compile time, you are paying for shared macOS pool scarcity — not slow code or lazy YAML.
Three Team Benchmarks: Before vs After Migration
All three datasets come from real migration projects (team names anonymized). Conditions were aligned: same repo, same major Xcode version, two-week weekday sampling windows.
Case A: 12-person iOS team, single app plus extensions
Before migration, everything ran on macos-14 managed runners. After migration, two M4 16 GB Cloud Mac machines ran self-hosted runners with DerivedData on a local NVMe path. Average 18 PRs per day.
| Metric | Before | After | Change |
|---|---|---|---|
| PR feedback P50 | 52 minutes | 11 minutes | −79% |
| Queue P95 | 38 minutes | 0.8 minutes | −98% |
| Single Archive build | 12.4 minutes | 9.1 minutes | −27% |
| TestFlight builds per release night | 1.5 | 4 | +167% |
The tech lead's summary: "We used to push at 5 p.m. and learn whether we could merge at 6:30. Now I grab water and the checks are green when I get back."
Case B: 28-person KMP team, Mac builds iOS shell only
Before migration, macOS jobs competed with Android jobs for the same release window. After migration, one always-on M4 Pro plus two burst Cloud Mac machines during release week (see release-week burst playbook).
| Metric | Before | After | Change |
|---|---|---|---|
| Dual-platform PR all-green P50 | 71 minutes | 24 minutes | −66% |
| Total queue hours per release day | 6.2 hours | 0.4 hours | −94% |
| Developer weekly wait (survey average) | 4.8 person-hours | 1.1 person-hours | −77% |
Case B shows that mixed-platform teams feel migration gains even when Mac work is a slice of the pipeline — as long as macOS jobs were the bottleneck during release windows.
Case C: 8-person indie studio, two releases per month
Counterexample: after migration they saw almost no improvement. PR volume was low, queues were already near zero, and self-hosted machines added keychain maintenance overhead. Archive time dropped from 10.2 minutes to 9.4 minutes (−8%). Queue was already ~0. "How much you gain" depends heavily on load shape — do not copy enterprise numbers into a low-frequency workflow.
Where the Gains Come From: Queue, Cache, Concurrency
Split total wait time into components. It makes the story legible to non-engineering stakeholders:
PR total time ≈ queue wait + environment prep + compile/test + artifact upload1. Queue (usually the largest slice): GitHub's managed macOS runners sit in a shared pool. During release weeks or major Xcode upgrade windows, P95 queue times of 30+ minutes are common. A self-hosted node is dedicated capacity — queue entries nearly disappear.
2. Cold start and cache: Managed jobs are destroyed when they finish. DerivedData, CocoaPods, and SwiftPM caches restart from scratch every run. Self-hosted machines mount hot directories on persistent volumes; second builds are often ~20% faster. See the self-hosted runner cache and disk FAQ for directory layout and cleanup rules.
3. Concurrency: Two or three Mac machines can absorb matrix jobs in parallel so release night is not a single-file queue. Run multiple jobs on one host only with per-job directory isolation — random cache collisions will erase your gains.
| Phase | Typical share on managed runners | After self-hosted nodes |
|---|---|---|
| Queue | 45%–70% | <5% |
| Dependency unpack / indexing | 15%–25% | 5%–10% (with persistent cache) |
| Pure compile and test | 20%–35% | 15%–30% |
This breakdown explains why "we shaved four minutes off xcodebuild" can still feel like a transformation when queue time was forty minutes. Leadership cares about calendar time, not compiler microseconds.
Two-Week Migration Path: Benchmark First, Then Shift Traffic
Do not flip production on a Friday evening. A reproducible cadence looks like this:
- Days 1–2: Export two weeks of queue and duration baselines from Actions. Provision one Cloud Mac (~5 minutes), install a runner, use
runs-on: [self-hosted, macos, canary]on manual triggers only - Days 3–5: Persist
~/ci/DerivedDataand SwiftPM cache paths. Run the same main commit A/B five times each; record P50 - Days 6–8: Route 50% of release / nightly workflow traffic to the self-hosted label; keep managed runners as fallback
- Days 9–10: Move all PR required checks to self-hosted; configure 80% disk watermark alerts and artifact cleanup cron
- Days 11–14: Review the comparison table, report ROI upward, decide on one always-on machine vs burst rental by release window
Keep GitHub Actions as the orchestration layer — YAML, permissions, and environment protection rules stay put. You only change runs-on. That matches the "separate orchestration from execution" model in enterprise Mac CI resource pool design.
Minimal workflow change
jobs:
ios-build:
# Before: runs-on: macos-14
runs-on: [self-hosted, macos, ios-pool]
steps:
- uses: actions/checkout@v4
- name: Log queue metrics
run: echo "QUEUE_SEC=${QUEUE_SEC:-0}" >> $GITHUB_STEP_SUMMARYIf you have not decided whether to buy hardware, rent an M4 Cloud Mac by the day for a two-week experiment. Cost is usually lower than one hour of idle waiting multiplied across the team.
During the canary phase, keep managed runners wired as fallback. Nothing kills confidence faster than a Friday outage with no escape hatch.
ROI Sketch: Does Efficiency Math Cover Machine Cost?
Using Case A numbers, here is a formula you can adapt (blended hourly rate at $55 for illustration only):
- 12 developers × 3.7 fewer waiting hours per week ≈ 44 person-hours per month ≈ $2,420/month equivalent output (or fewer merge conflicts from faster PR cycles)
- Two M4 16 GB Cloud Mac machines ≈ $206/month ($103 each — check the pricing page for current rates)
- Part-time platform ops ≈ 4–8 person-hours per month (disk, certificates, runner upgrades)
Rough net benefit stays positive for Case A — but low-frequency builders (Case C) may not break even. Plug your own queue P95 into the formula before you commit:
Monthly benefit ≈ dev count × weekly hours saved × 4 × hourly rate − machine rent − ops hours × hourly rateDuring release week, add a third burst machine and drop it when load normalizes — avoid paying peak capacity all year. Long-term buy-vs-rent TCO is covered in buy Mac mini vs rent Cloud Mac.
Finance teams respond better to "44 hours/month returned to feature work" than "compile is 27% faster." Lead with waiting hours, then show machine cost as a line item.
When Not to Migrate — Avoid Migration for Its Own Sake
In these situations we explicitly recommend holding off, or renting one machine for a single validation week:
- Fewer than ~30 macOS jobs per month and Queue P95 stays under 5 minutes — upside is capped (Case C)
- Nobody can on-call for runner maintenance — a full disk is worse for morale than a short queue
- Compliance requires machines inside your own VPC — solve networking and secrets first, then build the pool
- Expecting to leave GitHub Actions entirely — orchestration, audit trails, and permissions are still worth keeping on the platform
Migration is a means to measurable wait-time reduction. If a two-week experiment cannot show >30% PR feedback improvement, optimize the workflow first — split jobs, reduce Archive frequency — before buying three Mac minis.
FAQ
How much developer efficiency do you gain migrating from GitHub Actions to self-hosted Mac?
High-frequency iOS teams commonly see ~70% shorter PR feedback and queues near zero; pure compile time improves 15%–25%. Low-frequency teams may see single-digit gains — always establish a baseline first.
Is one Mac machine enough?
For teams under ~10 people with serial releases, often yes. Matrix testing or multiple apps in parallel usually needs two machines minimum, plus concurrency limits so jobs do not stomp shared cache.
How much does the Actions bill drop?
macOS minute usage often falls 60%–90% depending on how many jobs you move — but machine rent and ops hours rise. Evaluate total cost with the ROI formula above, not line items in isolation.
Does Cloud Mac differ from an office Mac mini for efficiency?
Same chip and RAM yields similar compile performance. Differences show up in network RTT (dependency pulls, artifact uploads) and whether disk is NVMe. Pick nodes close to your code host and artifact registry.
Does migration affect signing and notarization?
It does not magically fix signing, but stable environments reduce keychain and provisioning profile drift — which cuts down on "only fails in CI" midnight fire drills.
How long until you see improvement?
Once the runner is connected and cache directories are warm, queue metrics move on the first business day. Collect two full weeks of PR feedback data before reporting upward.
Conclusion and Related Reads
Migrating from GitHub Actions to self-hosted Mac nodes is not answered by a vague "much faster." In typical iOS teams, PR feedback shrinks by roughly seventy percent and release throughput doubles — mostly because queues disappear, with persistent cache as the second driver. Run a two-week A/B experiment, track four metric categories, and plug numbers into the ROI formula so leadership gets concrete figures. If the experiment is flat, fix workflow design before you buy machines.