Claude Code agora cria apps com simulador de iOS

Criei um aplicativo de iPhone inteiro dentro do Claude Code sem escrever uma única linha de código. O app se chama Unscroll: ele bloqueia o celular depois de um tempo de uso e só devolve a tela depois de uma respiração guiada e de a pessoa escrever pelo que é grata naquele momento. O que torna isso possível é uma novidade da Anthropic, um simulador de iPhone dentro do próprio Claude Code, e vale entender como usar isso direito, porque o simulador sozinho não é o que garante qualidade.

O que mudou

Agora dá pra criar o app conversando com o modelo e ver ele funcionando em tempo real, direto num simulador de iOS, sem sair do terminal. Existe um botão de "Simulador de iOS" que abre o aparelho escolhido (usei um iPhone 17) e mostra cada tela sendo construída conforme a conversa avança.

Pra rodar o simulador é preciso ter o Xcode instalado, que é gratuito e vem pela App Store, e isso significa que só funciona num Mac. Mas o processo que descrevo aqui não depende do simulador em si: funciona do mesmo jeito pra qualquer tipo de projeto, app Android, site, CRM, sistema interno, só muda onde o projeto roda. Quem não tem Mac aplica a mesma lógica pra outras plataformas.

A metodologia em três etapas

Gosto de comparar o processo com construir uma casa. Ninguém começa erguendo parede sem planta, e criar um app é a mesma coisa: quem pula direto pra "obra" sem planejar acaba com um monte de retrabalho.

1. Planta: planejar antes de qualquer linha de código

Antes de escrever qualquer prompt de construção, uso uma skill de planejador de produto que faz uma entrevista estruturada sobre a visão do produto. Dessa entrevista saem três documentos:

Vision.md: as decisões consolidadas do produto, público-alvo, diferencial, tom de voz, estratégia, persona e os riscos envolvidos.
PRD (Product Requirements Document): as especificações técnicas de verdade, o que o app precisa fazer, tela por tela.
Product Roadmap: a ordem em que as funcionalidades entram.

Também dá pra usar referências visuais nessa etapa. Mandei uma imagem de um design que gostei no Dribbble e pedi pro Claude Code gerar um design.md com paleta de cores, tipografia e estrutura visual, basicamente um design system em documento antes mesmo de existir uma tela.

2. Obra: construir com a documentação pronta

Com Vision, PRD, Roadmap e design system prontos, o próximo passo é montar um prompt detalhado com regras inegociáveis e critérios claros de "pronto". Essa parte é o que chamo de estratégia de loop: definir de antemão quais testes o app precisa passar pra ser considerado terminado, em vez de ficar julgando no olho se está bom.

Depois de mandar esse prompt, é só abrir o Simulador de iOS, escolher o aparelho e acompanhar a construção em tempo real, tela aparecendo, fluxo sendo montado, sem precisar ficar rodando o projeto manualmente pra conferir cada mudança.

3. Acabamento: polir o que sobrou

No fim, a mesma skill gera um documento de pendências, o pendencias.md, listando o que ainda falta resolver. Parte dessas pendências o próprio modelo resolve sozinho. Outra parte depende de coisas que só se testam de verdade, como o processo de publicar na App Store, e outra parte é ajuste manual mesmo, visual, funcionalidade que precisa de decisão humana, bug específico.

O resultado

Com essa base toda pronta, o app saiu praticamente funcional com poucos prompts. A diferença não foi o simulador ter feito mágica, foi a documentação ter garantido um nível alto de qualidade desde o primeiro prompt de construção. Sem a etapa de planejamento, teria sido o de sempre: várias idas e vindas até o modelo acertar o que eu queria.

O que fica desse experimento

A barreira técnica pra criar um aplicativo está cada vez menor, mas o simulador de iOS não é o que faz o app ficar bom sozinho. É o processo de planejamento, a planta antes da obra, que garante isso. Se você não tem Mac e não consegue usar o simulador, a mesma metodologia de três etapas funciona pra web ou qualquer outra plataforma, o que muda é só onde você vai ver o resultado rodando.