A Apple lançou a versão 1.0 do container, sua ferramenta open source para rodar containers Linux nativamente no Mac com Apple Silicon. Anunciada na WWDC 2025, ela chegou ao 1.0.0 em 9 de junho de 2026, sob licença Apache 2.0. Na prática, é uma alternativa nativa ao Docker no Mac — escrita em Swift e afinada para o hardware da Apple.
Como esse assunto circulou com algumas confusões, vale deixar claro desde já o que a ferramenta é (e o que ela não é), como funciona por baixo e como usar hoje — com os comandos reais.
O que é o Apple container
O container é uma ferramenta de linha de comando (CLI) que cria e executa containers Linux em máquinas virtuais leves no Mac. Ele consome e produz imagens compatíveis com OCI, então dá para puxar e enviar imagens de qualquer registry padrão (as mesmas do Docker). Por baixo, ele usa o pacote Swift Containerization para gerenciar containers, imagens e processos — e é esse framework que você usaria caso queira construir suas próprias ferramentas.
Como funciona por baixo
Aqui está o diferencial técnico: em vez de um único daemon gigante rodando tudo, cada container ganha a sua própria micro-VM dedicada, criada pelo framework de Virtualization do macOS — que o Apple Silicon inicia e encerra muito rápido. Cada VM sobe um kernel otimizado (baseado no Kata Containers) com um init mínimo escrito em Swift (o vminitd) em menos de um segundo.
O resultado é forte isolamento (uma VM por container) com peso baixo de memória e CPU, tudo alinhado à arquitetura do Mac — sem camadas de tradução nem uma VM única e pesada compartilhada.
Importante: é para containers Linux (não para "buildar iOS")
Circulou muita empolgação dizendo que o container serviria para criar “ambientes reproduzíveis de build de iOS” ou “testar componentes SwiftUI isolados”. Isso não é o caso: a ferramenta roda containers Linux. Você não compila nem executa apps iOS dentro dela (isso continua exigindo macOS + Xcode). O valor real está em outro lugar:
- Serviços locais de backend: subir Postgres, Redis, MySQL, filas e afins para desenvolver e testar, sem instalar tudo na máquina.
- Swift on Server: empacotar e rodar apps Vapor/Hummingbird em Linux, do jeito nativo da Apple — e o mesmo container que roda local vai para produção.
- Ambientes de dev reproduzíveis e CI: as mesmas imagens Linux entre a sua máquina e o pipeline.
Mão na massa
Requisitos: Mac com Apple Silicon e macOS 26 (Tahoe) ou superior (a ferramenta depende de recursos novos de virtualização e rede dessa versão). A instalação é via instalador assinado das releases no GitHub; depois, sobe o serviço:
# inicia o serviço do container
container system start
# roda uma imagem Linux (puxa de um registry padrão)
container run -it --rm docker.io/library/postgres:17
# lista containers e imagens
container ls -a
container image listConstruir uma imagem a partir de um Dockerfile e publicá-la em um registry segue o fluxo que você já conhece — só muda o binário:
# build a partir de um Dockerfile
container build --tag web-test --file Dockerfile .
# sobe em background e executa comandos dentro do container
container run --name my-web-server --detach --rm web-test
container exec --tty --interactive my-web-server sh
# publica em um registry
container registry login some-registry.example.com
container image tag web-test some-registry.example.com/fido/web-test:latest
container image push some-registry.example.com/fido/web-test:latest
# encerra
container stop my-web-server
container system stopSe preferir programar em vez de usar o CLI, o pacote Swift Containerization expõe as mesmas capacidades de baixo nível para você embutir em suas próprias ferramentas.
Por que isso importa para quem vive no ecossistema Apple
Rodar containers no Mac sempre foi “funciona, mas com imposto”: uma VM única e pesada, um daemon consumindo recursos, camadas de tradução. O container inverte isso ao ser nativo do Apple Silicon, leve e com isolamento por VM — e ao ser open source, dá para inspecionar, contribuir e construir em cima. Para quem faz Swift on Server, é a primeira via realmente “primeira-classe” da Apple para empacotar e entregar apps Swift em Linux.
Pontos de atenção
- Só Apple Silicon + macOS 26. Não roda em Intel nem em versões antigas do macOS — ele depende dos recursos novos de virtualização/rede do Tahoe.
- É Linux, não iOS. Não substitui Xcode nem “conteineriza” builds de app iOS; pense nele para serviços e Swift server.
- A “API container.swift / ContainerKit” que circula é imprecisa. Não existe um manifesto container.swift com ContainerEnvironment como padrão de uso — o real é o CLI (com Dockerfile) mais o framework Containerization para quem quer código. Desconfie de exemplos que apresentam essa DSL como oficial.
- 1.0 é o começo. O ecossistema (imagens, docs, ferramentas em volta) ainda está se formando; espere evolução rápida.
Conclusão
O container 1.0 não vai mudar “como você constrói apps iOS”, como alguns títulos sugeriram — mas muda, e bastante, como você roda serviços e Swift server no Mac. É a Apple trazendo para o Apple Silicon a reprodutibilidade e o isolamento que o pessoal de backend já tinha, de forma nativa, leve e open source.
De olho daqui para frente: se você usa Docker no Mac só para subir um banco ou uma API local, vale testar o container hoje — comece pelo pipeline de CI ou por um serviço isolado antes de trocar o fluxo inteiro. E se você faz Swift on Server, essa passou a ser a via nativa para empacotar e entregar. 🚀
Referências
- Repositório oficial: github.com/apple/container
- Apple Open Source: projeto container
- Framework: apple/containerization
- Tutorial oficial: start-here · command reference