Dat je niet gamet of programmeert op een MacBook is allang achterhaald. Althans, als je vertelt dat je midden in een World of Warcraft-raid zit op een MacBook (en dan ook nog eens een pen tablet als muis gebruikt), zullen er ongetwijfeld wat wenkbrauwen omhooggaan. Je teamleden zullen je de volgende keer waarschijnlijk met lichte argwaan accepteren om weer samen een dungeon te betreden.
Maar tijden veranderen. Niet elke MacBook die opengeklapt staat in een koffietentje wordt nog gebruikt voor grafisch ontwerp of het schrijven van een roman. Geregeld spotten we VS Code op het scherm, met een Mac-gebruiker die geconcentreerd code aan het schrijven is en commits naar GitHub pusht. In 2025 gebruikt iedere doorgewinterde programmeur package managers, want waarom zou je het wiel opnieuw uitvinden, en staat Docker Desktop of Podman geïnstalleerd om te zorgen voor consistente omgevingen. Zo wordt het eeuwenoude probleem “het werkt op mijn machine” eindelijk opgelost.
En toch lijkt er opnieuw iets te verschuiven. Tijdens de laatste WWDC introduceerde Apple een eigen containertool, volledig native geschreven in Swift en geoptimaliseerd voor Apple Silicon. Waar Docker en Podman inmiddels de standaard zijn, komt Apple nu met een alternatief dat belooft sneller, efficiënter en beter geïntegreerd te zijn met het Mac-ecosysteem. Maar het verhaal gaat dieper dan alleen een nieuwe tool.
Wat maakt Apple Containers anders?
Het probleem van containers op macOS zat nooit in Docker zelf. Docker is namelijk vooral een beheertool. Daaronder zitten containerd als de container runtime interface en runc als de laagste uitvoeringslaag. Op Linux draait dat allemaal native omdat de kernel containertechnologie ondersteunt. Op macOS was dat anders: daar moest Docker eerst een Linux VM starten, en pas daarbinnen konden containerd en runc werken.
Apple Containers verandert dit fundamenteel. Voor het eerst ondersteunt de macOS-kernel containerisatie direct, waardoor er geen virtuele Linux-omgeving meer nodig is. Dit betekent dat containers straks echt native op macOS draaien, zonder de overhead van een extra virtuele laag. In feite creëert Apple hiermee het ontbrekende stuk dat Linux al had, maar macOS niet.
Voor developers kan dit enorme snelheidswinst opleveren. Builds en containerstarts zullen veel sneller zijn, minder batterij verbruiken en directer integreren met de rest van het systeem. Docker kan dan bovenop deze native containerlaag gaan werken, net zoals op Linux. Je hoeft dus niet per se Apple Containers te gebruiken als bovenliggende tool, maar je krijgt eindelijk dezelfde fundamentele laag ondersteuning waar Linux al jaren van profiteert.
Belangrijk is ook dat Apple de broncode open op GitHub heeft gezet. Daarmee is het niet alleen een gesloten Apple-ecosysteem, maar een project dat ook voor anderen toegankelijk is. En net als op Linux kun je straks de tooling kiezen die je wilt: Docker, Podman of de native Apple CLI.
Stap jij over?
Dus stel, je zit met je MacBook in een koffietentje. Je hebt VS Code open, je repo’s staan netjes op GitHub en je containers draaien soepel. Zou jij dan overstappen en gebruikmaken van deze nieuwe native ondersteuning? Ga je Docker draaien bovenop Apple Containers, of blijf je bij de oude vertrouwde oplossing in een VM omdat je team dat gewend is?
