Appka z Bolta ma zepsute logowanie albo płatności? Od czego zacząć naprawę
Jeśli appka wygenerowana w Bolcie albo Expo ma zepsute logowanie, płatności lub subskrypcje, użyj tej kolejności działań, zanim znowu zaczniesz łatać ekrany.
Kiedy appka z Expo wygenerowana przez AI zaczyna się sypać, founderzy zwykle gonią najbardziej widoczny bug.
To odwrotna kolejność.
Jeśli zepsuty jest auth albo płatności, problemem najczęściej nie jest jeden ekran. Problemem jest model stanu appki. Naprawianie pojedynczych błędów bez zrozumienia stanu to dokładnie ten mechanizm, który zamienia prosty prototyp w tygodnie łatania.
Najpierw rozpisz realne stany użytkownika
Zanim tkniesz kod, wypisz każdy stan, który appka musi obsłużyć:
wylogowany
zalogowany
onboarding nieukończony
onboarding ukończony
użytkownik darmowy
użytkownik na trialu
użytkownik płacący
użytkownik po wygaśnięciu
użytkownik z nieudanym zakupem
konto usunięte
Jeśli appka nie ma jasnego modelu tych stanów, bugi w logowaniu i płatnościach będą wracać.
Napraw auth przed płatnościami
Nie buduj logiki subskrypcji na niestabilnym logowaniu.
Auth musi odpowiadać na pytania:
kim jest ten użytkownik?
czy sesja wraca po otwarciu appki?
czy chronione ekrany potrafią się załadować, zanim auth będzie gotowy?
czy wylogowanie czyści stan lokalny?
czy usuwanie konta jest obsłużone?
czy onboarding wie, do którego użytkownika należy?
Jeśli to jest niejasne, logika płatności przyklei się do złych założeń.
Potem napraw logikę entitlementów
Paywall nie jest źródłem prawdy.
Appka potrzebuje warstwy entitlementów, która decyduje:
czy ten użytkownik ma dostęp do funkcji?
czy zakup się udał?
czy restore purchases zadziałał?
czy subskrypcja wygasła?
co się dzieje, gdy ładowanie produktów zawiedzie?
co się dzieje po restarcie appki?
Wiele appek zbudowanych przez AI ma ekran paywalla i pozwala użytkownikom go obejść, bo żaden system entitlementów nie istnieje.
Trzymaj kod płatności poza przypadkowymi ekranami
Logika płatności nie ma być kopiowana do każdego ekranu funkcji.
Zrób jeden centralny helper do zakupów i subskrypcji, który obsługuje:
ładowanie produktów
wywołanie zakupu
wywołanie restore
odświeżenie entitlementu
stan błędu zakupu
eventy analityczne
Wtedy ekrany zadają jedno proste pytanie: czy ten użytkownik ma dostęp do tej funkcji?
Dodaj analitykę w trakcie naprawy
Nie czekaj z tym do premiery.
Śledź:
rejestrację
ukończony onboarding
wyświetlenie paywalla
załadowanie produktu
start zakupu
zakończony zakup
nieudany zakup
kliknięcie restore
udany restore
użycie płatnej funkcji
Te eventy pokazują, czy Twoja naprawa faktycznie działa.
Unikaj pułapki łatania
Pułapka łatania wygląda tak:
prosisz AI o naprawę logowania
logowanie działa, psuje się onboarding
prosisz o naprawę onboardingu
onboarding działa, psuje się paywall
prosisz o naprawę paywalla
status płatny znika po restarcie
W tym momencie nie masz listy bugów. Masz problem architektoniczny.
Kiedy sięgnąć po sprint ratunkowy
Sięgnij po Ratunek dla aplikacji, kiedy auth, płatności i stan są splątane na tyle, że nie ufasz własnemu produktowi.
Audytuję kod, decyduję, co zostaje, i naprawiam albo przepisuję główny przepływ tak, żeby appkę dało się wypuścić razem z onboardingiem, subskrypcjami, analityką i przygotowaniem do App Store.
Do przeczytania dalej:
FAQ
Naprawiać najpierw auth czy płatności?
Najpierw auth. Logika płatności i entitlementów zależy od tego, czy wiadomo, kim jest użytkownik i w jakim jest stanie.
Dlaczego mój paywall od AI działa raz, a potem się psuje?
Bo wiele wygenerowanych paywalli to ekrany, nie systemy. Pomijają odświeżanie entitlementu, restore purchases, wygaśnięcie subskrypcji i stan po restarcie appki.