Uwaga, sierpień 2026: ten wpis pochodzi z wcześniejszego wydania i opisuje ówczesny podział na plany. W wersji 1.2.0 AlcoLog połączył plan Pro z Premium, więc teraz jest jeden płatny plan. Przy połączeniu nic nie zniknęło, a każdy, kto miał Pro, przeszedł na Premium bez dodatkowych kosztów.

Jeśli zaraz wydajesz wersję 1.0 aplikacji na iOS z subskrypcjami, zakupami w aplikacji, towarzyszącą aplikacją na Watch, widżetami albo jakimkolwiek pozycjonowaniem bliskim zdrowiu, proces App Review będzie trudniejszy, niż sugeruje dokumentacja. Ten wpis opisuje jeden cykl premiery (cztery odrzucenia w ciągu pięciu dni, pięciu recenzentów, jeden plik binarny) i schematy, dzięki którym dało się go przetrwać. Dzielę się nim, bo to jedna z najsłabiej opisanych części wydawania poważnej niezależnej aplikacji, a wersja udokumentowana (sesje WWDC, strona z wytycznymi App Review, fora dla deweloperów) nie zgadza się z codzienną rzeczywistością.

Jeśli jesteś w trakcie cyklu i szukasz konkretnych poprawek, przejdź od razu do części „Co poprawić przed wysłaniem” i „Schematy, które warto zrozumieć”. Osobista oś czasu jest w drugiej połowie, jeśli chcesz poznać kontekst.

# Co poprawić przed wysłaniem

Oto punkty, które wypłynęły w czterech odrzuceniach. Jeśli poprawisz je z góry, usuniesz większość powodów do odrzucenia wersji 1.0 z wrażliwej kategorii z subskrypcjami.

# Hierarchia cen na ekranach zakupu subskrypcji

Wytyczne Apple Human Interface Guidelines dotyczące subskrypcji są jednoznaczne w kwestii prezentacji cen. Kwota, która zostanie pobrana, musi być najbardziej widocznym elementem cenowym. Instynkt marketingowy (niech zniżka wygląda jak wygrana) jest tu błędny. Instynkt zgodności z zasadami (niech pobierana kwota będzie typograficznym bohaterem) jest właściwy.

W praktyce oznacza to, że cena regularna powinna być największym i najgrubszym elementem. Cena wprowadzająca lub promocyjna powinna być mniejsza, z wyraźnym oznaczeniem „Pierwszy okres:”. Unikaj procentowych plakietek w małych znacznikach (używaj „LAUNCH OFFER”, a nie „25% OFF”). Egzekwowanie zasady 3.1.2© Payments and Subscriptions w tym punkcie jest spójne u wszystkich recenzentów.

# Wyraźna ścieżka usuwania danych

Nawet jeśli twoje „konto” to tylko dobrowolny anonimowy identyfikator, zasada 5.1.1(v) Apple wymaga podpisanej, widocznej i natychmiastowej ścieżki usuwania. Wyłączenie przełącznika jako domyślne usunięcie wygląda od strony dewelopera na zgodne z zasadami, ale nie spełnia obecnego sposobu ich egzekwowania.

Wbuduj wyraźny przycisk „Delete My Data” w ekran prywatności lub ustawień od pierwszej wersji. Dodaj alert z potwierdzeniem. Upewnij się, że otaczający go tekst opisuje faktyczne działanie usuwania, a nie tymczasowy harmonogram, który zamierzasz później poprawić.

# Przejrzyj Info.plist pod kątem szczątkowych deklaracji

Tryby działania w tle, pobieranie w tle, uprawnienia lokalizacji, deklaracje HealthKit i podobne wpisy w Info.plist mogą miesiącami leżeć nieużywane, podczas gdy kod się zmienia. Zostają oznaczone, gdy nie odpowiadają żadnej faktycznej funkcji. Egzekwowanie zasady 2.5.4 Software Requirements jest tu mechaniczne i jednoznaczne.

Konkretnie: każdy wpis UIBackgroundModes musi odpowiadać funkcji, która go naprawdę używa. Jeśli twoja aplikacja deklaruje „location” jako tryb działania w tle, ale nigdy nie używasz ciągłej lokalizacji w tle i masz allowsBackgroundLocationUpdates = false, usuń tę deklarację. Monitorowanie regionów jej nie wymaga. Przegląd zajmuje dziesięć minut i oszczędza jeden cykl odrzucenia.

Pole Polityki prywatności w App Store Connect jest dobrze znane. Wymóg Warunków korzystania jest znany mniej. Jeśli używasz standardowej umowy EULA Apple, dodaj link do Warunków korzystania w opisie aplikacji. Jeśli używasz własnej umowy EULA, dodaj ją w polu na niestandardową EULA w App Store Connect.

Sama strona z warunkami powinna ujawniać wszystkie płatne produkty z długością subskrypcji, ceną i zasadami odnawiania. Większość zespołów ma te elementy rozrzucone po osobnych stronach albo zakopane w polityce prywatności. Zbierz je na jednej stronie z warunkami, którą recenzent przeczyta w dwie minuty.

# Filmy App Preview: używaj surowych nagrań ekranu

Trójwymiarowe makiety telefonów, ramki urządzeń i stylizowane kompozycje marketingowe zależą od uznania recenzenta w ramach zasady 2.3.4 Accurate Metadata. Publiczna strona z wytycznymi nie zakazuje wprost ramek urządzeń, ale wewnętrzne materiały szkoleniowe, z których korzystają recenzenci, najwyraźniej tak. Zwykłe nagrania ekranu w natywnej rozdzielczości są bezpieczne bez żadnych wątpliwości.

Zachowaj marketingową oprawę na własną stronę, media społecznościowe i Reddita. W miejsce App Preview wstaw nagrania ekranu. Różnica w konwersji między „dopracowanym podglądem z makietą” a „surowym nagraniem ekranu” jest niewielka. Spadek ryzyka jest duży.

# Wyraźna nawigacja do zakupów w aplikacji w notatkach dla App Review

Recenzenci mają na aplikację od 5 do 15 minut. Nie zawsze znajdą każdy zakup w aplikacji przypisany do wersji. Jeśli twoje zakupy są dostępne różnymi ścieżkami (osobne ekrany zakupu, osobne karty, głębsza nawigacja), dodaj w notatkach dla App Review ścieżkę stuknięcie po stuknięciu do każdego z nich.

Format, który działa:

Premium subscriptions and Lifetime IAP: Settings tab > Premium card > Get Premium button > Premium upgrade sheet Pro subscriptions and Lifetime IAP: Settings tab > Pro card > Get Pro button Consumable Tip Jar items: Settings tab > scroll past tier cards > Tip Jar card > Show Tip Options

Brzmi to przesadnie. Zapobiega jednemu konkretnemu cyklowi odrzucenia (zasada 2.1(b) Information Needed), który inaczej kosztuje cię dzień.

# Zapas w kalendarzu między zgłoszeniem a zapowiedzianą datą premiery

Przy zgłoszeniu wersji 1.0 z subskrypcjami we wrażliwej kategorii zaplanuj co najmniej siedem dni kalendarzowych między pierwszym zgłoszeniem a publicznie zapowiedzianą datą premiery. Każdy cykl odrzucenia trwa mniej więcej 24 godziny, jeśli odpowiadasz szybko. Cztery cykle odrzucenia to realistyczny najgorszy scenariusz dla takich zgłoszeń.

Jeśli data premiery jest zapowiedziana na zewnątrz (skonfigurowane zamówienia przedpremierowe, zaplanowane wydarzenia w aplikacji, zarezerwowana kampania marketingowa, wysłane propozycje do dziennikarzy), siedem dni zapasu to minimum. Dziesięć dni jest wygodniejsze. Przy mniej niż siedmiu ryzykujesz, że przegapisz datę przez jedno proceduralne odrzucenie.

# Schematy, które warto zrozumieć

Kilka obserwacji z wnętrza cyklu, które nie są oczywiste z dokumentacji.

# Każde odrzucenie znajduje coś innego

Cztery odrzucenia wskazały punkty, które się nie pokrywały. Każdy recenzent miał dostęp do każdego ekranu, który poprzedni recenzent przepuścił. Pierwszy wskazał link do EULA w metadanych. Drugi wskazał trzy różne punkty w tym samym pliku binarnym (tryb działania w tle, prezentację cen, przycisk usuwania). Trzeci wskazał materiał marketingowy. Czwarty zadał pytanie o nawigację.

To nie błąd. Tak po prostu zbudowany jest App Review. Recenzje wydają się dotyczyć pojedynczych problemów, a nie całej aplikacji. Recenzenci zatrzymują się na pierwszym poważnym problemie, który wyłapią w swoim czasie. Nie muszą robić wyczerpujących audytów, a system nie nadaje statusu „wcześniej zatwierdzone” elementom, które zaakceptował poprzedni recenzent. Ta struktura stawia przepustowość instytucji ponad doświadczeniem dewelopera.

Wniosek: z żadnego pojedynczego przejścia recenzji nie dostaniesz pełnego audytu. Dostaniesz tylko to, co obecny recenzent wyłapie w swoim oknie czasowym, i musisz przyjąć, że następny recenzent może niezależnie wyłapać cokolwiek innego w kolejnym przejściu.

# Każde odrzucenie zwykle ma mniejszy zakres niż poprzednie

To luźny schemat, a nie gwarancja. Pierwsze odrzucenie jest często merytoryczne (brakujący wymóg, problem architektoniczny). Drugie wciąż jest merytoryczne, ale bardziej przypomina listę kontrolną. Trzecie dryfuje w stronę pobocznych metadanych. Czwarte bywa proceduralnym pytaniem, a nie odrzuceniem.

Powodem nie jest to, że aplikacja „robi się lepsza” z każdym przejściem. Powodem jest to, że obszar do sprawdzenia w pliku binarnym i metadanych kurczy się z każdym przejściem, bo wcześniej wskazane punkty zostają poprawione, a wcześniej przepuszczone przestają być w zakresie. Recenzenci niezależnie od siebie wyczerpują dostępną listę kontrolną, więc późniejsze recenzje mają mniej do znalezienia.

Ten schemat uspokaja, gdy jesteś w cyklu, ale nie licz na niego. Recenzent pod koniec cyklu wciąż może wyłapać coś merytorycznego, co wcześniejsi przeoczyli.

# Dokładność recenzentów bardzo się różni

W czterech recenzjach tego samego pliku binarnego rozrzut w tym, co znalazł każdy recenzent, był duży. Jeden znalazł trzy punkty. Inny znalazł jeden poboczny. Trzeci zadał pytanie, na które odpowiedź dawało stuknięcie karty na drugiej karcie aplikacji.

Nie masz wpływu na to, który recenzent dostanie twoje zgłoszenie w danym przejściu. Zaplanuj ten rozrzut. Nie zakładaj, że następne przejście będzie dokładniejsze albo łagodniejsze od poprzedniego. To niezależne próbki z szerokiego rozkładu.

# Zatwierdzenie w Beta App Review nie przesądza o zatwierdzeniu w pełnym App Review

Te dwa procesy mają różne zespoły i różne kryteria. Wersja, która przechodzi Beta z tymi samymi funkcjami, które zostają wskazane w recenzji produkcyjnej, to nie sprzeczność. To dwa różne procesy recenzji.

Jeśli używasz TestFlight, żeby potwierdzić gotowość do recenzji produkcyjnej, patrzysz na niewłaściwy sygnał. TestFlight wyłapuje problemy z poprawnością wersji i podstawową zgodnością. Produkcyjny App Review sprawdza pełny zakres egzekwowanych zasad. Nie są wymienne.

# We wrażliwych kategoriach czynniki kontroli się kumulują

Subskrypcje, zwłaszcza z ceną wprowadzającą lub okresem próbnym, automatycznie uruchamiają egzekwowanie zasady 3.1.2. Kategorie bliskie zdrowiu (alkohol, fitness, zdrowie psychiczne, sen) kierują uwagę recenzenta na zasadę 1.4.1 i twierdzenia medyczne. Funkcje wrażliwe dla prywatności (lokalizacja, HealthKit, anonimowe identyfikatory) uruchamiają kontrolę w ramach zasady 5.1.1. Pierwsze zgłoszenia wersji 1.0 uruchamiają pełne recenzje. Wydarzenia w aplikacji powiązane z datą premiery uruchamiają kontrolę metadanych.

Każdy z tych czynników z osobna da się opanować. Kumulują się jednak multiplikatywnie. Poważna premiera we wrażliwej kategorii, z subskrypcjami, kilkoma platformami i wydarzeniem w aplikacji, ma wszystkie czynniki aktywne naraz. Darmowe jednoekranowe narzędzie bez zakupów w aplikacji przechodzi w 2 minuty. Trudność twojej recenzji zależy od powagi i zakresu premiery, a nie od jakości aplikacji.

# Dokumentacja i egzekwowanie nie zawsze idealnie się pokrywają

Odrzucenie może powoływać się na wytyczne, których nie ma wprost na podlinkowanej publicznej stronie. Recenzenci pracują na wewnętrznych materiałach szkoleniowych, które pokrywają się z publicznymi wytycznymi App Review, ale nie są z nimi identyczne. Jeśli trafisz na odrzucenie, które nie zgadza się z publiczną dokumentacją, możesz uprzejmie się odwołać. Czasem decyzja zostaje zmieniona, czasem nie.

Gdy się odwołujesz, zrób to na piśmie w Resolution Center, w uporządkowanym akapicie, który cytuje publiczne wytyczne i prosi o wskazanie konkretnego stosowanego punktu. Unikaj frustracji w języku. Recenzent czyta odpowiedź z ograniczonym czasem; uważnie czytana jest ta odpowiedź, która to szanuje.

# Jak konstruktywnie odpowiadać na odrzucenia

Kilka praktycznych uwag o wymianie wiadomości w Resolution Center.

# Odpowiadaj tego samego dnia, jeśli możesz

Najszybszy sposób na wyjście z cyklu to utrzymywanie go w ruchu. Zegar każdego cyklu odrzucenia startuje od nowa, gdy odpowiadasz. Odpowiedzi tego samego dnia dają rozwiązanie w tym samym tygodniu; odpowiedzi po kilku dniach proporcjonalnie wydłużają cykl.

To wymaga, żeby twój zespół był zorganizowany pod szybkie wydawanie poprawek. Dla niezależnego dewelopera często oznacza to wyczyszczenie kalendarza na dni po zgłoszeniu. Okna zgłoszenia nie można traktować jako pracy w tle.

# Połącz poprawki w jedno ponowne zgłoszenie

Jeśli odrzucenie wskazuje trzy punkty, popraw wszystkie trzy przed ponownym zgłoszeniem. Nie wysyłaj odpowiedzi „dwa z trzech poprawione, pracuję nad trzecim”. Następny recenzent wyłapie zupełnie inne punkty; odpowiedź z częściową poprawką dokłada tylko kolejny cykl do kolejki.

# Dołączaj nagrania ekranu potwierdzające poprawki

Do każdej nietrywialnej poprawki dołącz 30-sekundowe nagranie ekranu pokazujące ją w działaniu. Proces usuwania, poprawioną prezentację cen, nową ścieżkę nawigacji. Recenzent chętniej zamknie sprawę w następnym przejściu, jeśli zobaczy poprawkę bez samodzielnego szukania jej w aplikacji.

# Poproś w odpowiedzi o pełną recenzję

Uprzejma prośba, żeby wszystkie pozostałe zastrzeżenia zostały zgłoszone razem w bieżącym przejściu, a nie rozłożone na kolejne cykle, jest rozsądna. Nie zawsze działa, ale czasem tak. Sformułowanie ma znaczenie: „Każdy dotychczas zgłoszony problem rozwiązaliśmy szybko i w dobrej wierze. Będziemy wdzięczni za pełną recenzję pod kątem wszystkich obowiązujących wytycznych w tym przejściu, aby ograniczyć kolejne cykle”.

To stawia recenzenta w sytuacji, w której jego następna odpowiedź albo zatwierdza aplikację, albo wymienia wszystkie pozostałe zastrzeżenia. Oba wyniki są lepsze niż kolejne odrzucenie z jednym punktem.

# Traktuj każde przejście jako niezależne

Kusi założenie, że następny recenzent przeczytał notatki poprzedniego. Prawdopodobnie nie. Każda odpowiedź w Resolution Center powinna być samodzielna i podsumowywać stan zgłoszenia dla kogoś, kto nie widział wcześniejszej rozmowy.

Oznacza to, że trochę powtórzeń między cyklami jest niezbędne. Szczegółowe notatki dla App Review, które zadziałały przy pierwszym recenzencie, warto dołączyć lub powtórzyć dla trzeciego. Nie zakładaj pamięci instytucjonalnej.

# Osobista oś czasu

Dla kontekstu tak wyglądało te pięć dni.

Wersję 22 wysłałem w sobotę po południu. Zgłoszenie obejmowało 4 automatycznie odnawiane subskrypcje, 2 dożywotnie zakupy jednorazowe, 5 elementów Tip Jar do wielokrotnego zakupu, opis aplikacji, zrzuty ekranu, filmy App Preview, wydarzenie w aplikacji powiązane z tygodniem premiery i zamówienia przedpremierowe skonfigurowane na datę premiery w 175 krajach.

Przez poprzednie sześć tygodni systematycznie usuwałem każdy problem, jaki mogłem przewidzieć. Notatki dla App Review zawierały przyjazne recenzentom wyjaśnienia tych części aplikacji, które najpewniej zwrócą uwagę. Informacje o przedsiębiorcy wymagane przez DSA zostały zatwierdzone tydzień wcześniej. Etykiety prywatności aplikacji były już opublikowane. Beta App Review przepuściło kilka wersji. Czułem się gotowy.

Dzień 2, 5:15: Pierwsze odrzucenie. Zasada 3.1.2©. Brak działającego linku do Warunków korzystania w metadanych App Store. Poprawka wydana tego samego dnia (dodany link do Warunków na ekranie przejścia na wyższy plan w aplikacji, rozszerzona strona warunków o wszystkie płatne produkty, zaktualizowany opis aplikacji). Cykl jednodniowy.

Dzień 4, 16:03: Drugie odrzucenie. Trzy punkty w jednej wiadomości. Zasada 2.5.4 (szczątkowy wpis „location” w UIBackgroundModes, którego nie powinno tam być). Zasada 3.1.2© (cena wprowadzająca pokazana wyraźniej niż pobierana kwota). Zasada 5.1.1(v) (wyłączenie przełącznika anonimowego identyfikatora wymagało wyraźnego, podpisanego przycisku usuwania). Poprawka wydana tego samego dnia (usunięty wpis w Info.plist, odwrócona hierarchia cen, dodany wyraźny przycisk „Delete Anonymous Data” z alertem potwierdzenia). Cykl jednodniowy.

Dzień 5, 17:05: Trzecie odrzucenie. Zasada 2.3.4 Accurate Metadata. Filmy App Preview pokazywały ekrany aplikacji na trójwymiarowych makietach telefonu. Notatka recenzenta wskazywała treści, które „w wystarczającym stopniu nie pokazują aplikacji w użyciu”, i wprost wymieniała ramki urządzeń.

Problem: publiczna strona z wytycznymi pod adresem developer.apple.com/app-store/app-previews/ nie zakazuje wprost ramek urządzeń. Najbliższa udokumentowana zasada to „Stay within the app”, z przykładami ujęć zza ramienia i fizycznej interakcji z urządzeniami. Żadna z nich nie miała zastosowania.

Do premiery zostały cztery dni, a łączne opóźnienie wynosiło już cztery dni, więc poszedłem na kompromis. Usunąłem filmy App Preview, żeby odblokować ponowne zgłoszenie. Uprzejmie poprosiłem o ponowne rozpatrzenie, jeśli przeoczyłem jakiś konkretny punkt wytycznych. Wysłałem uprzejmy, uporządkowany akapit z prośbą, żeby wszystkie pozostałe zastrzeżenia zgłoszono razem w tym przejściu. Usunięcie App Preview zostało. Na prośbę o ponowne rozpatrzenie nie dostałem bezpośredniej odpowiedzi.

Dzień 6, 19:23: Czwarta wiadomość. Zasada 2.1(b) Information Needed. Formalnie nie odrzucenie. Wstrzymanie recenzji, żeby zadać pytanie. Recenzent nie mógł znaleźć dwóch zakupów w aplikacji przypisanych do wersji i zapytał, gdzie są.

Dołączony zrzut ekranu poprawnie pokazywał pierwszy ekran zakupu. Drugi był na tym samym ekranie Ustawień, dostępny po stuknięciu karty tuż pod pierwszą kartą, do której recenzent bez problemu dotarł. Odpowiedziałem w niecałą godzinę, podając dokładną nawigację krok po kroku do wszystkich 11 zakupów w aplikacji.

Dzień 7, 20:30: Zatwierdzenie. Wersja przepuszczona. Zamówienia przedpremierowe aktywne. Tydzień premiery wyznaczony na 11 maja.

Te pięć dni było intensywne. Z perspektywy czasu żaden z nich nie był egzystencjalny, choć w środku cyklu tak to nie wyglądało. Łączne opóźnienie prawie kosztowało datę premiery, ale jednak nie. Wydany produkt to dokładnie to, co zbudowałem przed zgłoszeniem. Nic nie zostało wycięte, zmienione ani odłożone, żeby przejść recenzję.

# To, czego cykl nie wskazuje, też coś mówi

W czterech recenzjach elementy, o które martwiłem się najbardziej, nie zostały wskazane ani razu.

Funkcja wyniku nawyków (wynik 0-100 z czynnikami pomagającymi i szkodzącymi w sześciu ważonych filarach). Obszar śledzenia leków (wyłącznie rejestrowanie, bez żadnych porad). Model prywatności (bez kont, dane na urządzeniu, dobrowolne anonimowe udostępnianie z wyraźnym usuwaniem). Zapisy do HealthKit. Żaden z tych elementów, czyli części aplikacji najbardziej narażonych na zastrzeżenia dotyczące twierdzeń zdrowotnych lub prywatności, nie został wskazany w żadnej z czterech recenzji. Czterech niezależnych recenzentów patrzyło i wszyscy zdecydowali się ich nie wskazywać.

Wniosek dla twórców aplikacji z wrażliwych kategorii: proaktywne ujawnianie informacji ma znaczenie. Notatki dla App Review wyjaśniające metodologię, zastrzeżenia w aplikacji, staranne nazewnictwo, ostrożne ujęcie w opisie aplikacji. Nic z tego nie jest efektowne. Wszystko to przyczyniło się do tego, że czterech recenzentów z rzędu zdecydowało się nie wskazywać najbardziej dyskusyjnych elementów. Kategoria wiekowa 18+, ekran z zastrzeżeniem przy pierwszym uruchomieniu, wyraźny tekst „nie udzielamy porad medycznych” w odpowiednich miejscach. Wszystko to zadziałało.

Wskazywane były za to elementy proceduralne i mechaniczne. Hierarchia prezentacji cen. Deklaracje trybów działania w tle. Obecność linków w metadanych. Kompozycja materiałów marketingowych. Wykrywalność zakupów w aplikacji. Merytoryczne części aplikacji przechodziły w każdym przejściu.

# Ostatnie uwagi dla niezależnych deweloperów

Kilka obserwacji, które nie zmieściły się wyżej.

Tanie aplikacje, które widzisz w App Store, nie są traktowane łagodniej. Zostały zatwierdzone lata temu, gdy standardy były niższe, albo nie uruchamiają tych czynników kontroli, które uruchamia twoja poważna premiera. System nagradza mało pracochłonne aplikacje o niskim ryzyku niską kontrolą. Twój wysiłek i staranność są jednym z powodów, dla których twoja recenzja jest trudniejsza. To nie jest ocena jakości twojej aplikacji.

System nie ma ludzi, żeby dać ci takie doświadczenie, jakiego chcesz. App Review to pula wykonawców. Recenzenci obsługują dziesiątki aplikacji dziennie, po kilka minut na każdą. Są szkoleni z wytycznych App Review jako listy kontrolnej, a nie ze szczegółów interfejsu konkretnej aplikacji. Brak empatii wynika ze struktury, a nie z nastawienia do ciebie.

Opisywanie doświadczeń niezależnych twórców w końcu coś zmienia. Apple w ostatniej dekadzie wyraźnie poprawiło App Review. Część tej poprawy wynika z tego, że niezależni deweloperzy konsekwentnie opisywali swoje doświadczenia, a łączna presja rosła. Twoje pojedyncze odrzucenie nie sprawi, że jakiś recenzent zostanie przeszkolony od nowa. Uporządkowana suma doświadczeń niezależnych twórców w końcu zmienia jednak instytucję.

Najpewniej wydasz swój produkt dokładnie taki, jaki jest. Każda funkcja, o której wycięcie się martwiłem, trafiła do wydania nienaruszona. Cykl z czterema odrzuceniami wydawał się egzystencjalny, gdy trwał. Faktyczny wynik zmierzał do zatwierdzenia, dopóki odpowiadałem jasno i miałem w zanadrzu zapas czasu przed premierą.

Jeśli jesteś teraz w środku cyklu i zarywasz noce w Resolution Center: premiera się odbędzie. Odpowiadaj dalej. System nie jest wymierzony w ciebie. Produkt jest twój.

Ten wpis dokumentuje premierę AlcoLog, aplikacji na iOS do śledzenia drinków. AlcoLog pojawia się w App Store 11 maja 2026 roku, po opisanym wyżej cyklu. Aplikacja jest darmowa, z opcjonalnymi planami Premium, i już teraz można ją zamówić przedpremierowo w 175 krajach.

Jeśli jesteś deweloperem iOS i chcesz porównać doświadczenia z App Review, dobrym punktem wyjścia są społeczności niezależnych twórców iOS na r/iOSProgramming i Indie Hackers. Im dokładniej każdy z nas opisze, na co trafił, tym bardziej przydatna będzie ta suma dla następnej osoby.