Als je het nieuwe containersysteem van Apple afzet tegen Docker, lijkt het kapot. Elke instantie verbruikt 270 tot 400 MB RAM voordat hij iets nuttigs doet. De opstarttijd is vier tot tien keer langzamer dan die van een Linux-container. Probeer een volume te delen tussen meerdere containers en je loopt tegen een harde muur aan: één koppeling, één box. Voor iedereen die op zoek is naar een lichtere manier om microservices te draaien, voelen deze cijfers als dealbreakers.
Maar Apple bouwt geen vervanging voor je dev-stack. Het bouwt een gevangenis voor code die je niet kunt vertrouwen.
Die ene verschuiving in perspectief verandert elke klacht in een bewuste afweging.
De verkeerde benchmark
Onze sector heeft het afgelopen decennium gewerkt aan het maximaliseren van de dichtheid van containers. We wilden tientallen apps die op één kernel draaien, geheugenpagina's delen, dezelfde volumes mounten en in milliseconden opstarten. Docker loste dat probleem briljant op. Het hele doel was om de abstractie tussen software en hardware zo dun mogelijk te maken.
Het ontwerp van Apple werkt andersom. Het offert dichtheid op voor scheiding. Het ruilt gedeelde resources in voor rigide muren. Als je het bekijkt als infrastructuur voor een Kubernetes-cluster, is de rekensom absurd. Je zou nooit een vloot van nodes samenstellen waarbij elke container een kwart gigabyte aan overhead en een eigen kernel met zich meedraagt. De economie werkt simpelweg niet.
Tenzij de workload een AI-agent is die je zojuist op je laptop hebt uitgenodigd.
De huurder is veranderd
In 2026 is de gevaarlijkste code die op je machine draait geen vergiftigd npm-pakket of een louche browser-extensie. Het is de autonome programmeeragent. Deze tools lezen je codebase, herschrijven functies, voeren shell-commando's uit en roepen externe API's aan. Ze nemen duizenden beslissingen per minuut binnen dezelfde mappenstructuur waar je SSH-keys, omgevingsbestanden en browsercookies staan.
Traditionele machtigingsmodellen storten in onder die snelheid. Je kunt niet verwachten dat een mens elke bestandslas, elke subprocess-start en elke netwerkverzoek goedkeurt. Die goedkeuringsketen verandert een refactoring-klusje van vijf minuten in een uur lang oppassen. Toch is een agent onbeperkte toegang geven tot je home-directory niet veel veiliger dan je laptop aan een vreemde geven.
Het enige verstandige vertrekpunt is om de agent standaard als vijandig te beschouwen, en veiligheid vervolgens te bewijzen door middel van structuur in plaats van hoop.
Het containersysteem van Apple is ontworpen met precies die mindset in het achterhoofd.
Wanneer isolatie het doel wordt
Elke Apple-container draait in zijn eigen lichtgewicht VM met een eigen kernel. In de Docker-wereld is dat ketterij. Je verliest geheugendeduplicatie. Je verliest de snelheid van een gedeelde kernel. Je verliest het vermogen om honderden workloads op een enkele host te plaatsen.
Voor één onbetrouwbare agent is een privé-kernel echter een fort. Als de agent uit zijn user space ontsnapt, botst hij nog steeds tegen een grens aan die niet jouw host-kernel is. Dat is geen verspilling. Dat is de feature waar je voor betaalt met die extra megabytes.
Apple breidt deze grens uit via mcpbridge. Veel programmeeragenten communiceren met tools via het Model Context Protocol, of MCP. Apple onderschept die commando's en vertaalt ze naar XPC, hetzelfde cross-process framework dat fijnmazige machtigingen afdwingt op macOS en iOS. De agent kan niet zomaar in je bestandssysteem of netwerk snuffelen. Elke tool-aanroep moet eerst door het strikte machtigingsmodel van Apple.
Dan is er nog de splitsing in rekenkracht. De zware AI-modellen zelf blijven op de host Mac draaien, op de Neural Engine. De container verspilt geen RAM aan modelgewichten of inference engines. Het huisvest alleen de tools en de tijdelijke opslag van de agent. Het dure werk gebeurt waar de hardware het sterkst is; het risicovolle werk gebeurt in de kooi.
Deze architectuur weerspiegelt de filosofie achter Apple's Private Cloud Compute-initiatief. Vraag de gebruiker niet om je blindelings te vertrouwen. Bewijs de grens met de structuur van het systeem zelf.