Seguro por design: por que o Buildy sobrevive à 2.5.2 da Apple

Em março de 2026, a Apple começou a aplicar a Diretriz 2.5.2 contra construtores de apps com IA. O Buildy foi arquitetado para que a regra não se aplique aos apps que você cria com ele.

Em março de 2026, a Apple começou a aplicar a Diretriz 2.5.2 contra construtores de apps com IA. Segundo reportagens do MacRumors e do 9to5Mac, ela bloqueou atualizações dos apps da Replit e da Vibecode e removeu de vez o app Anything (antigo Create.xyz). A aplicação da regra aconteceu de forma gradual ao longo do mês, em vez de tudo de uma vez, e alguns status mudaram depois — o Anything voltou mais tarde e a Replit retomou as publicações. A regra por trás disso era a Diretriz 2.5.2 de Revisão da App Store.

O que a 2.5.2 realmente diz

A diretriz é curta: apps "não podem baixar, instalar ou executar código que introduza ou altere recursos ou funcionalidades do app." Em palavras simples, um app no celular tem que ser autossuficiente. Ele não pode buscar código novo em tempo de execução e rodá-lo.

É exatamente isso que os construtores removidos faziam. O padrão era idêntico em todos eles:

1. O usuário abre o app construtor de IA no celular.
2. O app aceita ou baixa código gerado pelo usuário em tempo de execução.
3. Um webview embutido ou motor JavaScript executa esse código.

O passo três é a violação. No momento em que um binário entregue roda código que não passou pela revisão, ele está em infração — e a Apple começou a aplicar isso contra essa categoria inteira em março de 2026.

Por que isso não se aplica ao Buildy

O Buildy é uma ferramenta de construção, não um motor que roda dentro dos apps dos seus usuários. A distinção parece sutil. Em termos de arquitetura, é o jogo inteiro.

Quando você cria com o Buildy, existem duas coisas completamente separadas:

• O editor e o preview. Eles ficam no buildy.me, nos nossos servidores. Quando você clica em um elemento no preview ao vivo, o Buildy compila seu código no servidor e o renderiza num iframe em sandbox. O motor de preview nunca sai da nossa infraestrutura. Ele nunca é empacotado em nada que chegue a um celular.
• O app que você entrega. Esse é código React Native e Expo comum. O EAS Build o compila para um .ipa ou .apk assinado. O binário na App Store não tem nenhuma execução de código, nenhum carregador remoto, nenhuma superfície de 2.5.2.

Os construtores que foram removidos misturaram essas duas coisas numa só. O motor de preview era o app entregue. A gente nunca montou desse jeito, e não existe nenhuma configuração que pudéssemos virar amanhã para quebrar isso — é assim que a arquitetura é construída.

Por que a gente fez essa escolha cedo

Preview no servidor é mais difícil de construir do que embutir um runtime no app. Um motor JavaScript dentro do app é o caminho de menor resistência: empacote uma vez e todo preview sai de graça. A gente não seguiu esse caminho, e por um tempo pareceu trabalho extra sem retorno. Aí a aplicação da 2.5.2 chegou e o retorno foi a categoria inteira ficando fora da loteria de rejeição.

Tem um segundo benefício que vem da mesma decisão. Como o preview roda nos nossos servidores e a exportação é código puro, o código que você entrega é exatamente o código que você pode ler, auditar e ter como seu. Nenhum runtime proprietário é costurado no momento da build. (Mais sobre isso em Seu código é seu.)

O que isso significa para você

Se você viu concorrentes serem removidos da loja e ficou se perguntando se vale a pena o risco de criar um app mobile com IA, esta é a resposta: o risco que aqueles produtos carregavam era uma escolha de arquitetura, não uma propriedade inerente à criação de apps com IA. O Buildy fez a outra escolha.

Você descreve o app. A gente gera o código React Native. Você visualiza com segurança nos nossos servidores, exporta num plano pago e entrega um binário assinado normal que não tem nada a esconder da revisão.

Crie apps mobile sem a loteria de rejeição. Comece a construir de graça.