Por que aplicativos de pagamento criados por intuição (vibe-coded) são rejeitados na App Store

Os aplicativos de pagamento criados por intuição (vibe-coded) são rejeitados na App Store em uma taxa mais alta do que quase qualquer outra coisa na fila de revisão, e os motivos geralmente não têm nada a ver com a qualidade do código. Um aplicativo criado por intuição — aquele que você construiu descrevendo o que queria para um assistente de IA e publicando o que ele escreveu — pode parecer indistinguível de um trabalho profissional. A revisão da Apple não avalia o código. Ela verifica quem enviou o aplicativo, qual mecanismo de pagamento lida com qual tipo de produto, se as permissões de hardware foram aprovadas separadamente e se o revisor consegue concluir uma transação real. Essas são exatamente as coisas que um assistente de IA não consegue gerar.

Essa é a parede em que todos batem depois de criar um POS personalizado com um modelo de IA: o código existe em uma tarde, mas colocá-lo em um iPhone como um aplicativo de checkout real é um processo de conformidade, não uma tarefa de programação.

A sua IA roteou os pagamentos pelo sistema errado?

A rejeição mais comum é usar o mecanismo de pagamento errado para os produtos que estão sendo vendidos, e os assistentes de IA são excepcionalmente bons em errar nisso. As Diretrizes de Revisão da App Store da Apple definem um limite rígido. Conteúdos e serviços digitais consumidos dentro do aplicativo devem usar as compras dentro do aplicativo da Apple sob a Diretriz 3.1.1. Bens físicos e serviços do mundo real — um café, um corte de cabelo, um pedido enviado — devem fazer o oposto sob a Diretriz 3.1.5(a): eles não podem usar compras dentro do aplicativo de forma alguma e exigem um método de pagamento externo.

Um modelo de programação reproduz o padrão de pagamento que dominou seus dados de treinamento — código padrão de compra dentro do aplicativo de tutoriais de assinatura ou um SDK de checkout web de exemplos de e-commerce — sem nunca perguntar o que você está vendendo. Peça a ele "um aplicativo que aceita pagamentos" e você obterá um dos dois, escolhido por estatísticas e não pelas regras da Apple. As regras também mudam conforme a loja: após a decisão da Epic em 2025, os aplicativos na loja dos EUA podem incluir links para opções de compra externa de bens digitais, mas essa exceção se aplica apenas nos Estados Unidos. Um aplicativo distribuído mundialmente ainda precisa satisfazer a regra mais rígida em todos os outros lugares.

Você tem permissão para enviar um aplicativo de pagamento?

A Apple espera que os aplicativos que lidam com gestão financeira ou serviços financeiros sejam enviados pela instituição que realmente realiza esses serviços, com o licenciamento exigido em cada região onde o aplicativo está disponível — essa é a Diretriz 3.2.1. Um desenvolvedor solo que publica um aplicativo de pagamentos gerado por IA não é uma instituição financeira licenciada, e uma agência que envia um para um cliente também não é. Oferecer o aplicativo em um país onde o licenciamento para movimentação de dinheiro não existe resulta na mesma rejeição com um selo diferente.

Os revisores da Apple não avaliam se o seu programa de conformidade é bom; eles verificam se a entidade correta enviou o aplicativo e o rejeitam quando não é o caso. Nenhum comando corrige isso.

Por que o tap-to-pay tem seu próprio processo de aprovação?

Aceitar cartões por aproximação em um iPhone exige a permissão Tap to Pay on iPhone — uma solicitação separada para a Apple, independente da revisão do aplicativo, concedida a uma entidade legal e não a uma base de código. A permissão de desenvolvimento geralmente é liberada em um ou dois dias. A permissão de publicação passa pela equipe de operações da Apple, normalmente leva de uma a duas semanas e exige o trabalho com um provedor de serviços de pagamento compatível. Um assistente de IA escreverá alegremente o código de tap-to-pay sem mencionar nada disso; envie antes que a permissão seja concedida e o aplicativo será rejeitado.

A aceitação com cartão presente também traz requisitos que não pertencem à Apple: hardware de leitura certificado, regras EMV e escopo PCI para qualquer coisa que toque em dados de cartão. Nada disso sai de um modelo escrevendo Swift.

O revisor consegue realmente concluir uma transação?

A Diretriz 2.1, Integridade do Aplicativo, elimina silenciosamente mais aplicativos de pagamento do que as regras de pagamentos. Os revisores devem ser capazes de testar o aplicativo completo, incluindo o fluxo de pagamento. Um aplicativo de pagamento normalmente exige uma conta de comerciante, verificação de identidade, às vezes uma conta bancária — coisas para as quais um revisor não pode se cadastrar durante a revisão. Os envios criados por intuição falham constantemente aqui, porque o criador muitas vezes nunca provisionou uma conta de comerciante real; o aplicativo foi testado apenas com dados fictícios que a IA gerou junto com ele. Sem uma conta de demonstração funcional e uma maneira de executar uma transação de teste, o aplicativo é rejeitado como incompleto, e cada reenvio custa outro ciclo de revisão.

Então, o que realmente é publicado?

A parte difícil nunca foi o código. Um assistente de IA pode produzir uma interface de checkout funcional em uma tarde, mas a distribuição na App Store é um desafio de permissões, licenciamento e políticas de revisão que estão totalmente fora do alcance de um comando. A demonstração funciona; a infraestrutura não existe.

Para um comerciante que vende bens físicos, a conclusão prática é mais simples: não entre na fila. Sua empresa precisa de um checkout funcional, não de sua própria listagem na App Store — os custos de licenciamento, certificação de hardware e revisão só fazem sentido para empresas cujo produto é o próprio software de pagamentos. Opere o balcão em uma plataforma de POS que já absorveu esses custos (o Final foi construído exatamente dessa forma — pagamentos através do Final Pay com hardware de terminal certificado, sem aplicativo próprio para publicar) e invista o dinheiro que seria gasto em ciclos de revisão em coisas que geram receita, como um fluxo de checkout mais rápido e taxas de cartão efetivas mais baixas.

O processo de revisão da Apple existe por boas razões — aplicativos financeiros que falham prejudicam pessoas reais. Só não é um processo pelo qual a maioria dos comerciantes precisa passar, não importa quem ou o que escreveu o aplicativo.