Disclaimer: I work as a Principal Software Engineer at AWS on Amazon Elastic Kubernetes Service (EKS), and Apple is an AWS customer. The following post is solely my own perspective and speculation based on publicly available data, with no internal insight from anyone at Apple into their reasoning.
On June 9, 2025, at Apple’s World Wide Developer Conference (WWDC), they announced new Linux container tooling and a framework for their macOS operating system built in Swift. The developer focused announcement and video, along with a screenshot of docker-like activity of pulling images and running containers, stated the following
The Containerization framework enables developers to create, download, or run Linux container images directly on Mac. It’s built on an open-source framework optimized for Apple silicon and provides secure isolation between container images.
This framework and CLI builds on Apple’s VM framework to create a new VM per container, using a minimal custom init system and container runtime written in Swift to pull and start a container in the Linux VM.
What motives does Apple have to release this?
To get a sense of why a company like Apple would build something like this, we’ll first examine how big of an investment this is. So how much did this cost? Let’s do some napkin math. Apple has hired numerous container developers from Docker, AWS, Intel, Google, and elsewhere over the last 5 years or so. If we conservatively estimate that one of these engineers costs Apple in the range of $750K/yr, and assume there are approximately 10 engineers behind this specific work (based on GitHub commits [1] [2]), thats roughly $8M/yr for 5 years. Assuming there are others involved than the contributors on GitHub, we can use ballpark number of $10M/yr. It might be twice that, but this gives us a baseline.
If we take the announcement and accompanying video at face value, macOS developer experience is the focus of running Linux containers. Would Apple spend millions of dollars per year for half a decade to reimplement an existing developer tool that doesn’t even have full parity with the primary alternative, Docker Desktop? With Docker’s licensing requirements for enterprises (the annual pricing for Docker is $24/mo/seat, assume a 50% enterprise discount, its still $144/year/seat), Apple would only pay Docker ~$1.7M/yr if every one of Apple’s ~12K engineers needed Docker Desktop. In 2022 Amazon launched Finch which is an open-source, free alternative to Docker Desktop’s product. Given the investment size compared to the potential cost, the existence of Finch and other open source alternatives, an in-house alternative to Docker Desktop for Apple’s own developers does not seem like a motivating factor.
Does Apple have a problem with the security model of Docker Desktop/Finch that would lead them to develop custom container tooling? Given that Apple’s new functionality uses virtualization and likely supports most of the same filesystem and network sharing primitives as existing tools, this doesn’t seem to be a significant factor.
Does Apple think there is a strategic risk of developers not using macOS computers? There is a strong long-standing industry-wide preference by developers to use macOS. Developers forgoing macOS for Linux or Windows with WSL does not seem like primary motivation.
From 2002-2011 Apple used to sell a rack-mounted server, Xserve. Given the new paradigm of AI and competition for GPU hardware, could this be an early move by Apple in the direction of providing server hardware, particularly AI focused? Apple is already a the largest buyer of capacity from TSMC on their most advanced fabs, and competes for manufacturing capacity with Nvidia/AMD/Qualcomm. Could Apple be setting the stage for a large strategic shift of selling server hardware too? This is a much larger and more expensive (billions of dollars) strategic decision that would have initiated ripples on rumor sites and generated other industry chatter. Given Apple’s proclivity for high margin businesses (iPhone, 50-60%, company-wide ~26%), if they could approach Nvidia’s overall 42% on server hardware, it could be an attractive option, but at this point seems unlikely due to lack of other evidence.
Is there a server-side use case on existing Apple hardware for this? While AWS does enable customers to run macOS instances, the most recent instances available are limited to M2 Pro Mac Minis, which were released in January 2023. There are no Mac Pro, or Mac Studio instances available on AWS with the last two years worth of advances in chip design. At present and without any additional information, it is hard to imagine this announcement being geared toward public server-side use cases. Given the cost of Apple hardware it would be prohibitively expensive to run software written and compiled for Linux virtualized on a Mac for general purpose compute uses.
Could Apple have an internal server side use case? Last year at WWDC they announced their Private Cloud Compute (PCC) in which they discussed running LLM inference on custom hardware:
The root of trust for Private Cloud Compute is our compute node: custom-built server hardware that brings the power and security of Apple silicon to the data center, with the same hardware security technologies used in iPhone, including the Secure Enclave and Secure Boot. We paired this hardware with a new operating system: a hardened subset of the foundations of iOS and macOS tailored to support Large Language Model (LLM) inference workloads while presenting an extremely narrow attack surface. This allows us to take advantage of iOS security technologies such as Code Signing and sandboxing.
Even with a custom OS on custom hardware, for performance it seems difficult to justify running server software on virtualized Linux in such a trusted and hardened environment.
As referenced above, Apple has spent almost two decades adding security and isolation features to the shared kernel used by iOS and macOS. In the constant cat-and-mouse dynamic with groups like Pegasus maker NSO or Cellebrite (notoriously used by government agencies like the FBI in 2015), Apple has consistently been hardening and reducing the capabilities of code running on their systems. Most of these capability limits are geared toward mitigating the threats faced in a single user-system (iOS/macOS) with a moderately trusted App Store, which have some overlap, but also differ from server-side use cases.
With full respect for what the engineers at Apple have built, they have not released anything technically innovative at this point. This is largely a rewrite of functionality provided by existing technologies like runc and containerd (both written in Go) in Apple’s Swift programming language.
It would be premature to read too much into the structure of the code released on GitHub and make conclusions about the direction Apple will go, but it seems plausible given the wording in the documentation that they’ve left the door open for macOS-native containers.
Many operating systems support containers, but the most commonly encountered containers are those that run on the Linux operating system.
From the Technical Overview
While its true that Microsoft Windows also supports containers, there really aren’t other options out there.
@Option(name: .long, help: ArgumentHelp("set the build os", valueName: "value"))
var os: [String] = {
["linux"]
}()
Parameterized option with a single value for an Operating System selection in the build command
If you don’t write code, a standard principle is that you don’t provide unnecessary options to users. By explicitly coding an Operating System option with only one viable choice of “linux”, it would seem to indicate they’re leaving the door open to other OS’s in the future.
In Linux, containers on a single machine typically do not require orchestration, but when managing software across multiple machines, Apple has talked frequently at industry conferences about their use of Kubernetes for orchestrating server deployments. Could Apple be working on a macOS-native container solution compatible with Kubernetes? It is an intriguing possibility. There is significant body of other work they’ll have to complete to support protocols like the Container Runtime Interface (CRI) used by Kubernetes to manage workloads that are virtualized.
What use case would Apple have for native macOS containers with orchestration? Based on the public statements they’ve made about PCC, it would seem like AI inference on custom hardware would be compelling enough to make the investment of the size we’ve seen. It is entirely possible that such work may forever remain internal to Apple’s data centers and never make it out into external products. (Although I’m sure hobbyists like Georgi Gerganov would love to make use of clustering features for AI inferencing on consumer hardware). If I had to guess, I wouldn’t expect any public annoucement around macOS containers before WWDC 2026, if they make an announcement at all.
While Apple has a motivation to provide a good developer experience on macOS, the only conclusion I can draw without more data is that Apple still has some other unknown motivation, potentially a macOS-native container feature, to justify an investment in the Linux container features launched this week.