Este é o Parte 2 da série sobre Modularização iOS. Parte 1: Você Deveria Modularizar Seu App iOS?

Índice

CocoaPods Morreu. E Agora?
As Empresas Que Não Escolheram SPM
Os Números Não Mentem (Mas Não Contam Tudo)
Para Onde a Apple Está Levando o SPM?
SPM: Bom o Suficiente — Até Deixar de Ser
Tuist: A Ferramenta Que Você Não Conhece (Mas Deveria)
Bazel: Exagero — A Não Ser Que Você Seja a Uber
Então... Qual Escolher?
Onde Aprender Mais
Próximos Passos

Comecei a escrever este artigo esperando uma comparação simples: SPM vs Tuist vs Bazel, escolha um, pronto. Aí olhei o que Uber, Spotify, Grab e Lyft realmente usam — e nenhum deles escolheu a ferramenta que 70% dos desenvolvedores iOS preferem.

O que se seguiu foi uma toca de coelho: 15 engineering blogs, issues no GitHub abertas desde 2022, um survey acadêmico peer-reviewed, e a documentação oficial do Bazel e do Tuist. A resposta foi mais complexa do que eu esperava. Tudo aqui linka para a fonte original.

TL;DR: SPM funciona bem até ~100 módulos. Acima disso, Tuist resolve a dor sem sair do Xcode. Bazel é para 500+ módulos com time dedicado de infra. Comece com SPM, planeje migração para Tuist na marca de 80 módulos. Ir para o framework de decisão →

CocoaPods Morreu. E Agora?

Se você faz desenvolvimento iOS há algum tempo, lembra dos dias de pod install. Essa era está acabando.

Um survey peer-reviewed com 112 desenvolvedores iOS, apresentado na conferência IEEE/ACM MOBILESoft 2024, descobriu que 70,5% preferem o Swift Package Manager como gerenciador de dependências principal — com CocoaPods em apenas 26,8%. Outro dado: 20,54% já tinham trocado de ferramenta, sugerindo que desenvolvedores avaliam e migram ativamente, não apenas declaram preferências.

É uma amostra pequena (112 respondentes de comunidades como Swift Leeds, Cocoaheads Brasil e o Slack de iOS Developers), mas os dados ao redor contam a mesma história: CocoaPods entrou oficialmente em modo de manutenção em agosto de 2024. Seu repositório de specs vai se tornar read-only em dezembro de 2026. Google anunciou que vai parar de lançar versões CocoaPods do SDK de Maps para iOS após Q2 2026.

Preferência de Gerenciador de Dependências iOS

O survey diz SPM. O time do CocoaPods diz modo de manutenção. O Google diz sem mais pods. Isso está documentado.

Mas quando comecei a olhar quem realmente modulariza em escala — o cenário mudou.

As Empresas Que Não Escolheram SPM

Passei por cada blog post de engenharia que encontrei de empresas que documentaram publicamente sua modularização iOS. Aqui está o que escolheram:

Gráfico de Empresas e Módulos

Big Tech escolheu Bazel. Uber (monorepo iOS, 150+ engenheiros mobile em 2017), Spotify (200+ engenheiros, CI reduzido de 80 para 20 minutos), Grab (700+ targets iOS, 2,5M linhas de código, 30K+ testes unitários), Lyft, Tinder, Pinterest, Discord. Todos escolheram o build system do Google. A documentação do Bazel descreve o trade-off: curva de aprendizado íngreme e investimento significativo em infraestrutura.

Scale-ups escolheram Tuist. monday.com (~200 módulos, CI reduzido de 20+ para ~9 minutos), Bumble (110+ módulos), Back Market (35-40% mais rápido em clean builds), Trendyol (170+ desenvolvedores mobile iOS e Android, tempo de build reduzido em 65%), Qonto (avaliou SPM mas escolheu Tuist, 50% mais rápido ao modularizar seu monolito), Asana, SoundCloud, Etsy, Bending Spoons — a homepage do Tuist reporta 10K+ times usando a plataforma.

E o SPM sozinho com 100+ módulos? Não encontrei case studies públicos de empresas usando SPM como única ferramenta de modularização nessa escala. Isso não é um veredito sobre as capacidades do SPM — a Apple normalmente não publica case studies sobre suas próprias ferramentas, e muitas empresas simplesmente não blogam sobre infraestrutura de build. É uma ausência de evidência pública, não evidência de ausência.

O que os dados mostram: SPM é a ferramenta mais popular do ecossistema. As empresas que documentaram publicamente suas jornadas de modularização em escala escolheram Tuist ou Bazel — mas isso diz mais sobre quem escreve engineering blogs do que sobre os limites do SPM.

Dito isso, existem problemas documentados. E vale a pena entendê-los antes de escolher.

Os Números Não Mentem (Mas Não Contam Tudo)

Levantei as estatísticas do GitHub dos três projetos (dados de março de 2025).

Comparação SPM vs Tuist vs Bazel

SPM tem 10.100 stars mas 1.045 issues abertas. Tuist tem 5.573 stars com apenas 197 issues abertas. Bazel tem 25.200 stars com 1.624 issues. Esses números refletem escopo do projeto, práticas de triagem e tamanho da comunidade — não qualidade. Uma contagem alta de issues em um projeto amplamente usado é esperada.

Dito isso, várias das issues mais antigas do SPM descrevem especificamente problemas de escalabilidade:

Timeline de Issues do SPM

Um engenheiro trabalhando no Amazon Flex reportou aumentos de 40-50 minutos no build por resolução transitiva de dependências em um projeto com 100+ packages. Essa issue foi aberta após conversar com engenheiros da Apple na WWDC 2022. Ainda está aberta. Três anos depois.

O Swift Forums tem threads sobre Xcode travando por 10-15 minutos na fase "Packages. Finishing...". Outros relatos descrevem travamentos de 5-20 segundos só ao adicionar um arquivo. Uma issue no SourceKit-LSP documenta indexação em background rodando 2-3x mais lenta que o mecanismo nativo do Xcode.

Eu mesmo bati nessa parede — escalando um codebase para 50+ módulos SPM antes de migrar para Tuist. Os problemas nessas threads não são teóricos para mim.

Mas não dizem quando começam a importar. Antes de mergulhar em cada ferramenta, vale entender para onde a Apple está levando o SPM — porque isso define se esses problemas serão resolvidos.

Para Onde a Apple Está Levando o SPM?

SPM tem 9 sessões na WWDC entre 2018-2025, documentação oficial no developer.apple.com, e o Swift Package Index indexa mais de 10.000 packages. Nenhuma outra ferramenta de modularização tem suporte first-party da Apple.

Em fevereiro de 2025, a Apple open-sourced o Swift Build — o motor de build interno do Xcode — reconhecendo: "ter duas formas diferentes de buildar packages também levou a confusão do usuário quando o comportamento das duas implementações não batia." O objetivo: unificar como o SPM builda código no Xcode e na toolchain de linha de comando. A partir do Swift 6.3, desenvolvedores podem optar por testar o Swift Build como sistema de build do SPM.

Propostas recentes do Swift Evolution mostram a direção: SE-0450 (Package Traits), SE-0509 (geração de SBOM), SE-0500 (Package Templates). Melhoram experiência do desenvolvedor e compliance — mas nenhuma endereça os problemas de escalabilidade documentados na issue #5580. A Apple está investindo no SPM, mas o investimento é em amplitude, não nos problemas de escala que empurram times para alternativas.

Veja como as três ferramentas se comparam em comunidade e suporte do ecossistema:

Comparação de Comunidade

Com esse contexto, vamos olhar o que cada ferramenta realmente faz — começando pelo que funciona.

SPM: Bom o Suficiente — Até Deixar de Ser

Você conhece essa experiência: adiciona um Swift package via Xcode, resolve em segundos, importa e já está escrevendo código. Sem Podfile. Sem Ruby. Sem pod install. Simplesmente funciona.

Essa experiência — zero fricção, zero setup — é real e documentada. SPM é integrado ao Xcode, mantido pela Apple, e os problemas documentados de escalabilidade começam a aparecer com 100+ packages. Abaixo desse limite, não encontrei relatos públicos de problemas significativos.

O que o SPM faz bem:

Zero setup. Nenhuma toolchain para instalar, nenhum plugin de CI para configurar. Já vem no Xcode.
Gerenciamento de dependências externas. Adicionar bibliotecas terceiras via URL Git com versionamento semântico — production-ready. Substitui CocoaPods de forma limpa.
Modularização local. Referências .package(path:) dão limites enforçados pelo compilador e targets de teste isolados.
Controle de acesso. public, package e internal mapeiam diretamente para os limites dos módulos.

Onde fica aquém: SPM não tem caching de binários built-in, nem geração centralizada de projetos, e nenhuma forma de restringir quais targets dependem de quais. Conforme a contagem de targets cresce, a indexação em background degrada — e não há workaround dentro do SPM.

Vamos aprofundar no workflow hands-on do SPM na Parte 3. Agora vamos ver o que os times buscam quando encontram esses problemas.

Tuist: A Ferramenta Que Você Não Conhece (Mas Deveria)

Você troca de branch. Xcode trava em "Resolving Packages." Você espera. Limpa o Derived Data. Espera de novo. Seu .pbxproj tem um conflito de merge com 47 linhas de UUIDs. Familiar?

Essa é a experiência que levou times como monday.com, SoundCloud e Trendyol ao Tuist. Seus blog posts descrevem os mesmos pontos de dor — e o mesmo antes/depois.

Tuist se descreve como uma forma de "aprimorar as ferramentas nativas da Apple." Você descreve seus módulos em Swift manifests, o Tuist gera projetos Xcode. Os arquivos gerados são descartáveis — sua configuração é a source of truth. Na prática:

Configuração centralizada. Mude a versão mínima do iOS em um arquivo, não em trinta. Um lugar para build settings, deployment targets, compiler flags.
Geração de projetos. Rode tuist generate, receba um workspace totalmente configurado. Sem gerenciar .xcworkspace manualmente.
Cache de binários. Trendyol cortou builds de CI de 30 para 10 minutos — e setup de UI tests de 15 minutos para 30 segundos. monday.com reduziu CI de 20+ para ~9 minutos com ~200 módulos. Back Market reportou "clean builds mais rápidos, até 35-40% usando cache de dependências terceiras, e até 90% com cache completo."
Enforcement do grafo de dependências. Feature importando outra feature? O CI detecta automaticamente.

O padrão entre os times é consistente: monday.com escreveu que "reestruturar o projeto frequentemente parecia lutar contra a ferramenta em vez de construir com ela." Back Market migrou de SwiftPM para Tuist depois que SPM causava lentidão no Xcode e previews do SwiftUI quebrados. Qonto avaliou SPM mas rejeitou — e escolheu Tuist, cortando tempo de build em 50%.

Duas features se destacam que nem SPM nem Bazel oferecem:

Testes seletivos. Rode apenas os testes afetados pelas suas mudanças. Tuist tem um smart runner nativo — Trendyol construiu sua própria versão antes disso existir.
Continua dentro do Xcode. Tuist gera arquivos .xcodeproj padrão — code completion, debugging e Instruments funcionam como esperado. Bazel requer Starlark e tem integração limitada com Xcode.

O trade-off: A própria documentação do Tuist reconhece que isso adiciona uma camada de abstração. É mais uma ferramenta para aprender e dar suporte no CI.

A homepage do Tuist reporta 10K+ times usando a plataforma, com 300+ contribuidores e 8.300+ PRs mergeados. Os case studies públicos documentados vão até 200+ módulos (monday.com). Não encontrei case studies públicos com 500+ ou 1.000+ módulos no Tuist, mas também não encontrei relatos públicos da plataforma falhando em escalas maiores.

Bazel faz coisas que o Tuist não pode. Mas o contrário também é verdade — e os trade-offs são mais íngremes do que a maioria dos artigos reconhece.

Bazel: Exagero — A Não Ser Que Você Seja a Uber

Bazel é o build system open-source do Google. Diferente do Tuist, que aprimora as ferramentas nativas da Apple, Bazel substitui o build system inteiro. A documentação do Tuist descreve essa distinção: algumas organizações "optam por abandonar o build system do Xcode e adotar alternativas como Buck ou Bazel," mas nota que isso "vem com alta complexidade e carga de manutenção" e "apenas poucas empresas com recursos abundantes conseguem arcar com esse overhead."

O que justifica esse overhead? Três coisas que só uma substituição completa do build system pode fazer:

1. Execução remota. Não apenas cache de artefatos — realmente rodar compilação em servidores remotos. Se o cache falha no Tuist, você builda localmente. Se o cache falha no Bazel, um cluster de servidores builda para você. Spotify reportou redução do feedback de CI de 80 para 20 minutos dessa forma.

2. Builds herméticos. Dois desenvolvedores buildam a mesma branch, mesmo commit, mesmo código — e obtêm binários diferentes. Isso não é hipotético. Acontece sempre que builds dependem de coisas fora do código-fonte: toolchains instaladas no sistema, caminhos absolutos, versões diferentes do Xcode.

Bazel resolve isso. Sua documentação define build hermético como: "dado o mesmo código-fonte e configuração de produto, um build system hermético sempre retorna o mesmo output isolando o build de mudanças no sistema host." O build baixa suas próprias ferramentas. Cada input é rastreado por hash de conteúdo. Mesmos inputs = mesmos outputs, byte a byte. Isso habilita reprodução de crashes (rebuildar o binário exato que você shipou há seis meses), confiabilidade de cache, e execução remota (qualquer máquina produz o mesmo output). Nem SPM nem Tuist podem oferecer isso — ambos delegam compilação ao build system do Xcode, que usa toolchains do sistema e caminhos absolutos.

3. Escala massiva e multi-plataforma. iOS, Android e backend em um monorepo com um único grafo de dependências. Grab documenta 700+ targets iOS e 2,5M linhas de código. Spotify descreve 800+ targets de teste. Square e Mercari reportam perto de 1.000 módulos iOS cada. A página de hermeticidade do Bazel linka para case studies da SpaceX e BMW.

O custo é alto. Bazel usa sua própria linguagem de build (Starlark), requer infraestrutura dedicada, e tem integração limitada com Xcode — desenvolvedores precisam do rules_xcodeproj só para ter code completion funcionando. Sem testes seletivos built-in, sem dashboard de insights, sem geração de projetos. A migração do Spotify foi de experimentação em 2017 até descomissionamento completo do build system legado em 2023 — com 200+ engenheiros contribuindo mensalmente. Uber, Grab e Lyft tinham a escala e os times dedicados para justificar. A maioria dos times não tem.

Então... Qual Escolher?

Três perguntas para se fazer — baseadas no que os dados mostram:

Você está experienciando os problemas documentados do SPM? Travamentos no planejamento de build, Xcode travando na resolução, indexação lenta? Esses são os gatilhos documentados que levaram empresas a avaliar alternativas.
Você precisa de infraestrutura de build ou de um build system? Tuist se descreve como aprimoramento das ferramentas da Apple — testes seletivos, insights de build, caching, tudo dentro do Xcode. Bazel substitui o build system inteiro. A distinção é documentada por ambos os projetos.
Você precisa de builds herméticos? A documentação do Bazel define quando isso importa: execução remota, reprodutibilidade de build e confiabilidade de cache. As empresas que documentaram essa necessidade — Uber, Spotify, Grab — operam com centenas de engenheiros.

Use este fluxograma como ponto de partida — depois confira a tabela de custos abaixo:

Fluxograma de Decisão de Ferramenta

Antes de se comprometer, considere o que a migração realmente custa para seu time — baseado em dados públicos:

	SPM	Tuist	Bazel
Tempo de setup	Horas (integrado ao Xcode, sem ferramentas externas)	Dias a semanas	Meses
Curva de aprendizado	Nenhuma	Moderada (Swift manifests)	Íngreme (Starlark)
Escala documentada	Até ~100 packages	110–200+ módulos	700–1.000+ módulos
Melhoria de CI	Baseline	50–65% mais rápido	75% mais rápido (80→20 min)
Timeline de migração	—	Semanas a meses	Anos (2017→2023)
Infraestrutura	Nenhuma	Tuist Cloud (opcional)	Executores remotos, time de infra
Integração Xcode	Nativa	Completa (.xcodeproj)	Limitada (rules_xcodeproj)
Tamanho do time	Qualquer	5+ engenheiros, 30+ módulos	50+ engenheiros, 200+ módulos

Se eu tivesse que escolher uma ferramenta para um novo projeto de 50 módulos com um time de 15 pessoas hoje, começaria com SPM e planejaria um caminho de migração para Tuist na marca de 80 módulos. Mas esse é o meu contexto — o seu pode ser diferente.

Onde Aprender Mais

Qualquer que seja sua escolha, você não estará começando do zero. Veja como as três ferramentas se comparam de relance — e os melhores recursos que encontrei para cada uma.

Comparação de Ferramentas: SPM vs Tuist vs Bazel

SPM — Comece aqui:

Documentação oficial da Apple — guias para adicionar packages, criar packages e gerenciar dependências
Documentação do Package Manager no Swift.org — referência CLI e formato do manifest
Sessões da WWDC — 9 sessões de 2018 a 2025, começando com Getting to Know Swift Package Manager (2018)
Swift Package Index — 10.000+ packages indexados, apoiado pela Apple
Anúncio do Swift Build open-source — para onde a Apple está levando o build system

Tuist — Comece aqui:

Documentação oficial — começando, geração de projetos, caching, testes seletivos
Guias de migração — passo a passo para projetos Xcode, Swift packages, XcodeGen e Bazel
awesome-tuist — 86 recursos da comunidade: 11 talks, 9 vídeos, 45 blog posts
Slack do Tuist — comunidade ativa com mantenedores
Engineering blogs: monday.com, Back Market, Trendyol, Qonto

Bazel — Comece aqui:

Guia oficial de migração — migrando do Xcode
rules_apple — regras da comunidade para buildar apps Apple com Bazel
rules_xcodeproj — gerar projetos Xcode a partir do Bazel
Talks da BazelCon — conferência anual com 200+ participantes
Engineering blogs: Spotify, Grab, Airbnb (Buck para Bazel)

Próximos Passos

Comecei este artigo esperando uma resposta simples. O que descobri foi que a "melhor ferramenta" depende de um limiar — e ninguém havia mapeado onde esse limiar realmente está.

Se o SPM funciona para 80% dos times, o que acontece no ponto exato onde ele para de funcionar? Na Parte 3, vamos descobrir — com código. SPM hands-on: distribuição, módulos locais, Features + Foundations, e os padrões de arquitetura que mantêm seu grafo de dependências limpo.

Na Parte 4, vamos aprofundar no Tuist — geração de projetos, cache de binários, e o que times como Trendyol e monday.com realmente mudaram em seus codebases.

Todos os dados vêm de fontes publicamente disponíveis até abril de 2026. As opiniões expressas aqui são minhas.

Achou útil? Compartilhe com seu time — esse é o tipo de pesquisa que economiza semanas de avaliação. Assine via RSS para receber a Parte 3 primeiro, ou fale comigo no LinkedIn — leio todas as mensagens.