Perché le app di pagamento create tramite "vibe-coding" vengono rifiutate dall'App Store

Le app di pagamento create tramite vibe-coding vengono rifiutate dall'App Store a un tasso più elevato rispetto a quasi qualsiasi altra cosa nella coda di revisione, e i motivi di solito non hanno nulla a che fare con la qualità del codice. Un'app creata tramite vibe-coding — ovvero un'app creata descrivendo ciò che si desidera a un assistente IA e distribuendo ciò che ha scritto — può sembrare indistinguibile da un lavoro professionale. La revisione di Apple non valuta il codice. Controlla chi ha inviato l'app, quale meccanismo di pagamento gestisce quale tipo di beni, se le abilitazioni hardware sono state approvate separatamente e se il revisore può completare una transazione reale. Queste sono esattamente le cose che un assistente IA non può generare.

Questo è il muro contro cui tutti si scontrano dopo aver costruito un punto vendita personalizzato con un modello di IA: il codice esiste in un pomeriggio, ma portarlo su un iPhone come una vera app di checkout è un processo di conformità, non un compito di programmazione.

La vostra IA ha instradato i pagamenti attraverso il sistema sbagliato?

Il rifiuto più comune riguarda l'uso del meccanismo di pagamento errato per i beni venduti, e gli assistenti IA sono insolitamente bravi a sbagliare questo aspetto. Le Linee guida per la revisione dell'App Store di Apple tracciano una linea netta. I contenuti e i servizi digitali consumati all'interno dell'app devono utilizzare l'acquisto in-app di Apple ai sensi della Linea guida 3.1.1. I beni fisici e i servizi del mondo reale — un caffè, un taglio di capelli, un ordine spedito — devono fare il contrario ai sensi della Linea guida 3.1.5(a): non possono utilizzare affatto l'acquisto in-app e richiedono un metodo di pagamento esterno.

Un modello di programmazione riproduce il pattern di pagamento che ha dominato i suoi dati di addestramento — codice standard per acquisti in-app da tutorial sugli abbonamenti, o un SDK di checkout web da esempi di e-commerce — senza mai chiedere cosa state vendendo. Chiedetegli "un'app che accetta pagamenti" e otterrete una delle due opzioni, scelta dalle statistiche piuttosto che dalle regole di Apple. Le regole cambiano anche in base alla vetrina: dopo la sentenza Epic del 2025, le app sulla vetrina statunitense possono rimandare a opzioni di acquisto esterne per i beni digitali, ma tale deroga si applica solo negli Stati Uniti. Un'app distribuita in tutto il mondo deve comunque soddisfare la regola più severa ovunque altrove.

Siete autorizzati a inviare un'app di pagamento?

Apple si aspetta che le app che gestiscono la gestione del denaro o i servizi finanziari siano inviate dall'istituto che effettivamente esegue tali servizi, con le licenze richieste in ogni regione in cui l'app è disponibile — questa è la Linea guida 3.2.1. Uno sviluppatore solista che distribuisce un'app di pagamenti generata dall'IA non è un istituto finanziario autorizzato, e non lo è nemmeno un'agenzia che ne invia una per un cliente. Offrire l'app in un paese in cui non esiste la licenza per il trasferimento di denaro comporta lo stesso rifiuto con un timbro postale diverso.

I revisori di Apple non valutano se il vostro programma di conformità è valido; controllano se l'entità corretta ha inviato l'app e la rifiutano in caso contrario. Nessun prompt può risolvere questo problema.

Perché il tap-to-pay ha un processo di approvazione a sé stante?

Accettare carte contactless su un iPhone richiede l'abilitazione Tap to Pay on iPhone — una richiesta separata ad Apple, indipendente dalla revisione dell'app, concessa a un'entità legale piuttosto che a una base di codice. L'abilitazione allo sviluppo di solito viene approvata in un giorno o due. L'abilitazione alla pubblicazione passa attraverso il team operativo di Apple, richiede in genere da una a due settimane e necessita della collaborazione con un fornitore di servizi di pagamento supportato. Un assistente IA scriverà felicemente il codice tap-to-pay senza menzionare nulla di tutto ciò; se si invia l'app prima che l'abilitazione sia concessa, l'app verrà respinta.

L'accettazione con carta presente trascina con sé anche requisiti che non appartengono ad Apple: hardware di lettura certificato, regole EMV e ambito PCI per qualsiasi cosa tocchi i dati della carta. Niente di tutto questo viene fuori da un modello che scrive in Swift.

Il revisore può effettivamente completare una transazione?

La Linea guida 2.1, Completezza dell'app, boccia silenziosamente più app di pagamento rispetto alle regole sui pagamenti stesse. I revisori devono essere in grado di testare l'app completa, incluso il flusso di pagamento. Un'app di pagamento richiede in genere un conto commerciante, la verifica dell'identità, a volte un conto bancario — cose per cui un revisore non può registrarsi durante la revisione. Gli invii di app create tramite vibe-coding falliscono costantemente qui, perché lo sviluppatore spesso non ha mai predisposto un vero conto commerciante; l'app è stata testata solo con dati fittizi generati dall'IA insieme ad essa. Senza un account demo funzionante e un modo per eseguire una transazione di prova, l'app viene rifiutata in quanto incompleta, e ogni nuovo invio costa un altro ciclo di revisione.

Quindi cosa viene effettivamente distribuito?

La parte difficile non è mai stata il codice. Un assistente IA può produrre un'interfaccia di checkout funzionante in un pomeriggio, ma la distribuzione sull'App Store è un percorso a ostacoli fatto di abilitazioni, licenze e politiche di revisione che si trova completamente al di fuori della portata di qualsiasi prompt. La demo funziona; l'infrastruttura non esiste ancora.

Per un commerciante che vende beni fisici, la conclusione pratica è più semplice: non entrate in coda. La vostra attività ha bisogno di un checkout funzionante, non di una propria presenza sull'App Store — i costi di licenza, certificazione hardware e gestione della revisione hanno senso solo per le aziende il cui prodotto è il software di pagamento stesso. Gestite la cassa su una piattaforma POS che ha già assorbito questi costi (Final è costruita esattamente in questo modo — pagamenti tramite Final Pay con hardware terminale certificato, nessuna app propria da pubblicare), e investite il denaro dei cicli di revisione in cose che generano entrate, come un flusso di checkout più rapido e commissioni effettive sulle carte più basse.

Il processo di revisione di Apple esiste per ottime ragioni — le app finanziarie che falliscono danneggiano le persone reali. Solo che non è un processo che la maggior parte dei commercianti ha bisogno di superare, indipendentemente da chi o cosa abbia scritto l'app.