Cloud Mac 16GB or 24GB for long-term development?

16GB can work for one repo, one simulator, occasional AI tools; with indexing always on, 2+ simulators, and Cursor/Claude Code together, 24GB swaps less and fits 4–12 week locked environments.

How much do clean builds differ between 16GB and 24GB?

Clean builds are CPU-bound—often only a few percent apart. Gaps show up on incremental builds with SourceKit, simulators, and AI tools resident together.

Can I upgrade to 24GB mid-lease?

Dedicated tiers usually mean migrating to a new instance: certs, DerivedData policy, runner labels. If you expect AI agents, start at 24GB.

CI-only without GUI—is 16GB enough?

Often yes for one pipeline and one simulator; parallel jobs or sim matrices still want 24GB or split runners.

Cloud Mac 16GB と 24GB の実測：Xcode ビルド、シミュレータ複数起動、AI コーディング—長期開発向けはどちら？

TL;DR · 3行

16GBは単一リポジトリ・Simulator 1台・SSH 中心の Xcode 向け。メモリ圧力が黄になると増分ビルドと索引が遅れる
24GBは Xcode + Simulator 2～3 + AI 索引/Agent 同時時の swap と UI カクつきを抑え、長期クラウド開発のデフォルト
長期契約は月額差だけ見ない：16GB の節約は clean build・Simulator 終了・ swap 待ちで消える。AI 時代は 24GB + 512GB から

Cloud Mac では CPU よりメモリ構成の変更が租期中に効きにくい。同一リージョン・同一 Xcode 16.x イメージの Mac mini M4 専用クラウドホスト 2台（16GB/256GB と 24GB/512GB）で、Xcode ビルド・Simulator 複数・AI コーディング負荷を再現可能な脚本で計測した。長期開発なら 16GB と 24GB のどちらを固定するかが問いだ。

Load types: compile · simulators · AI toolchain

2×

Pair: M4 16GB vs M4 24GB (same image)

DerivedData kept—realistic long dev

実測方法とサンプル工程

We used three anonymized repo profiles:

Tier A: single-module SwiftUI app, moderate CocoaPods, ~80k Swift LOC equivalent
Tier B: multi-target workspace (app + extension + widget), SwiftPM + Pods, ~250k LOC equivalent
Tier C: iOS host with React Native / Flutter shell, ~150k native LOC plus Node tooling

Same conditions: no extra user sessions; local SSD DerivedData; gigabit in-region network; three runs median. We tracked memory pressure and memory_pressure events; build time from xcodebuild wall clock.

Region, tenure, and parallel splits: Mac cloud host 16/24GB handbook; CI: CI/CD FAQ.

Xcode: clean vs incremental builds

Clean builds (DerivedData wiped, xcodebuild -scheme Release clean build) are CPU-bound; 16GB vs 24GB medians on tier B differ ~4–7%—within noise.

Gap widens with incremental builds while indexing runs (Xcode GUI open, SourceKit busy):

Project	16GB incremental median	24GB incremental median	16GB swap?
Tier A	42s	38s	Occasional at index peak
Tier B	3m 12s	2m 28s	3/3 runs
Tier C	4m 05s	3m 06s	3/3; Node daemons worsen it

16GB can compile, but compile + index + other residents raises tail latency. Dozens of incremental builds per day often exceed the RAM tier price delta.

Xcode and Swift on screen—Cloud Mac M4 16GB vs 24GB compile and index testing

Simulator fan-out and memory pressure

We launched iPhone 16 / iPad Pro simulators and UI tests, recording stable parallel count before red pressure:

16GB: tier B—one simulator + Xcode is OK; second sim yellows pressure; third always swaps
24GB: 2–3 simulators stable on the same project; fourth wobbles on tier C

One sim for debug + one for UI tests can squeeze into 16GB; multi-size screenshot farms (common in RN/Flutter) treat 24GB as the interactive cloud desktop baseline. TestFlight flow: TestFlight FAQ.

AI coding: index, agents, parallel work

Same overlay on both machines:

Xcode with tier B workspace
Cursor on the same repo (index on)
Claude Code in tmux (~45m scripted refactor + test session)

16GB: yellow pressure by ~15m; clear swap ~25m; swift test tail latency doubled; agent child processes compressed.
24GB: mostly green–yellow; one swap spike; Xcode and agent stayed responsive.

Matches Mac execution nodes: models on API, marathons on Mac. OpenClaw Gateway: split instances—multi-agent FAQ.

30-second self-check

memory_pressure 2>/dev/null || true
vm_stat | head -5
ps -axo rss,comm | sort -nr | head -8
# Rising swap + indexing → 24GB for long-term dev

Long-term dev: which tier to lock?

“Long-term” = 4–12 weeks on one environment: DerivedData, Keychain certs, runner config, AI caches.

16GB: solo indie, single scheme, device-heavy, light sims, occasional AI—OK if you close sims at peaks
24GB: shared team box, monorepo, parallel sims, always-on Claude Code/Cursor, runner + GUI—our default long-term tier

16GB tiers often ship 256GB SSD; 24GB tiers start 512GB—better match for not wiping DerivedData weekly. If 256GB is tight, add 1TB or a second build box instead of living in swap.

Matrix and combo advice

Scenario	RAM	Notes
SSH compile, minimal GUI	16GB	`tmux` + nightly batches
VNC daily + one sim	16–24GB	16GB needs discipline; 24GB calmer
AI agent marathon + Xcode	24GB	Claude coding agent stack
Multi-sim UI batches	24GB or 2nd machine	Parallel resources

FAQ

Can I upgrade 16GB → 24GB mid-lease?

Usually a new instance: migrate certs, repos, DerivedData policy, runner labels. If you expect AI tools, start at 24GB.

Wait for M4 Pro?

For most app teams M4 CPU is enough; bottlenecks are RAM and disk. Pro fits heavy video or huge parallel compile farms.

CI-only, no GUI—16GB enough?

Often yes for one pipeline and one sim; parallel jobs or sim matrices still want 24GB or split runners.

Conclusion

Clean builds barely separate the tiers; index + simulators + AI tools make 16GB pay swap tax daily. For stable delivery on a Cloud Mac in 2026, treat M4 24GB / 512GB as the default; reserve 16GB for predictable, solo light stacks.