Apple container 1.0: por qué los contenedores en Mac siempre serán un apaño (y qué ha hecho Apple para disimularlo)

Qué ha pasado

El 9 de junio de 2026, justo un año después de anunciarlo en la WWDC 2025, Apple publicó la versión 1.0 de container, su herramienta open source para ejecutar contenedores Linux en macOS. Viene acompañada del framework Containerization, escrito en Swift, y es compatible con imágenes OCI estándar: puedes hacer pull de Docker Hub o de cualquier registro de siempre.

El titular que circula es el de costumbre: "Apple mata a Docker". No. Lo que ha hecho Apple es interesante, pero para entender qué aporta de verdad —y qué es marketing— primero hay que tener clara una cosa que mucha gente que usa Docker a diario no tiene del todo asimilada: un contenedor no es una tecnología de Docker, es una funcionalidad del kernel de Linux.

Los contenedores solo son nativos en Linux

En Linux, un contenedor es un proceso normal de tu máquina al que el kernel le pone anteojeras: namespaces para que no vea los demás procesos ni la red del host, cgroups para limitarle CPU y memoria, y un sistema de archivos en capas. No hay virtualización, no hay capa intermedia, no hay traducción. Un ps aux en el host te enseña los procesos de tus contenedores como procesos más.

Por eso Docker en Linux va perfecto y por eso es lo que corre en prácticamente todos los servidores del mundo. El "contenedor" es el kernel haciendo su trabajo; Docker solo es la herramienta cómoda para pedírselo.

El problema llega cuando quieres eso mismo en un Mac. El kernel de macOS (XNU) no tiene namespaces ni cgroups, y además las imágenes de contenedor llevan binarios compilados para Linux: el MySQL de la imagen es un ejecutable Linux, no uno de macOS. Conclusión inevitable: para ejecutar un contenedor Linux en un Mac necesitas un kernel Linux de verdad corriendo en algún sitio. Es decir, una máquina virtual. Siempre. No hay forma de esquivarlo.

Todo lo que sea "Docker en Mac" es, en realidad, una VM Linux disfrazada. Y los comportamientos raros que cualquiera nota la primera semana salen de las costuras de ese disfraz:

• Disco lento: los volúmenes montados (-v ./codigo:/app) cruzan la frontera macOS↔VM con un protocolo de archivos compartidos. Por eso un composer install o un npm install sobre un volumen montado es dolorosamente lento en Mac y normal en Linux.
• Red rara: host.docker.internal, un --network host que no funciona de verdad... porque la red del contenedor vive dentro de la VM, no en tu Mac.
• RAM secuestrada: la VM de Docker Desktop reserva los gigas que le configures y está encendida mientras la app corra, tengas 0 o 20 contenedores levantados.

Qué hace distinto lo de Apple

Aquí está la parte técnica interesante. Docker Desktop resuelve el problema con una única VM Linux grande dentro de la cual corre dockerd, y todos tus contenedores son procesos de esa VM compartiendo su kernel. Es, literalmente, "un VirtualBox con Docker dentro".

Apple ha hecho lo contrario: una micro-VM por contenedor. Cada contenedor arranca su propia máquina virtual ligera con un kernel Linux mínimo y un init diminuto (vminitd, escrito en Swift) que ejecuta el proceso del contenedor directamente, sin ningún daemon de por medio. Cuando el contenedor muere, su VM desaparece con él.

Esto no lo ha inventado Apple. Es el mismo patrón que AWS Firecracker (lo que ejecuta cada función Lambda) y que Kata Containers: micro-VMs tan baratas de levantar que puedes permitirte una por carga de trabajo. La novedad es traerlo de serie al portátil de desarrollo.

Una forma de verlo que nos gusta: en Linux, un contenedor es un proceso disfrazado de máquina. En el Mac de Apple, es una máquina disfrazada de proceso. El usuario percibe algo parecido; la tripa es exactamente la opuesta.

Las promesas, a examen

"Consume menos RAM que Docker Desktop" — verdad a medias

En reposo, sí: cero contenedores = cero VMs = cero RAM, mientras que la VM de Docker Desktop reserva sus gigas solo por existir. Pero cada micro-VM de Apple arranca su propio kernel y recibe por defecto 1 GB asignado, así que con muchos contenedores simultáneos la cuenta se invierte: N kernels pesan más que uno compartido. El ahorro es real para el que levanta un contenedor suelto de vez en cuando; para un compose de ocho servicios, no tanto.

"Aislamiento a nivel de hardware" — frase marketinera, fondo real

En Docker, dos contenedores comparten kernel: un exploit de kernel desde un contenedor compromete a todos los demás, y escapar de namespaces es una clase de vulnerabilidad que aparece todos los años. Con una VM por contenedor, escapar exige romper el hipervisor —las extensiones de virtualización de la CPU, de ahí lo de "hardware"—, una barrera mucho más dura. Es el mismo argumento de venta de Firecracker en AWS. Eso sí: es un argumento de multi-tenancy, no de desarrollo local. Para levantar tu MariaDB de pruebas da exactamente igual.

"Arranca en milisegundos" — cierto, y es lo más conseguido

Kernel mínimo, rootfs mínimo, sin daemon. El arranque de un contenedor es prácticamente indistinguible de lanzarlo en Linux nativo. Aquí Apple ha hecho los deberes.

Lo que sigue siendo peaje

Los volúmenes montados siguen cruzando la frontera macOS↔Linux (virtiofs), así que el acceso a archivos compartidos seguirá siendo más lento que en Linux nativo. Han acolchado el apaño, no lo han eliminado. La física no cambia: en un Mac siempre habrá una VM en medio; en Linux, nunca.

La ironía de la jugada

Tiene su gracia que, después de años de críticas a Docker Desktop por "pesado", la alternativa de Apple arranque una VM entera con su kernel por cada contenedor. Sobre el papel suena más pesado todavía; la apuesta de Apple es que en su silicio las micro-VMs son tan baratas que no se nota.

Pero ojo a qué se criticaba exactamente de Docker. Nadie ha cuestionado el concepto de contenedor —ese lo ha ganado todo: las imágenes OCI son el estándar y Apple lo adopta tal cual, sin formato propio—. Las quejas iban contra Docker Desktop el producto: la VM siempre encendida, el rendimiento de disco, el daemon como root y, sobre todo, el cambio de licencia de 2021, cuando Docker Inc. empezó a cobrar suscripción a las empresas. De ahí salieron Colima, OrbStack, Podman Desktop... y ahora Apple, con su jugada clásica: el estándar ya existe, la implementación dominante tiene fricciones y peaje de licencia, pues lo metemos en el sistema operativo gratis.

Lo que está en juego no es Docker el concepto. Es Docker Desktop el producto.

Limitaciones antes de emocionarse

• Solo Apple Silicon (M1 en adelante). Nada de Intel.
• La 1.0 requiere macOS 26 (Tahoe); en versiones anteriores el soporte es limitado o nulo.
• No hay equivalente pleno de Docker Compose. Para un proyecto con varios servicios enlazados, Docker Desktop u OrbStack siguen siendo más cómodos hoy.
• El ecosistema de tooling (CI, integraciones de IDE, scripts de equipo) sigue girando en torno a Docker.

Qué cambia para ti (probablemente nada en el servidor)

Si administras servidores: nada. Los contenedores en Linux son nativos, ahí no hay nada que arreglar, y el deploy seguirá siendo Docker o Podman sobre Linux como siempre. container de Apple no compite en ese terreno ni lo pretende.

Si desarrollas en un Mac con Apple Silicon: es una alternativa seria a tener Docker Desktop instalado para contenedores sueltos —una base de datos de pruebas, un PHP aislado, un entorno desechable— sin VM permanente comiendo recursos ni licencia de por medio. Se instala con un .pkg desde las releases de GitHub y se arranca con container system start.

Y si el proyecto es un compose de muchos servicios, de momento, quédate donde estás. La 1.0 marca un contrato de API estable, no la paridad de funcionalidades.

Referencias

• apple/container — GitHub
• apple/containerization — GitHub
• Containerization — Apple Open Source
• Apple Containers on macOS: A Technical Comparison With Docker — The New Stack
• Under the hood with Apple's new Containerization framework — Anil Madhavapeddy