De ce aplicațiile de plată dezvoltate prin „vibe-coding” sunt respinse din App Store

Aplicațiile de plată dezvoltate prin vibe-coding sunt respinse din App Store într-un ritm mai mare decât aproape orice altceva din coada de revizuire, iar motivele nu au de obicei nicio legătură cu calitatea codului. O aplicație dezvoltată prin vibe-coding — una pe care ați construit-o descriind ceea ce doriți unui asistent IA și lansând ceea ce a scris acesta — poate arăta identic cu o lucrare profesională. Procesul de revizuire de la Apple nu notează codul. Acesta verifică cine a trimis aplicația, ce mecanism de plată gestionează fiecare tip de bunuri, dacă drepturile pentru hardware au fost aprobate separat și dacă evaluatorul poate finaliza o tranzacție reală. Acestea sunt exact lucrurile pe care un asistent IA nu le poate genera.

Acesta este zidul de care se lovește toată lumea după ce construiește un punct de vânzare personalizat cu un model de IA: codul este gata într-o după-amiază, dar instalarea acestuia pe un iPhone ca aplicație reală de plată este un proces de conformitate, nu o sarcină de programare.

A direcționat IA-ul dumneavoastră plățile prin sistemul greșit?

Cea mai frecventă respingere este cauzată de utilizarea unui mecanism de plată greșit pentru bunurile vândute, iar asistenții IA sunt neobișnuit de predispuși să greșească acest lucru. Ghidul de revizuire a aplicațiilor de la Apple trasează o linie clară. Conținutul digital și serviciile consumate în interiorul aplicației trebuie să utilizeze sistemul de achiziții în aplicație de la Apple, conform Directivei 3.1.1. Bunurile fizice și serviciile din lumea reală — o cafea, o tunsură, o comandă expediată — trebuie să facă exact contrariul, conform Directivei 3.1.5(a): acestea nu pot folosi deloc achizițiile în aplicație și necesită o metodă de plată externă.

Un model de programare reproduce modelul de plată care a dominat în datele sale de antrenament — fie codul standard pentru achiziții în aplicație din tutorialele de abonamente, fie un SDK de finalizare a comenzilor web din exemplele de e-commerce — fără a întreba vreodată ce anume vindeți. Cereți-i „o aplicație care acceptă plăți” și veți obține una dintre cele două variante, aleasă pe criterii statistice și nu conform regulilor Apple. De asemenea, regulile variază în funcție de regiune: după decizia Epic din 2025, aplicațiile din magazinul din SUA pot include linkuri către opțiuni externe de achiziție pentru bunuri digitale, dar această excepție se aplică doar în Statele Unite. O aplicație distribuită la nivel mondial trebuie să respecte în continuare regula mai strictă în toate celelalte regiuni.

Aveți măcar permisiunea de a trimite o aplicație de plată?

Apple solicită ca aplicațiile care gestionează servicii financiare sau de administrare a banilor să fie trimise de instituția care prestează efectiv acele servicii, deținând licențele necesare în fiecare regiune în care aplicația este disponibilă — aceasta este Directiva 3.2.1. Un dezvoltator independent care lansează o aplicație de plăți generată de IA nu este o instituție financiară licențiată, și nici o agenție care trimite o aplicație pentru un client. Oferirea aplicației într-o țară în care nu există licența de transfer de bani atrage aceeași respingere, doar cu o altă justificare.

Evaluatorii Apple nu analizează dacă programul dumneavoastră de conformitate este bun; ei verifică dacă aplicația a fost trimisă de entitatea corectă și o resping dacă nu este cazul. Nicio instrucțiune nu poate rezolva asta.

De ce este Tap to Pay un proces de aprobare separat?

Acceptarea cardurilor contactless pe un iPhone necesită dreptul „Tap to Pay on iPhone” — o solicitare separată către Apple, independentă de revizuirea aplicației, acordată unei entități juridice și nu unei baze de cod. Dreptul de dezvoltare se aprobă de obicei în una sau două zile. Dreptul de publicare trece prin echipa de operațiuni Apple, durează de obicei între una și două săptămâni și necesită colaborarea cu un furnizor de servicii de plată acceptat. Un asistent IA va scrie cu plăcere codul pentru tap-to-pay fără a menționa nimic din toate acestea; dacă trimiteți aplicația înainte ca dreptul să fie acordat, aceasta va fi respinsă.

Acceptarea plăților cu cardul fizic atrage, de asemenea, cerințe care nu depind de Apple: echipamente hardware de citire certificate, reguli EMV și standarde PCI pentru orice element care atinge datele cardului. Nimic din toate acestea nu este generat de un model care scrie în Swift.

Poate evaluatorul să finalizeze efectiv o tranzacție?

Directiva 2.1, Integritatea Aplicației, respinge în liniște mai multe aplicații de plată decât o fac regulile de plată în sine. Evaluatorii trebuie să poată testa aplicația în întregime, inclusiv fluxul de plată. O aplicație de plată necesită, de obicei, un cont de comerciant, verificarea identității și uneori un cont bancar — lucruri pentru care un evaluator nu se poate înregistra în timpul procesului de revizuire. Aplicațiile trimise prin vibe-coding eșuează constant aici, deoarece dezvoltatorul adesea nu a configurat niciodată un cont de comerciant real; aplicația a fost testată doar cu date fictive generate de IA. Fără un cont demo funcțional și o modalitate de a rula o tranzacție de test, aplicația este respinsă ca fiind incompletă, iar fiecare retransmitere costă un alt ciclu de revizuire.

Deci, ce se lansează de fapt?

Partea dificilă nu a fost niciodată codul. Un asistent IA poate produce o interfață de plată funcțională într-o după-amiază, dar distribuția în App Store este un parcurs dificil de drepturi, licențe și politici de revizuire care se află complet în afara limitelor unei instrucțiuni. Versiunea demo funcționează; infrastructura nu există încă.

Pentru un comerciant care vinde bunuri fizice, concluzia practică este mai simplă: nu intrați în această coadă de așteptare. Afacerea dumneavoastră are nevoie de un proces de plată funcțional, nu de propria listare în App Store — costurile cu licențierea, certificarea hardware și revizuirea au sens doar pentru companiile al căror produs este software-ul de plată în sine. Gestionați vânzările pe o platformă POS care a absorbit deja aceste costuri (Final este construit exact în acest mod — plăți prin Final Pay cu echipamente hardware de terminal certificate, fără a fi nevoie să publicați o aplicație proprie) și investiți banii economisiți din ciclurile de revizuire în lucruri care generează venituri, cum ar fi un flux de plată mai rapid și comisioane efective mai mici pentru carduri.

Procesul de revizuire de la Apple există din motive întemeiate — aplicațiile financiare care eșuează afectează oameni reali. Doar că nu este un proces pe care majoritatea comercianților trebuie să îl parcurgă vreodată, indiferent de cine sau ce a scris aplicația.