Varför vibe-kodade betalappar blir avvisade från App Store

Vibe-kodade betalappar blir avvisade från App Store i högre utsträckning än nästan allt annat i granskningskön, och orsakerna har vanligtvis ingenting med kodkvalitet att göra. En vibe-kodad app — en app du byggt genom att beskriva vad du vill ha för en AI-assistent och sedan publicerat vad den skrev — kan se helt professionell ut. Apples granskning betygsätter inte koden. Den kontrollerar vem som skickade in appen, vilken betalningsmekanism som hanterar vilken typ av varor, om hårdvarubehörigheter godkändes separat och om granskaren kan slutföra en verklig transaktion. Det är exakt de saker som en AI-assistent inte kan generera.

Detta är väggen alla stöter på efter att ha byggt ett anpassat kassasystem med en AI-modell: koden finns där på en eftermiddag, men att få in den på en iPhone as a real checkout app är en efterlevnadsprocess, inte en kodningsuppgift.

Dirigerade din AI betalningar genom fel system?

Det vanligaste skälet till avvisning är att fel betalningsmekanism används för de varor som säljs, och AI-assistenter är ovanligt bra på att göra fel här. Apples App Review Guidelines drar en hård gräns. Digitalt innehåll och tjänster som konsumeras i appen måste använda Apples köp inuti app (in-app purchase) enligt riktlinje 3.1.1. Fysiska varor och tjänster i den verkliga världen — en kaffe, en klippning, en skickad beställning — måste göra motsatsen enligt riktlinje 3.1.5(a): de får inte använda köp inuti app överhuvudtaget, utan kräver en extern betalningsmetod.

En kodningsmodell återskapar det betalningsmönster som dominerade dess träningsdata — standardkod för köp inuti app från prenumerationsguider, eller ett SDK för webbkassa från e-handelsexempel — utan att någonsin fråga vad du säljer. Be den om "en app som tar emot betalningar" och du får ett av de två alternativen, valt utifrån statistik snarare än Apples regler. Reglerna skiljer sig dessutom mellan olika marknader: efter Epic-domen 2025 får appar på den amerikanska marknaden länka ut till externa köpalternativ för digitala varor, men det undantaget gäller endast i USA. En app som distribueras globalt måste fortfarande uppfylla den strängare regeln överallt annars.

Får du ens skicka in en betalapp?

Apple förväntar sig att appar som hanterar pengar eller finansiella tjänster skickas in av den institution som faktiskt utför tjänsterna, med de licenser som krävs i varje region där appen är tillgänglig — det är riktlinje 3.2.1. En enskild utvecklare som lanserar en AI-genererad betalapp är inte ett licensierat finansiellt institut, och det är inte heller en byrå som skickar in en app åt en kund. Att erbjuda appen i ett land där licenserna för penningöverföring saknas leder till samma avvisning, bara med en annan poststämpel.

Apples granskare utvärderar inte om ditt efterlevnadsprogram är bra; de kontrollerar om rätt enhet har skickat in appen och avvisar den om så inte är fallet. Ingen prompt kan lösa det.

Varför är kontaktlös betalning en helt egen godkännandeprocess?

Att ta emot kontaktlösa kort på en iPhone kräver behörigheten "Tap to Pay on iPhone" — en separat ansökan till Apple, oberoende av appgranskningen, som beviljas till en juridisk person snarare än till en kodbas. Utvecklingsbehörigheten blir vanligtvis klar på en dag eller två. Publiceringsbehörigheten går via Apples driftsteam, tar vanligtvis en till två veckor och kräver att man samarbetar med en betaltjänstleverantör som stöds. En AI-assistent skriver gladeligen koden för kontaktlös betalning utan att nämna något av detta; skickar du in appen innan behörigheten har beviljats kommer den att nekas.

Kortbetalningar på plats drar också med sig krav som Apple inte äger: certifierad läsarhårdvara, EMV-regler och PCI-omfattning för allt som rör kortdata. Inget av det kommer från en modell som skriver Swift.

Kan granskaren faktiskt slutföra en transaktion?

Riktlinje 2.1, App Completeness (Fullständig app), dödar i tysthet fler betalappar än vad betalningsreglerna gör. Granskarna måste kunna testa hela appen, inklusive betalningsflödet. En betalapp kräver vanligtvis ett inlösenavtal, identitetsverifiering och ibland ett bankkonto — saker som en granskare inte kan registrera sig för under själva granskningen. Vibe-kodade bidrag misslyckas ständigt här, eftersom utvecklaren ofta aldrig har skaffat ett riktigt inlösenavtal själv; appen har bara testats med testdata som AI:n genererade tillsammans med koden. Utan ett fungerande demokonto och ett sätt att köra en testtransaktion avvisas appen som ofullständig, och varje ny inskickning kostar ytterligare en granskningscykel.

Så vad är det som faktiskt levereras?

Den svåra delen var aldrig koden. En AI-assistent kan producera ett fungerande kassagränssnitt på en eftermiddag, men distribution i App Store är ett gatlopp av behörigheter, licenser och granskningspolicyer som ligger helt utanför vad en prompt kan nå. Demon fungerar; infrastrukturen finns inte än.

För een handlare som säljer fysiska varor är den praktiska slutsatsen enklare: ställ dig inte i kön. Ditt företag behöver en fungerande kassa, inte en egen app i App Store — licensiering, hårdvarucertifiering och granskningskostnader är bara rimliga för företag vars faktiska produkt är själva betalningsprogramvaran. Kör kassan på en POS-plattform som redan har tagit de kostnaderna (Final är byggt exakt så — betalningar via Final Pay med certifierad terminalhårdvara, utan någon egen app att publicera), och lägg pengarna du sparar på granskningscykler på saker som faktiskt ökar intäkterna, som ett snabbare kassaflöde och lägre effektiva kortavgifter.

Apples granskningsprocess finns av goda skäl — betalappar som inte fungerar skadar riktiga människor. Det är bara inte en process som de flesta handlare någonsin behöver gå igenom, oavsett vem eller vad som skrev appen.