Resumo semanal do que está acontecendo no ecossistema Tuist — notas de lançamento, destaques da comunidade e observações sobre o uso real.
Quem está escrevendo isso
Eu sou Youngjun Lee (Gamehelper), um engenheiro iOS. Contribuí para a localização coreana do Tuist e estou listado como depoimento no site oficial do Tuist. Não uso o Tuist em um código de produção da empresa hoje (minha equipe atual e anterior usava React Native ou ainda não encontrou o momento certo para adotá-lo), mas eu o rodo em todos os meus projetos pessoais e tenho sido ativo no Slack público do Tuist há algum tempo.
Esta série é minha maneira de acompanhar o Tuist de perto e compartilhar o que aprendo — não uma reivindicação a qualquer papel oficial.
Uma nota sobre o ritmo: O Tuist não é lançado em um ritmo semanal estrito, então este primeiro episódio pega os principais ajustes dos últimos dois ou três dias, ao invés de uma semana exata. A partir do episódio #2, cada episódio cobrirá o período desde o anterior — mais curto quando não há muito a relatar e mais longo quando houver.
Alterações da semana passada
1. SwifterPM é agora o método padrão de restauração de dependências
A partir da versão 4.202.0, o comando tuist install usa SwifterPM por padrão para buscar e restaurar as dependências de pacotes Swift. A resolução ainda passa pelo Swift Package Manager, mas a restauração agora vincula checkouts a um repositório global com links simbólicos em vez de copiá-los para cada árvore de trabalho. O efeito prático: restaurações quentes caem para subsegundos, e o problema de gigabytes duplicados entre as árvores de trabalho desaparece. Isso era opcional — agora está ativado por padrão, com uma reconfiguração pelo ambiente (TUIST_USE_SWIFTERPM=0) se você encontrar um pacote não suportado.
Dica: em CI, você pode registrar ~/.cache/swifterpm como um caminho de cache.
2. Controlando condições de invalidação do cache de alvo
O cache de um alvo pode ser afetado por mais do que arquivos-fonte e dependências declaradas — modelos de geração de código, versões de ferramentas, arquivos de configuração, variáveis de ambiente. Até agora, alterações nesse ambiente não invalidavam o cache do Tuist. A partir da versão pré-lançamento 4.204.0, você pode controlar isso definindo additionalHashingInputs em um alvo:
let hashingInputs: [Target.HashingInput] = [
.glob("Templates/Model.stencil"),
.glob("Codegen"),
.glob("Config/**/*.json"),
.environmentVariable("FEATURE_CONFIGURATION"),
.string("generator-v2"),
.script("codegen --version"),
]
let target = Target.target(
...,
additionalHashingInputs: hashingInputs
)3. Agentes de codificação agora podem autenticar diretamente com o Tuist (auth.md)
Notícias de 17 de julho. O Tuist agora suporta auth.md para agentes de codificação conectando-se através do seu servidor MCP (atualmente suportando Claude Code, Codex, OpenCode e Pi). Um agente não autenticado pode descobrir o fluxo de autenticação por conta própria, registrar, solicitar um código de aprovação de seis dígitos e receber uma credencial limitada quando você a aprovar. Uma vez conectado, o agente pode listar suas contas, criar um projeto, guiar uma integração Gradle e verificar o comportamento do cache, então reportar que a configuração foi concluída.
Por quê isso é importante: à medida que mais equipes iOS/Android trazem agentes de codificação para CI e desenvolvimento local, ter um fluxo de autenticação padronizado para agentes IA é uma melhoria significativa do lado da segurança.
Tuist Talk
O Tuist lançou um chamado no Slack para quem estivesse disposto testar seu GitHub macOS runner (tuist-macos) para DM-á-los. Eu fui convidado e dei uma tentada, mas não funcionou.
Depois de checar, fui informado para tentar a partir de uma Organização — mas não posso mover meu projeto para uma, então ainda não é funcional para mim.
Se você quiser tentar por conta própria, altere seu runner conforme abaixo e entre em contato através de DM ou comentário.
runs-on: tuist-macosNotas práticas
Depois de ver que o SwifterPM agora era padrão, fiquei curioso se poderia usá-lo em meu próprio projeto e quanto mais rápido seria na prática.
Para fazer uma comparação, executei um deploy do GitHub a partir de minha ramificação existente, então tentei novamente em uma ramificação onde atualizei o Tuist.
O build falhou. Tentei construir localmente para rastrear o problema e recebi erros dizendo que nenhum dos modelos Core Data poderia ser encontrado.
Os arquivos de modelo estavam ausentes das Recursos. A causa se revelou algo de uma correção anterior: para resolver um erro “Multiple commands produce”, eu tinha excluído o arquivo .xcdatamodel dentro do .xcdatamodeld do Manifesto do Projeto. Como uma atualização recente alterou o esquema, esse .xcdatamodeld agora tinha dois arquivos, Model.xcdatamodel e Model2.xcdatamodel, e excluir apenas o Model.xcdatamodel resolveu.
Ainda assim, não parecia limpo, então tentei uma opção diferente. Uma configuração coreDataModels tinha sido adicionada anteriormente exatamente para esse tipo de problema, mas não havia resolvido meu problema quando eu primeiro o testei. Mantendo o .xcdatamodeld excluído das Recursos,
recursos: [.glob(pattern: "Resources/**",
excluindo: [
...,
"Resources/Databases/DAModel.xcdatamodeld/**"
]
)],e especificando o .xcdatamodeld excluído sob coreDataModels,
coreDataModels: [
.coreDataModel("Resources/Databases/DAModel.xcdatamodeld")
]fez o erro desaparecer.
No passado, quando eu encontrava um erro como esse, eu procuraria em qual versão ou qual commit introduziu. Dessa vez não fui tão longe.
Depois de corrigir o erro do build, verifiquei o tempo de deploy — não havia mudado nada, então voltei a investigar localmente. A documentação do SwifterPM diz que um cache é criado em ~/.cache/swiftpm, e para registrar esse caminho como um cache, mas na verdade nada estava sendo criado lá.
Até mesmo depois de limpar completamente o cache do Tuist e o SPM cache, ainda não funcionou, levando a uma hipótese: talvez só entre em vigor quando você está usando Package.swift diretamente. Abri um projeto de amostra Tuist que eu havia criado anteriormente e executei tuist install — o log mostrou swifterpm.
Após executar clean e então install novamente, o log mostrou que estava sendo restaurado de ~/.cache/swiftpm em vez de ser obtido.
Com base na descrição de que “se você integrar com um projeto Xcode existente, tuist install usa SwifterPM,” eu esperava que funcionasse em projetos gerados pelo Tuist também — mas descobri que funciona apenas em projetos que usam Package.swift.
Testando auth.md
Para testar isso, primeiro me desloguei da sessão existente.
mise x -- tuist auth logoutQuando pedi a um agente para executar generate, recebi um erro me informando que eu precisava fazer login.
Depois de instalar o MCP do Tuist,
claude mcp add --transport http tuist https://tuist.dev/mcptentando novamente recebi esta resposta:
Esse MCP tool autentica o servidor MCP, não a CLI — ele não escreve a entrada ~/.config/tuist/credentials que tuist generate lê. Errou o alvo; pulando isso.Verificando se o requisito de autenticação pode ser contornado para um generate simples: Executou 1 comando shellNão pode ser contornado aqui. Tuist.swift declara fullHandle: "gamehelper/democracy-action-ios", então o projeto está conectado ao servidor e cada generate autentica primeiro — --no-binary-cache falha da mesma forma.O login é um fluxo interativo do navegador, então tem que vir do seu terminal:! mise x -- tuist auth loginMe avise depois e eu executarei o generate.
Ele diz que a autenticação do MCP é necessária.
Mesmo depois de autenticar o MCP, ainda me pediu para fazer login — então concluí que isso não automatiza a autenticação para builds do Tuist. (Isso foi explicado em algum lugar, mas eu não acho que li com suficiente atenção.)
Depois de me deslogar do MCP e pedir uma lista de projetos, foi solicitado meu endereço de email.
Uma vez que dei, um código de aprovação foi emitido e me disseram para abrir uma página e inseri-lo.
Naquela página, eu fui solicitado a inserir um código de seis dígitos e, uma vez que completei a autenticação,
Claude o pegou e exibiu corretamente a lista de projetos.
Mas o MCP ainda estava mostrando como falha. Quando autentiquei novamente, vi que ele abriu um navegador, autenticou e fechou automaticamente.
Como funcionou imediatamente após sair do MCP, eu esperava que essa autenticação conectasse o MCP — mas o MCP ainda estava mostrando como desconectado, mesmo com chamadas sendo bem-sucedidas normalmente, o que era confuso. Minha suposição é que quando você se autentica através de auth.md, o agente mantém um token, mas a CLI não, por isso isso acontece.
Código Feliz! 😎
Se você achou este post útil, por favor, dê uma rodada de palmas 👏. Explore mais conteúdo relacionado a iOS, Tuist em meus outros posts.
Para insights adicionais e atualizações, confira meu LinkedIn perfil. Obrigado pelo seu apoio!
Esta série é um projeto pessoal para acompanhar as mudanças da Tuist de forma consistente, compartilhando alterações conforme elas ocorrem.
Quanto ao cronograma de publicação: a Tuist não é lançada exatamente uma vez por semana, então este primeiro número foi composto com as principais notícias dos últimos 2 semanas. A partir do segundo número, usaremos o período desde a última edição como base, mas se houver poucas notícias, será mais curto, e se houver muitas, será mais longo.
Principais alterações da semana passada
1. Adoção do SwifterPM como método padrão de restauração de dependências
4.202.0부터 tuist install이 기본적으로 SwifterPM을 사용해서 Swift 패키지 의존성을 가져오고 복원합니다. 패키지 해석(resolution) 자체는 여전히 Swift Package Manager가 담당하지만, 복원(restoration) 단계에서 각 worktree에 파일을 복사하는 대신 전역 콘텐츠 주소 기반 저장소에 Symbolic 링크만 겁니다. 결과적으로 캐시가 미리 준비된 상태에서의 복원은 1초 미만으로 줄고, 여러 worktree에 중복 저장되어 발행한 용량 문제도 사라집니다. 기존에는 선택사항이었는데 이제는 기본으로 사용되고, 지원 안 되는 패키지를 사용하면 환경 변수로 되돌릴 수 있습니다.(TUIST_USE_SWIFTERPM=0)
Dica: CI에서는 ~/.cache/swifterpm을 캐시에 등록해 사용할 수 있습니다.
2. Controle de condições para invalidação do cache de alvo
O cache de um alvo pode ser afetado por fatores além dos arquivos de origem e das dependências declaradas, como modelos de geração de código, versões de ferramentas, arquivos de configuração e variáveis de ambiente. Até agora, havia o risco de que alterações nessas condições não invalidassem o cache do Tuist, mas a partir da versão pré-lançamento 4.204.0, é possível controlar isso configurando o campo additionalHashingInputs no alvo.
3. Agentes de codificação podem ser autenticados diretamente no Tuist (auth.md)
A partir de 17 de julho, o Tuist suporta auth.md para autenticar agentes conectados ao servidor MCP (atualmente suportando Claude Code, Codex, OpenCode e Pi). Agentes não autenticados podem descobrir métodos de autenticação, se registrar e solicitar um código de aprovação de 6 dígitos. Após a entrada do código pelo usuário, o agente recebe uma credencial limitada. Uma vez conectado, o agente pode realizar tarefas como consulta de contas, criação de projetos, integração com Gradle e verificação da operação do cache.
Dica: O MCP funciona sem autenticação, mas pode ser configurado para funcionar.
Tuist Talk
Há um anúncio para testar o runner macOS personalizado do Tuist (tuist-macos) no Github, envie uma DM se quiser tentar, mas não funcionou.
A resposta do suporte foi para testá-lo na organização, mas não posso mover o projeto para a organização, então ainda não é possível usar.
Se quiser testar, altere o runner e envie uma DM ou comentário para solicitar.
Depoimentos após a adoção
SwifterPM
Depois de ver que SwifterPM foi configurado como padrão, fiquei curioso para saber se funcionava no meu projeto e quão rápido era.
Para comparar, executei a distribuição do Github em uma ramificação existente e tentei novamente após atualizar o Tuist.
Mas a construção falhou e, ao tentar construir localmente para encontrar o problema, recebi um erro informando que não conseguia encontrar todos os modelos do Core Data.
Faltava um arquivo de modelo no diretório Resources. No artigo anterior, para resolver o erro “Multiple commands produce”, excluí os arquivos .xcdatamodel dentro do xcdatamodeld no Manifesto de Projeto, e isso foi a causa do problema.
O xcdatamodeld em questão tinha dois modelos (Model.xcdatamodel e Model2.xcdatamodel) após uma atualização recente do esquema. Ao excluir apenas o Model.xcdatamodel, consegui resolver o problema.
No entanto, isso parecia não ser limpo, então tentei uma nova opção.
Devido a esse erro, coreDataModels foi adicionado mais cedo, mas quando tentei resolver o problema, ele não ajudou.
Mantendo xcdatamodeld excluído do Resources e especificando um xcdatamodeld sem .coreDataModels, o erro desapareceu.
Ao contrário das vezes anteriores em que precisei procurar em versões específicas ou commits para encontrar a causa do problema, desta vez não precisei fazer isso.
Após resolver o erro de construção e verificar o tempo de publicação, notei que nada havia mudado, então comecei a verificar localmente novamente.
Ao seguir as instruções do SwifterPM, diziam para registrar ~/.cache/swiftpm como cache, mas não foi criada nenhuma pasta lá.
Além de limpar o cache do Tuist, também limpei o SPM e cheguei à conclusão de que isso funcionava apenas quando usávamos Package.swift.
Fiz download de um exemplo pré-existente do Tuist e executei tuist install, podendo ver swifterpm no log.
Ao executar o comando clean seguido por install novamente, pude ver um registro indicando que os arquivos estavam sendo restaurados de ~/.cache/swiftpm em vez de serem baixados (fetching).
Lendo a explicação “se baseado no XcodeProj, ao executar o comando tuist install, usa-se SwifterPM”, eu esperava que funcionasse em projetos criados pelo Tuist também. No entanto, verifiquei e percebi que isso só funciona em projetos que usam Package.swift.
auth.md
Para testar, primeiro desloguei o login existente.
mies x — tuist auth logout
Ao pedir ao agente para generate, recebi um erro informando que deveria fazer login.
Depois de instalar o Tuist MCP,
claude mcp add — transport http tuist https://tuist.dev/mcp
Ao tentar novamente, aparece a seguinte mensagem de autenticação necessária:
Ainda não autenticado. Um utilitário de autenticação do Tuist MCP acabou de se tornar disponível — tentando isso em vez da rota no navegador:
Esse utilitário de MCP autentica o servidor MCP, não a CLI — ele não escreverá a entrada ~/.config/tuist/credentials que tuist generate lê. Erro na alavanca; pulando.
Verificando se a exigência de autenticação pode ser contornada para um gerar simples:
Executou 1 comando shell
Não pode ser contornado aqui. Tuist.swift declara fullHandle: "gamehelper/democracy-action-ios", então o projeto está conectado ao servidor e cada gerar autentica primeiro — --no-binary-cache falha de forma idêntica.
O login é um fluxo interativo no navegador, então ele tem que vir do seu terminal:
! mise x -- tuist auth login
Pingue-me depois e eu executarei o gerar.Mesmo após a autenticação do MCP, ainda é solicitado um login,
Pensei que a autenticação para o Tuist build não seria automatizada. (Havia uma explicação, mas eu não li direito)
Depois de desativar a autenticação do MCP, quando solicitei uma lista de projetos, foi solicitado meu endereço de e-mail.
Ao fornecer meu endereço de e-mail, um código foi emitido e eu fui solicitado a abrir uma página para inserir o código.
Ao acessar a página, apareceu uma solicitação para inserir um código de 6 dígitos.
Ao completar a autenticação, pude confirmar que Claude estava detectando e exibindo normalmente a lista de projetos.
No entanto, o MCP permaneceu em estado failed. Quando tentei a autenticação novamente, pude confirmar que o navegador foi aberto automaticamente e fechado após a autenticação.
Depois de fazer logout do MCP, esperava que essa autenticação conectasse o MCP, mas ele permaneceu em estado desconectado, embora as chamadas estivessem funcionando normalmente.
Acredito que essa condição ocorra porque, ao fazer autenticação através de auth.md, o Agente tem um Token, mas a CLI não.