Kvifor vibe-koda betalingsappar vert avviste frå App Store

Vibe-koda betalingsappar vert avviste frå App Store i høgare grad enn nesten alt anna i vurderingskøen, og årsakene har vanlegvis ingenting med kodekvalitet å gjere. Ein vibe-koda app – ein du har bygd ved å beskrive kva du vil ha til ein AI-assistent og sende inn det han skreiv – kan sjå heilt lik ut som profesjonelt arbeid. Apple si vurdering karakterset ikkje koden. Ho sjekkar kven som sende inn appen, kva betalingsmekanisme som handterer kva type varer, om maskinvarerettar vart godkjende separat, og om kontrolløren kan fullføre ein reell transaksjon. Dette er akkurat dei tinga ein AI-assistent ikkje kan generere.

Dette er veggen alle treff etter å ha bygd ein tilpassa POS med ein AI-modell: koden er klar på ein ettermiddag, men å få han inn på ein iPhone som ein ekte utsjekkings-app er ein samsvarsprosess, ikkje ein kodejobb.

Ruta AI-en din betalingar gjennom feil system?

Det vanlegaste avvisingsgrunnlaget er bruk av feil betalingsmekanisme for varene som vert selde, og AI-assistentar er uvanleg gode til å gjere feil her. Apple sine retningslinjer for App Store dreg ei hard grense. Digitalt innhald og tenester som vert brukte inne i appen må bruke Apple sine kjøp i app under retningslinje 3.1.1. Fysiske varer og tenester i den verkelege verda – ein kaffi, ein hårklipp, ein sendt ordre – må gjere det motsette under retningslinje 3.1.5(a): dei kan ikkje bruke kjøp i app i det heile, og krev ein ekstern betalingsmetode.

Ein kodemodell reproduserer det betalingsmønsteret som dominerte treningsdataa hans – standardkode for kjøp i app frå abonnementrettleiingar, eller eit SDK for nettutsjekking frå e-handelsdøme – utan nokon gong å spørje kva du sel. Be han om "ein app som tek imot betalingar", og du får ein av dei to, vald ut frå statistikk i staden for Apple sine reglar. Reglane varierer også etter marknad: etter Epic-dommen i 2025 kan appar på den amerikanske marknaden lenkje ut til eksterne kjøpsalternativ for digitale varer, men det unntaket gjelder berre i USA. Ein app som vert distribuert globalt må framleis oppfylle den strengare regelen alle andre stader.

Har du i det heile tatt lov til å sende inn ein betalings-app?

Apple forventar at appar som handterer pengar eller finansielle tenester vert sende inn av institusjonen som faktisk utfører desse tenestene, med dei nødvendige lisensane i kvar region der appen er tilgjengeleg – det er retningslinje 3.2.1. Ein enkeltutviklar som sender inn ein AI-generert betalings-app er ikkje ein lisensiert finansinstitusjon, og det er heller ikkje eit byrå som sender inn ein på vegner av ein kunde. Å tilby appen i eit land der lisensen for pengeflytting ikkje er på plass, gir same avvising med eit anna poststempel.

Apple sine kontrollørar vurderer ikkje om samsvarsprogrammet ditt er godt; dei sjekkar om rett eining sende inn appen, og avviser viss det ikkje er tilfelle. Ingen prompt kan fikse det.

Kvifor er tap-to-pay ein eigen godkjenningsprosess?

Å ta imot kontaktlause kort på ein iPhone krev rettigheita "Tap to Pay on iPhone" – ein eigen søknad til Apple, uavhengig av sjølve app-vurderinga, gjeven til ein juridisk eining i staden for til ein kodebase. Utviklingsrettigheita vert vanlegvis godkjend på ein dag eller to. Produksjonsrettigheita går gjennom Apple sitt driftsteam, tek vanlegvis éi til to veker, og krev samarbeid med ein støtta betalingsleverandør. Ein AI-assistent skriv gladeleg tap-to-pay-koden utan å nemne noko av dette; sender du inn før rettigheita er gjeven, vert appen avvist.

Fysisk kortbetaling dreg også med seg krav Apple ikkje rår over: sertifisert lesarmaskinvare, EMV-reglar og PCI-omfang for alt som rører kortdata. Ingenting av det kjem ut av ein modell som skriv Swift.

Kan kontrolløren faktisk fullføre ein transaksjon?

Retningslinje 2.1, Fullstendig app, stoppar i det stille fleire betalingsappar enn sjølve betalingsreglane gjer. Kontrollørar må kunne teste heile appen, inkludert betalingsflyten. Ein betalings-app krev vanlegvis ein innløysaravtale, identitetskontroll, og av og til ein bankkonto – ting ein kontrollør ikkje kan registrere seg for under vurderinga. Vibe-koda innsendingar feilar her heile tida, fordi utviklaren ofte aldri har sett opp ein ekte innløysaravtale sjølv; appen vart berre testa mot fiktive data som AI-en genererte saman med koden. Utan ein fungerande demokonto og ein måte å køyre ein testtransaksjon på, vert appen avvist som ufullstendig, og kvar nye innsending kostar ein ny vurderingsrunde.

Så kva er det som faktisk vert levert?

Den vanskelege delen var aldri koden. Ein AI-assistent kan produsere eit fungerande utsjekkingsgrensesnitt på ein ettermiddag, men distribusjon i App Store er eit hinderløp av rettar, lisensiering og retningslinjer som ligg heilt utanfor det eit prompt kan nå. Demoen fungerer; infrastrukturen finst ikkje enno.

For ein forhandlar som sel fysiske varer, er den praktiske konklusjonen enklare: ikkje still deg i den køen. Bedrifta di treng ein fungerande utsjekkingsflyt, ikkje ein eigen app i App Store – lisensieringa, maskinvaresertifiseringa og meirarbeidet med vurderingar gir berre meining for selskap der sjølve betalingsprogramvaren er produktet. Køyr disken på ein POS-plattform som allereie har teke desse kostnadene (Final er bygd akkurat slik – betalingar gjennom Final Pay med sertifisert terminalmaskinvare, ingen eigen app å publisere), og bruk pengane frå vurderingsrundane på ting som aukar omsetninga, som ein raskare utsjekkingsflyt og lågare effektive kortgebyr.

Apple sin vurderingsprosess finst av gode grunnar – penge-appar som sviktar skadar ekte menneske. Det er berre ikkje ein prosess dei fleste forhandlarar nokon gong treng å bestå, uansett kven eller kva som skreiv appen.