Dlaczego aplikacje płatnicze pisane metodą „vibe-codingu” są odrzucane z App Store

Aplikacje płatnicze pisane metodą „vibe-codingu” są odrzucane z App Store częściej niż niemal jakiekolwiek inne aplikacje w kolejce do weryfikacji, a powody zazwyczaj nie mają nic wspólnego z jakością kodu. Aplikacja stworzona tą metodą — czyli taka, którą zbudowałeś, opisując asystentowi AI swoje wymagania i publikując to, co napisał — może wyglądać identycznie jak profesjonalne dzieło. Weryfikacja Apple nie ocenia kodu. Sprawdza ona, kto przesłał aplikację, jaki mechanizm płatności obsługuje dany typ towarów, czy uprawnienia sprzętowe zostały zatwierdzone osobno oraz czy weryfikator może sfinalizować rzeczywistą transakcję. To są dokładnie te rzeczy, których asystent AI nie potrafi wygenerować.

To jest ściana, na którą trafia każdy po zbudowaniu niestandardowego punktu sprzedaży za pomocą modelu AI: kod powstaje w jedno popołudnie, ale umieszczenie go na iPhonie jako prawdziwej aplikacji kasowej to proces zgodności z przepisami, a nie zadanie programistyczne.

Czy Twoje AI skierowało płatności przez niewłaściwy system?

Najczęstszym powodem odrzucenia jest użycie niewłaściwego mechanizmu płatności dla sprzedawanych towarów, a asystenci AI wyjątkowo często się w tym mylą. Wytyczne dotyczące recenzowania aplikacji w App Store stawiają twardą granicę. Treści cyfrowe i usługi konsumowane wewnątrz aplikacji muszą korzystać z systemu zakupów w aplikacji Apple zgodnie z Wytyczną 3.1.1. Towary fizyczne i usługi w świecie rzeczywistym — kawa, strzyżenie, wysłane zamówienie — muszą robić coś przeciwnego zgodnie z Wytyczną 3.1.5(a): nie mogą w ogóle korzystać z zakupów w aplikacji i wymagają zewnętrznej metody płatności.

Model kodujący powiela ten wzorzec płatności, który dominował w jego danych treningowych — szablonowy kod zakupów w aplikacji z poradników o subskrypcjach lub SDK kasy internetowej z przykładów e-commerce — nigdy nie pytając, co właściwie sprzedajesz. Poproś go o „aplikację, która przyjmuje płatności”, a otrzymasz jedno z dwóch rozwiązań, wybranych na podstawie statystyk, a nie zasad Apple. Zasady te różnią się również w zależności od rynku: po wyroku w sprawie Epic z 2025 roku aplikacje w sklepie w USA mogą odsyłać do zewnętrznych opcji zakupu towarów cyfrowych, ale to wyłączenie dotyczy wyłącznie Stanów Zjednoczonych. Aplikacja dystrybuowana na całym świecie nadal musi spełniać surowsze reguły we wszystkich innych krajach.

Czy w ogóle wolno Ci zgłosić aplikację płatniczą?

Apple wymaga, aby aplikacje obsługujące zarządzanie pieniędzmi lub usługi finansowe były zgłaszane przez instytucję, która faktycznie świadczy te usługi, posiadającą wymagane licencje w każdym regionie, w którym aplikacja jest dostępna — to Wytyczna 3.2.1. Indywidualny twórca wydający wygenerowaną przez AI aplikację płatniczą nie jest licencjonowaną instytucją finansową, podobnie jak agencja zgłaszająca ją w imieniu klienta. Oferowanie aplikacji w kraju, w którym nie ma licencji na obrót pieniężny, kończy się takim samym odrzuceniem, tylko z innym uzasadnieniem geograficznym.

Weryfikatorzy Apple nie oceniają, czy Twój program zgodności z przepisami jest dobry; sprawdzają, czy aplikację przesłał właściwy podmiot, i odrzucają ją, jeśli tak nie jest. Żaden prompt tego nie naprawi.

Dlaczego funkcja Tap to Pay wymaga osobnego procesu zatwierdzania?

Przyjmowanie kart zbliżeniowych na iPhonie wymaga uprawnienia Tap to Pay on iPhone — to osobny wniosek do Apple, niezależny od weryfikacji aplikacji, przyznawany podmiotowi prawnemu, a nie samej bazie kodu. Uprawnienie deweloperskie jest zazwyczaj przyznawane w dzień lub dwa. Uprawnienie do publikacji przechodzi przez zespół operacyjny Apple, co zwykle zajmuje od jednego do dwóch tygodni i wymaga współpracy ze wspieranym dostawcą usług płatniczych. Asystent AI chętnie napisze kod dla Tap to Pay, nie wspominając o żadnej z tych rzeczy; jeśli prześlesz aplikację przed przyznaniem uprawnienia, zostanie ona odrzucona.

Akceptacja kart fizycznych niesie za sobą również wymagania, które nie należą do Apple: certyfikowany sprzęt czytnika, zasady EMV oraz zakres PCI dla wszystkiego, co dotyka danych karty. Nic z tego nie powstanie z modelu piszącego w języku Swift.

Czy weryfikator może rzeczywiście dokończyć transakcję?

Wytyczna 2.1, Kompletność aplikacji, po cichu uśmierca więcej aplikacji płatniczych niż same zasady dotyczące płatności. Weryfikatorzy muszą mieć możliwość przetestowania całej aplikacji, w tym procesu płatności. Aplikacja płatnicza zazwyczaj wymaga konta handlowego, weryfikacji tożsamości, a czasem konta bankowego — rzeczy, których weryfikator nie może założyć podczas procesu oceny. Zgłoszenia aplikacji pisanych metodą „vibe-codingu” stale tutaj przepadają, ponieważ twórca często sam nigdy nie skonfigurował prawdziwego konta handlowego; aplikacja była testowana wyłącznie na makietach danych wygenerowanych przez AI. Bez działającego konta demonstracyjnego i możliwości przeprowadzenia transakcji testowej aplikacja jest odrzucana jako niekompletna, a każde ponowne przesłanie to kolejny cykl weryfikacji.

Co więc faktycznie trafia na rynek?

Trudną częścią nigdy nie był kod. Asystent AI potrafi stworzyć działający interfejs kasy w jedno popołudnie, ale dystrybucja w App Store to droga przez mękę pełna uprawnień, licencji i polityk weryfikacji, które leżą całkowicie poza zasięgiem jakiegokolwiek promptu. Demo działa; infrastruktura nie istnieje.

Dla sprzedawcy oferującego towary fizyczne praktyczny wniosek jest prostszy: nie stawaj w tej kolejce. Twój biznes potrzebuje działającej kasy, a nie własnej pozycji w App Store — koszty licencji, certyfikacji sprzętu i weryfikacji mają sens tylko dla firm, których produktem jest samo oprogramowanie płatnicze. Prowadź sprzedaż na platformie POS, która już wzięła te koszty na siebie (Final jest zbudowany dokładnie w ten sposób — płatności przez Final Pay z certyfikowanym sprzętem terminalowym, bez konieczności publikowania własnej aplikacji) i przeznacz budżet na rzeczy, które zwiększają przychody, takie jak szybszy proces obsługi klienta przy kasie i niższe rzeczywiste opłaty kartowe.

Proces weryfikacji Apple istnieje z ważnych powodów — wadliwe aplikacje finansowe szkodzą prawdziwym ludziom. Po prostu nie jest to proces, który większość sprzedawców musi kiedykolwiek przechodzić, bez względu na to, kto lub co napisało aplikację.