Em março de 2026, a Apple passou a bloquear atualizações e remover da App Store apps construídos com vibe coding, citando a Guideline 2.5.2 das App Store Review Guidelines — a regra que proíbe um app de baixar, instalar ou executar código que altera sua própria funcionalidade sem passar por revisão da Apple. Para empresas brasileiras usando vibe coding para construir produtos que vão parar na loja pública, o risco é real e imediato. Para quem usa vibe coding só para ferramentas internas — o caso mais comum entre clientes da Jetpacks —, a resposta é mais tranquilizadora do que parece à primeira vista, mas com uma condição: depende de como o app é distribuído. Este guia separa os dois cenários e mostra o que muda em cada um.
O que aconteceu: a Apple bloqueou apps de vibe coding na App Store
Segundo reportagem original do The Information, replicada pela MacRumors e pela Exame, a Apple passou a bloquear atualizações de apps de "vibe coding" — ferramentas que geram e executam novos aplicativos ou funcionalidades a partir de prompt em linguagem natural — a partir de março de 2026. Os casos mais citados envolvem o Replit, o Vibecode e o app Anything, este último removido definitivamente da loja em 30 de março de 2026, após meses de bloqueio para atualizações desde dezembro de 2025.
A justificativa citada pela Apple é a Guideline 2.5.2, que não é uma regra nova — é uma cláusula que já existia nas App Store Review Guidelines antes da onda de vibe coding. O que mudou foi a aplicação dela contra uma categoria de app inteira: ferramentas cuja função central é gerar e rodar código executável dentro do próprio app, depois que o container já foi aprovado pela Apple.
A Guideline 2.5.2, no texto oficial da Apple
O texto, publicado pela própria Apple em developer.apple.com, diz:
"Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the app completely viewable and editable by the user."
Em português: um app não pode baixar ou executar código que altera sua própria funcionalidade sem passar por revisão — com uma exceção explícita para apps educacionais, cujo código gerado fica totalmente visível e editável pelo usuário. É essa exceção que explica por que algumas ferramentas de geração de código continuaram publicando sem problema, enquanto outras foram bloqueadas: a diferença está em como o app se posiciona e em como o código gerado é exposto ao usuário.
Por que a Apple está aplicando a regra agora
O gatilho é volume. A submissão de apps de vibe coding à App Store cresceu, segundo dado citado pelo The Information e replicado pela TheNextWeb, 84% em um único trimestre — vale registrar que esse número remonta a uma única reportagem original, não a uma medição independente de mercado, então trate-o como sinal de tendência, não como consenso estatístico do setor. Em paralelo, a Sensor Tower registrou alta de 56% ano a ano em lançamentos de apps iOS em dezembro de 2025 e 54,8% em janeiro de 2026, e a própria Apple recebeu 557 mil novas submissões em 2025 — o maior volume desde 2016.
Para a Apple, o risco de fundo é estrutural: um app que gera e executa outros apps dentro de si mesmo é, na prática, uma loja de aplicativos dentro do aplicativo — o tipo de coisa que a Apple já restringe há anos por razões de segurança e de controle de receita da própria App Store. A crítica que desenvolvedores levantaram, segundo a Exame — incluindo Dhruv Amin, fundador do app Anything, e a própria Replit, que se disse "surpresa e decepcionada" com o bloqueio de uma funcionalidade já aprovada mais de 100 vezes antes — é de inconsistência: a Apple aplicaria a regra de forma seletiva, enquanto integra capacidades semelhantes de geração de código no próprio Xcode. A Apple, por sua vez, nega mirar a categoria como tal, tratando o episódio como aplicação padrão de uma guideline já existente.
O que é rejeitado vs. o que passa: o padrão por trás das decisões
| Tende a ser rejeitado | Tende a passar |
|---|---|
| App gera código nativo iOS a partir de prompt e o executa dentro do próprio container | App abre o resultado gerado em navegador externo, fora do container revisado |
| Webview embutida que altera a funcionalidade do app depois de aprovado | Ferramenta se posiciona como educacional, com código-fonte visível e editável pelo usuário |
| App genérico, sem funcionalidade nativa própria — "site reembalado" (Guideline 4.2) | App com funcionalidade mínima suficiente além da geração de código |
| Chaves de API expostas, ausência de tratamento de erro — sinais de qualidade típicos de código gerado sem revisão | App tratado como produto, com refatoração de segurança e qualidade antes da submissão |
O checklist técnico de segurança que precisa vir antes de qualquer submissão — SAST/DAST, varredura de segredo, cobertura OWASP — já está detalhado em segurança do vibe coding: checklist antes de publicar; este artigo cobre a camada seguinte, específica de distribuição em loja de aplicativos, que aquele checklist não aborda.
App público na App Store vs. app corporativo interno: as regras não são iguais
Este é o ponto mais importante para o público que a Jetpacks atende — grandes empresas brasileiras que usam vibe coding majoritariamente para ferramentas internas, não para produtos de consumo publicados na loja pública. A relevância do bloqueio de março de 2026 muda completamente dependendo do canal de distribuição escolhido:
- App público na App Store — passa pela App Review normal e está sujeito à Guideline 2.5.2 como qualquer outro. É o cenário exato dos casos Replit, Vibecode e Anything.
- Custom Apps via Apple Business Manager (ABM) — o mecanismo recomendado pela Apple hoje para apps corporativos internos não tem isenção da revisão: cada Custom App passa pelo mesmo processo de App Review, com as mesmas guidelines, incluindo a 2.5.2 — só não fica visível na loja pública. Uma empresa que distribui uma ferramenta interna via ABM está exposta ao mesmo risco de rejeição que um app de consumo.
- Apple Developer Enterprise Program (distribuição in-house) — este é o único caminho que de fato escapa da App Review, incluindo a 2.5.2, porque a distribuição nunca passa pela App Store: os apps são assinados com certificado corporativo e instalados diretamente via MDM nos dispositivos da própria empresa. Tem requisitos próprios (mais de 100 funcionários, pessoa jurídica formal) e a própria Apple desencoraja seu uso fora dos casos em que Custom Apps ou distribuição Ad Hoc/TestFlight não resolvem — não é um caminho livre de atrito, é um programa à parte com elegibilidade própria.
Na prática: se sua empresa constrói ferramentas internas com vibe coding e distribui via MDM corporativo com o Enterprise Program, o bloqueio de março de 2026 não se aplica diretamente. Se a distribuição passa por Custom Apps do ABM ou pela loja pública, a mesma governança de compliance de plataforma descrita aqui vale integralmente.
Checklist prático antes de submeter um app vibe-coded à App Store
Antes de qualquer submissão à revisão da Apple — pública ou via ABM —, valide:
- O app executa ou gera código que altera sua própria funcionalidade dentro do container? Se sim, é candidato direto a rejeição pela 2.5.2, salvo enquadramento educacional explícito.
- O resultado gerado abre em navegador externo ou dentro de uma webview do próprio app? Abrir externamente reduz o risco de enquadramento na 2.5.2.
- O app tem funcionalidade nativa própria suficiente, além da geração de conteúdo/código? Apps genéricos caem também na Guideline 4.2 (funcionalidade mínima).
- A saída do vibe coding já foi tratada como produto — refatorada, com separação de lógica/UI/dados, autenticação e tratamento de erro — ou ainda está no estágio de protótipo? O ponto em que um protótipo precisa "graduar" para engenharia formal antes de virar produto está detalhado em vibe coding para MVP.
- Qual é o canal de distribuição real — App Store pública, Custom Apps via ABM, ou Enterprise/in-house via MDM? A resposta muda o nível de exposição ao risco descrito aqui.
O que fazer se o app for rejeitado ou removido
A Apple oferece um processo formal de apelação (App Review Board) para contestar uma rejeição ou remoção — mas o caminho mais eficaz, segundo os próprios relatos de desenvolvedores afetados citados pela Exame e pela MacRumors, é tratar a rejeição como sinal de que o app ainda está no estágio de protótipo, não de produto pronto para distribuição pública. Isso significa refatorar a saída do vibe coding antes de resubmeter — não apenas ajustar texto de metadata — e, quando o caso permitir, considerar migrar a distribuição para dentro do próprio MDM corporativo em vez de insistir na loja pública, se o uso for majoritariamente interno.
Onde isso se encaixa na governança de vibe coding da empresa
Compliance de plataforma é a quarta camada de um framework de risco que já existe neste hub: a matriz de risco de negócio e governança decide o que pode ser construído e por quem; o checklist de segurança garante que o código não tenha vulnerabilidade antes do deploy; a dívida técnica do vibe coding cobre o custo de manutenção depois que o app está em produção; e este artigo cobre a camada que só existe quando a distribuição sai do ambiente interno da empresa: as regras da própria plataforma de destino. Um inventário atualizado de todo o portfólio de apps vibe coded — incluindo canal de distribuição de cada um — é o que permite responder rápido quando uma regra de plataforma muda; veja como estruturar esse inventário em governança de portfólio de vibe coding.
FAQ
O que é a Guideline 2.5.2 da App Store da Apple?
É a cláusula das App Store Review Guidelines que proíbe um app de baixar, instalar ou executar código que altera sua própria funcionalidade sem passar por nova revisão da Apple — com exceção para apps educacionais cujo código gerado fica totalmente visível e editável pelo usuário. Não é uma regra nova; o que mudou em 2026 foi a aplicação dela contra apps de vibe coding.
Por que a Apple está bloqueando apps feitos com vibe coding em 2026?
Porque o volume de apps que geram e executam código a partir de prompt cresceu rápido o suficiente para a Apple tratá-los como risco estrutural — um app que gera outros apps dentro de si mesmo é, na prática, uma loja de aplicativos paralela, o tipo de coisa que a Apple já restringe por razões de segurança e de controle da própria App Store.
Um app criado com Replit ou outra ferramenta de vibe coding pode ser publicado na App Store?
Pode, mas com risco de rejeição sob a Guideline 2.5.2 se a função central do app for gerar e executar código dentro do próprio container. Abrir o resultado gerado em navegador externo, garantir funcionalidade nativa própria e refatorar a saída antes de submeter reduzem substancialmente esse risco.
Apps internos da empresa também precisam passar pela revisão da Apple?
Depende do canal. Apps distribuídos como Custom Apps via Apple Business Manager passam pela mesma App Review de apps públicos, incluindo a 2.5.2. Apps distribuídos via Apple Developer Enterprise Program (in-house, via MDM) não passam pela App Review — é o único canal que escapa dessa revisão, mas com requisitos próprios de elegibilidade.
Qual a diferença entre Apple Business Manager, Custom Apps e o Apple Developer Enterprise Program?
Apple Business Manager é a plataforma de gestão corporativa da Apple; Custom Apps é o mecanismo dentro dela para publicar apps internos, que ainda passa pela App Review padrão. O Apple Developer Enterprise Program é um programa à parte, com requisito de mais de 100 funcionários, que permite distribuição in-house via MDM sem passar pela App Review — o único caminho que escapa da Guideline 2.5.2.
O Google Play tem a mesma restrição que a Apple contra apps de IA generativa?
Não há registro de uma ação equivalente e específica do Google Play até o momento. O Play tem uma política de conteúdo gerado por IA, mas ela é voltada à moderação de conteúdo ofensivo, não à restrição de execução de código gerado dinamicamente como faz a Guideline 2.5.2 da Apple. Vale tratar isso como assimetria observada entre as duas lojas, não como garantia formal de que o Android está livre desse tipo de risco no futuro.
O que fazer se meu app foi rejeitado ou removido citando a Guideline 2.5.2?
Existe apelação formal junto à Apple, mas o caminho mais eficaz costuma ser tratar a rejeição como sinal de que o app ainda está em estágio de protótipo — refatorar a saída do vibe coding antes de resubmeter, e, se o uso for majoritariamente interno, avaliar migrar a distribuição para o MDM corporativo via Enterprise Program em vez de insistir na loja pública.
Conclusão: a governança de vibe coding não para na segurança do código
Empresas que já levaram vibe coding a sério em segurança técnica e matriz de risco de negócio ainda podem ser pegas de surpresa por uma camada que fica fora do controle direto delas: a regra da própria plataforma de distribuição. A diferença entre um app corporativo interno distribuído com segurança e um app público exposto a risco de rejeição está, na maior parte dos casos, na escolha do canal — não na qualidade do código gerado.
Se sua empresa está avaliando vibe coding para produtos que vão além do uso interno — ou já tem apps publicados e quer confirmar que o canal de distribuição está correto —, o diagnóstico gratuito da Jetpacks mapeia, em uma conversa de 30 a 45 minutos, o portfólio de vibe coding da empresa e o método Flight Plan aplicado com a governança certa para cada canal de distribuição — pública, corporativa via ABM ou in-house via MDM.
Descubra onde a IA gera mais resultado na sua empresa.
Comece com um diagnóstico gratuito: mapa de impacto por área e o desenho de um primeiro piloto medível, sem compromisso.