If you've been poking around Apple's container runtime expecting it to compete with Docker on resource efficiency, the numbers will make you wince. Every single container spins up its own virtual machine consuming somewhere between 270 and 400 megabytes of RAM before your code even runs. Throwaway containers — the kind you'd spin up constantly in a CI pipeline or for temporary workloads — start anywhere from four to ten times slower than their Docker equivalents. That's not a tuning problem. That's a fundamental design choice that, on its face, makes no sense for traditional containerized applications.

The Numbers Don't Lie, But They Might Be Asking the Wrong Question

A developer who ran actual benchmarks found these numbers by measuring Apple's runtime directly rather than trusting marketing. The VM overhead alone is substantial — 270-400 MB per container isn't lightweight isolation, it's full hardware virtualization like running a separate kernel. Volume mounting also appears restricted: named volumes can apparently only attach to one running instance at a time, which breaks a ton of patterns that Docker users take for granted. These constraints would be dealbreakers in most production environments where you're trying to maximize density and minimize cold start latency.

Why Apple Might Not Be Targeting Your Use Case

Here's the reframe nobody's talking about: what if Apple's container system isn't trying to replace Docker at all? AI agents have completely different requirements than microservices. They need strong isolation because they're running untrusted code from external models. They benefit from VM-level security boundaries rather than namespace separation. Persistent state matters more than startup speed for long-running agent instances. And resource consumption is secondary when your primary concern is preventing a rogue agent from accessing files it shouldn't touch.

The Agent-First Architecture Hypothesis

Think about what an AI agent runtime actually needs: guaranteed isolation between agents so one compromised agent can't read another agent's memory or files, reproducible environments for debugging when things go wrong, and security boundaries that survive even kernel exploits. A VM per container delivers all three in ways that traditional container runtimes simply cannot match without additional tooling like gVisor or Kata Containers. Apple's approach bakes in the protection rather than layering it on top.

Key Takeaways

  • Apple containers burn 270-400 MB per instance before your code runs — VM overhead, not lightweight
  • Startup times are 4-10× slower than Docker for ephemeral workloads
  • Volume restrictions (one attachment per named volume) break common patterns
  • The design makes sense if you're building an AI agent platform, not a general app host

The Bottom Line

Apple might be playing a longer game here — betting that the future of compute involves running untrusted AI code safely rather than scaling traditional microservices. If that's the bet, this "inefficient" container design is actually exactly what you'd build. Time to stop comparing it to Docker and start asking who Apple's real target customer actually is.