Blog

Runner macOS costuma ser o mais caro (em tempo e dinheiro) e o mais sensível (ambiente) dentro de um CI/CD.

Se você precisa de Xcode, codesign, notarization ou testes específicos de macOS, não tem muito “atalho”: você precisa de macOS em algum ponto do pipeline.

Este post faz parte da série:

• Guia de CI/CD no Git para times pequenos: performance, cache e runners

Mapa da série CI/CD

• Guia de CI/CD no Git para times pequenos: performance, cache e runners
• GitLab CI: tags de runner e roteamento de jobs
• Cache no CI/CD: como desenhar keys e evitar cache inválido (GitHub e GitLab)
• Docker layer caching no CI: BuildKit, buildx, cache-from e cache-to
• Runner dedicado no CI/CD: quando vale a pena e como planejar em time pequeno
• Runners macOS no CI: Intel vs Apple Silicon, custos e armadilhas

1) Quando você realmente precisa de macOS runner

Use macOS runner apenas quando necessário, por exemplo:

• build iOS/macOS com Xcode
• codesign e notarization
• testes que dependem de frameworks do macOS

Evite:

• rodar lint, testes unitários gerais, ou docker build no macOS
• transformar macOS runner em runner “padrão”

2) GitHub Actions: macos-latest, Intel e ARM

No GitHub Actions, o runs-on define o tipo de runner.

O detalhe importante: existem variações Intel e Apple Silicon (ARM64). Isso impacta:

• tempo de build
• compatibilidade de dependências nativas
• cache (arquiteturas não compartilham bem)

Dica prática:

• mantenha cache key com runner.arch
• separe workflows por arquitetura quando necessário

3) GitLab Runner no macOS: atenção ao executor e segurança

No GitLab, um padrão comum no macOS é usar executor shell.

Isso significa que os jobs rodam diretamente no host.

Recomendação prática para times pequenos:

• trate o macOS runner como dedicado e isolado
• limite quais projetos podem usá-lo
• documente o que roda ali (Xcode, certificados, dependências)

4) Performance: onde otimizar primeiro

O que mais costuma dar ganho:

• reduzir tarefas que rodam no macOS (deixar só o essencial)
• cache de dependências (com keys bem desenhadas)
• paralelizar testes fora do macOS quando possível

O que dá ganho menor (mas ajuda):

• cache de DerivedData com estratégia (cuidado para não contaminar)
• pré-instalar ferramentas para reduzir setup

Checklist final

• macOS runner só executa jobs que realmente precisam de macOS.
• Arquitetura (Intel vs ARM) está explícita em runs-on e cache keys.
• Runner macOS é tratado como dedicado/isolado.
• Existe estratégia para certificados e segredos com segurança.
• Pipeline é observável (fila vs execução e variação).

Referências

• GitHub Docs: GitHub-hosted runner reference (labels e arquitetura)
• GitLab Docs: Install GitLab Runner on macOS