Processo - Como um projeto acontece de verdade
Três fases: combinar o que entra na primeira versão, construir em mudanças pequenas que chegam com prova e entregar pelos mesmos canais que publicam os apps do estúdio. O post sobre uma noite construindo na nuvem mostra esse ciclo rodando.
Fase 01
Descobrir
Começa com uma conversa sobre o problema e sobre quem vai usar o produto. Nessa hora as restrições pesam mais que os objetivos: prazo, orçamento, dados sensíveis e o que já existe e precisa continuar funcionando.
Daí sai a escolha de plataforma: app nativo para iPhone, web ou os dois, e se a IA entra, no aparelho ou na nuvem. Quando a dúvida é de interface, um protótipo responde mais rápido que uma reunião.
O resultado é um escopo por escrito: o que entra na primeira versão, o que fica para depois e as regras do projeto num arquivo que pessoas e agentes leem antes de mexer no código.
Incluído nesta fase
- Escopo da primeira versão
- Escolha de plataforma
- Protótipo quando há dúvida
- Mapa do que sai do aparelho
- Regras do projeto por escrito
Fase 02
Construir
Cada tarefa vira uma sessão do Claude Code na nuvem, com o repositório clonado e uma mudança só. Várias rodam ao mesmo tempo, e cada uma termina num pull request.
Nos apps iOS, o Revyl compila o app num Mac na nuvem e abre um iPhone simulado que o próprio agente usa: toca, rola e tira as fotos que vão no pull request como prova. Na web, cada pull request ganha um preview na Vercel.
Os testes rodam junto: Swift Testing nos apps, bun test neste site. Nenhuma mudança chega à revisão sem dizer o que compilou, o que foi visto funcionando e o que ficou de fora.
Uma mudança pequena com prova é mais fácil de revisar do que uma grande com promessa. Uma noite trabalhando assim rendeu 19 pull requests mesclados em dois apps, com o Xcode fechado o tempo todo.
Fase 03
Entregar
Antes de uma versão ir para a loja, o Mac tem a palavra final: a suíte completa de testes roda lá, num build de verdade, porque o simulador da nuvem não pega tudo.
A assinatura e o envio ficam com o Xcode Cloud: um pull request aprovado já basta para ele gerar o build assinado para o TestFlight e a App Store. Na web, o merge publica na Vercel.
Junto com o app vão as páginas que a revisão da Apple pede, privacidade, termos e suporte, escritas a partir do que o código faz. Depois do lançamento vêm as atualizações para cada iOS novo e as correções.
Incluído nesta fase
- Prova a cada mudança. Fotos do simulador ou preview na Vercel em todo pull request, mais a suíte completa no Mac antes de cada versão.
- TestFlight e App Store. Builds assinados pelo Xcode Cloud, com a página e as capturas da loja revisadas a cada versão.
- Privacidade e suporte. Política de privacidade, termos e página de suporte em português e inglês, iguais ao que o app faz.
Nossos valores - No que a gente se segura
Regras que saíram dos apps do estúdio e valem para qualquer projeto.
- Prova antes do merge. Uma mudança chega à revisão com o que compilou, o que apareceu na tela e o que ficou de fora.
- O código faz as contas. O modelo lê e organiza. Números, regras e ranking ficam com código testado, como no Prandial.
- Dado no aparelho por padrão. Weightics, Zenoney e Prandial guardam os dados no iPhone. Só sai o que um recurso precisa, e a política diz o quê.
- Nativo quando é app. SwiftUI no iPhone em vez de uma web view embrulhada, para o app se comportar como a plataforma espera.
- Ferramenta nova começa em casa. Uma ferramenta nova passa primeiro pelos apps do estúdio, e o blog conta o que funcionou e o que não funcionou.
- Trabalho à vista. Cada mudança é um pull request que você pode abrir, com o preview e as fotos junto. Os trade-offs aparecem quando acontecem.
Sob encomenda - Traga o problema para a bancada.
Uma ideia crua já basta para começar. Você conversa direto com quem vai construir.
Bancada
São Paulo GMT−3