Miksi vibe-koodatut maksusovellukset hylätään App Storessa

Vibe-koodatut maksusovellukset hylätään App Storessa useammin kuin lähes mikään muu sovellustyyppi arviointijonossa, eikä syillä yleensä ole mitään tekemistä koodin laadun kanssa. Vibe-koodattu sovellus — sellainen, jonka rakensit kuvailemalla toiveesi tekoälyavustajalle ja julkaisemalla sen kirjoittaman koodin — voi näyttää täysin ammattilaistyöltä. Applen arvioinnissa ei arvostella koodia. Siinä tarkistetaan, kuka sovelluksen on lähettänyt, mikä maksutapa käsittelee minkäkin tyyppisiä tuotteita, onko laitteistooikeudet hyväksytty erikseen ja pystyykö tarkastaja suorittamaan todellisen maksutapahtuman. Nämä ovat juuri niitä asioita, joita tekoälyavustaja ei pysty generoimaan.

Tämä on seinä, johon kaikki törmäävät rakennettuaan räätälöidyn kassajärjestelmän tekoälymallilla: koodi on valmis iltapäivässä, mutta sen saaminen iPhoneen todelliseksi kassasovellukseksi on vaatimustenmukaisuusprosessi, ei koodaustehtävä.

Reitittikö tekoälysi maksut väärän järjestelmän kautta?

Yleisin hylkäyssyy on väärän maksutavan käyttäminen myytäville tuotteille, ja tekoälyavustajat ovat poikkeuksellisen hyviä tekemään tämän virheen. Applen App Review Guidelines -ohjeet vetävät tähän tarkan rajan. Sovelluksen sisällä kulutettavan digitaalisen sisällön ja palveluiden on käytettävä Applen sovelluksen sisäistä ostoa (in-app purchase) säännön 3.1.1 mukaisesti. Fyysisten tuotteiden ja reaalimaailman palveluiden — kuten kahvin, hiustenleikkuun tai lähetetyn tilauksen — on toimittava päinvastoin säännön 3.1.5(a) mukaisesti: ne eivät saa käyttää sovelluksen sisäistä ostoa lainkaan, vaan ne vaativat ulkoisen maksutavan.

Koodausmalli toistaa sitä maksutapaa, joka hallitsi sen koulutusdataa — joko sovelluksen sisäisten ostojen valmiskoodia tilausoppaista tai verkkokassan SDK-pakettia verkkokauppaesimerkeistä — kysymättä koskaan, mitä olet myymässä. Jos pyydät siltä "sovellusta, joka ottaa vastaan maksuja", saat toisen näistä tilastollisen todennäköisyyden, et Applen sääntöjen perusteella. Säännöt vaihtelevat myös maakohtaisesti: vuoden 2025 Epic-päätöksen jälkeen Yhdysvaltojen sovelluskaupassa olevat sovellukset voivat linkittää ulkoisiin ostovaihtoehtoihin digitaalisille tuotteille, mutta tämä poikkeus koskee vain Yhdysvaltoja. Maailmanlaajuisesti jaettavan sovelluksen on silti täytettävä tiukempi sääntö kaikkialla muualla.

Onko sinulla edes oikeutta lähettää maksusovellusta?

Apple edellyttää, että rahanhallintaa tai rahoituspalveluita käsittelevät sovellukset lähettää se instituutio, joka todellisuudessa tarjoaa kyseiset palvelut, ja että sillä on vaadittavat lisenssit jokaisella alueella, jolla sovellus on saatavilla — tämä on sääntö 3.2.1. Yksin toimiva kehittäjä, joka julkaisee tekoälyllä luodun maksusovelluksen, ei ole lisensoitu rahoituslaitos, eikä sellainen ole myöskään toimisto, joka lähettää sovelluksen asiakkaansa puolesta. Sovelluksen tarjoaminen maassa, jossa rahansiirtolisenssiä ei ole olemassa, johtaa samaan hylkäykseen eri postileimalla.

Applen tarkastajat eivät arvioi, onko vaatimustenmukaisuusohjelmasi hyvä; he tarkistavat, onko oikea taho lähettänyt sovelluksen, ja hylkäävät sen, jos näin ei ole. Mikään kehote ei korjaa tätä.

Miksi lähimaksu on oma hyväksymisprosessinsa?

Lähikorttimaksujen vastaanottaminen iPhonella vaatii Tap to Pay on iPhone -käyttöoikeuden (entitlement) — se on erillinen hakemus Applelle, riippumaton sovelluksen arvioinnista, ja se myönnetään oikeushenkilölle eikä koodikannalle. Kehityskäyttöoikeus hyväksytään yleensä päivässä tai parissa. Julkaisukäyttöoikeus kulkee Applen operaatiotiimin kautta, kestää yleensä yhdestä kahteen viikkoa ja vaatii yhteistyötä tuetun maksupalveluntarjoajan kanssa. Tekoälyavustaja kirjoittaa mielellään lähimaksukoodin mainitsematta mitään tästä; jos lähetät sovelluksen ennen käyttöoikeuden myöntämistä, se hylätään heti.

Korttimaksujen vastaanottaminen paikan päällä tuo mukanaan myös vaatimuksia, joita Apple ei hallitse: sertifioidut lukijalaitteet, EMV-säännöt ja PCI-vaatimukset kaikelle, mikä koskee korttitietoja. Mitään näistä ei synny Swift-koodia kirjoittavasta mallista.

Pystyykö tarkastaja todella suorittamaan maksutapahtuman loppuun?

Sääntö 2.1, App Completeness (Sovelluksen viimeistely), kaataa hiljaisesti useampia maksusovelluksia kuin varsinaiset maksusäännöt. Tarkastajien on voitava kokeilla koko sovellusta, mukaan lukien maksutapahtuma. Maksusovellus vaatii yleensä kauppiastilin, henkilöllisyyden vahvistamisen ja joskus pankkitilin — asioita, joita tarkastaja ei voi luoda arvioinnin aikana. Vibe-koodatut hakemukset epäonnistuvat tässä jatkuvasti, koska kehittäjä ei useinkaan ole itse hankkinut todellista kauppiastiliä; sovellusta on testattu vain tekoälyn sen ohessa generoimalla testimateriaalilla. Ilman toimivaa demotiliä ja mahdollisuutta suorittaa testimaksu sovellus hylätään puutteellisena, ja jokainen uusi yritys maksaa taas yhden arviointikierroksen.

Mikä siis todella päätyy julkaisuun?

Vaikea osuus ei koskaan ollut koodi. Tekoälyavustaja voi luoda toimivan kassaliittymän iltapäivässä, mutta App Store -jakelu on käyttöoikeuksien, lisensoinnin ja arviointikäytäntöjen esterata, joka on täysin kehotteiden ulottumattomissa. Demo toimii; infrastruktuuria ei ole vielä olemassa.

Fyysisiä tuotteita myyvälle kauppiaalle käytännön johtopäätös on yksinkertaisempi: älä edes asetu jonoon. Yrityksesi tarvitsee toimivan kassan, ei omaa sovellusta App Storeen — lisensointi, laitesertifiointi ja arviointivaiva ovat järkeviä vain yrityksille, joiden varsinainen tuote on maksualustaohjelmisto. Pyöritä kassaa POS-alustalla, joka on jo kattanut nämä kustannukset (Final on rakennettu juuri näin — maksut kulkevat Final Payn kautta sertifioidulla maksupäätelaitteistolla, ilman tarvetta julkaista omaa sovellusta), ja sijoita arviointikierroksiin kuluvat rahat asioihin, jotka kasvattavat liikevaihtoa, kuten nopeampaan kassavirtaan ja alhaisempiin korttimaksukuluihin.

Applen arviointiprosessi on olemassa hyvästä syystä — vialliset rahasovellukset vahingoittavat oikeita ihmisiä. Se ei vain ole prosessi, joka useimpien kauppiaiden tarvitsee koskaan läpäistä, riippumatta siitä, kuka tai mikä sovelluksen on kirjoittanut.