Mac mini M6 vs runner macOS hospedado do GitHub: um benchmark de build no Xcode

Queríamos um número real para uma pergunta. Quanto mais rápido é um Mac mini M6 dedicado do que o runner macOS hospedado padrão do GitHub, em um app de iOS de verdade? Então fizemos o build do app open source Wikipedia para iOS nos dois, com o mesmo Xcode e o mesmo script, três vezes em cada um.

Este post substitui o nosso post anterior de benchmark do M4. Todos os números aqui vêm de execuções feitas em 24 de setembro de 2026.

Resultados

Median of 3 runs, in seconds. Lower is better.

                      GitHub-hosted   MacRun M6   change
                      macos-26
package download            43            39       -8%
clean build                183            86      -53%
incremental build           21            10      -51%
no-op build                 20            10      -50%
220 unit tests              44            17      -61%

O M6 foi cerca de duas vezes mais rápido para compilar. O download dos pacotes ficou parecido, porque as duas máquinas baixam os mesmos pacotes do GitHub por conexões rápidas. Todos os passos deram certo nas duas máquinas em todas as execuções.

Quanto tempo custa um job de CI normal

A tabela compara as máquinas passo a passo. Um job de CI real é diferente em cada uma. Um runner hospedado começa todo job vazio. Ele precisa baixar os pacotes, fazer um build limpo e depois testar. Um Mac dedicado guarda a pasta de build, então depois de uma mudança pequena ele só refaz o que mudou.

Essa é a diferença que a sua equipe sente. Um job que levava quatro minutos e meio termina em menos de trinta segundos. Em um dia cheio de pushes, os minutos economizados viram horas.

O mesmo job custa dinheiro em um runner hospedado. O GitHub arredonda cada job para cima até o minuto, então 269 segundos são cobrados como 5 minutos. A $0.062 por minuto, isso dá uns 31 centavos por job. Em um Mac dedicado não custa nada a mais. Nossa calculadora de custos transforma o seu número de jobs em um valor mensal.

As duas máquinas

Os detalhes de hardware vêm das próprias máquinas. Cada execução mostrou o chip, o número de núcleos e a memória antes do build. O GitHub também vende runners macOS maiores, com preço por minuto mais alto. Testamos o padrão porque é o que a maioria das equipes usa.

Método

• Projeto: wikimedia/wikipedia-ios no commit 8691a89, com build para o iOS Simulator usando o scheme Wikipedia e os pacotes Swift dele.
• Simulador: um iPhone 17 novo no iOS 26.5, criado do mesmo jeito nas duas máquinas.
• Toda execução começa com o cache de pacotes e o DerivedData apagados. A assinatura fica desligada, como costuma ser em builds de CI para o simulador.
• Download de pacotes: xcodebuild -resolvePackageDependencies em uma pasta vazia.
• Build limpo: xcodebuild build-for-testing com o DerivedData vazio e os pacotes já baixados.
• Build incremental: o mesmo comando depois de adicionar uma linha de comentário a um arquivo Swift do app.
• Build sem mudanças: o mesmo comando de novo, sem nada alterado.
• Testes: os 220 testes de unidade do pacote WMFData do app, rodados com test-without-building em um simulador iniciado.
• Três execuções completas em cada máquina. Informamos a mediana.

Ressalvas

Rodamos os testes de pacote do app, não o target de testes principal. O target principal precisa de entitlements de app group assinados, e um build de CI sem assinatura não tem isso. O host de testes dele ficava reiniciando nas duas máquinas, então não seria uma medida justa.

O build incremental mexeu em um arquivo pequeno. A maior parte dos 10 segundos é o Xcode planejando o build, e por isso ele empata com o build sem mudanças. Uma mudança em um arquivo muito usado levaria mais tempo nas duas máquinas.

As duas máquinas rodavam versões diferentes do macOS, porque cada uma rodava o que o dono oferece hoje. Um job hospedado também pode guardar pacotes Swift em cache com actions/cache. Isso reduziria o passo de download. Não eliminaria o build limpo, que é a maior parte do tempo.

Nós vendemos o runner M6, então pese os nossos números sabendo disso. O método acima está completo o bastante para você repetir no seu próprio projeto, que é o único benchmark que realmente importa para você.