Guideline 3.1.1: kiedy zakup w aplikacji jest obowiązkowy

Guideline 3.1.1 wymaga zakupu w aplikacji (In-App Purchase) Apple, gdy tylko twoja aplikacja odblokowuje cyfrową treść albo funkcję: subskrypcję, pełną wersję, walutę w grze, treści premium. Odrzucenie z powodu 3.1.1 oznacza, że Apple znalazło inne wejście do tej treści: płatność na twojej stronie, klucz licencyjny, własny kod, przycisk prowadzący do strony płatności. Poprawka to zakup w aplikacji, chyba że twój przypadek mieści się w wyjątku albo w zasadzie regionalnej.

Publikuję własne aplikacje na iOS, a te, które mają subskrypcję, sprzedają ją przez zakup w aplikacji Apple. Nigdy nie dostałem odrzucenia 3.1.1 i nie będę udawał, że było inaczej. Ten poradnik opiera się na oficjalnym tekście, w wersji z 8 czerwca 2026, przeczytanej 15 października 2026, oraz na warunkach regionalnych opublikowanych przez Apple. Pokrewny przypadek subskrypcji, z dwoma prawdziwymi odrzuceniami, opisuję w poradniku o guideline 3.1.2.

Co mówi guideline 3.1.1?

Zasada 3.1.1, „In-App Purchase”, otwiera część 3.1 „Payments” w App Review Guidelines. Stąd tytuł maila: „Guideline 3.1.1 - Business - Payments - In-App Purchase”. Pierwsze zdanie mówi najważniejsze: żeby odblokować funkcje w aplikacji, „you must use in-app purchase”, musisz użyć zakupu w aplikacji. Apple wymienia subskrypcje, waluty w grach, poziomy, treści premium i pełną wersję.

Kolejne zdanie dotyczy obejść. Aplikacja nie może używać własnego mechanizmu do odblokowania treści: Apple wymienia klucze licencyjne, znaczniki rzeczywistości rozszerzonej, kody QR, kryptowaluty i portfele kryptowalut.

Ta sama zasada dodaje obowiązki, o których często się zapomina:

• kredyty i waluty kupione przez zakup w aplikacji nie wygasają, a każdy zakup, który da się przywrócić, ma mechanizm przywracania;
• płatna skrzynka albo losowanie („loot box”) pokazuje szanse na zdobycie każdego typu przedmiotu przed zakupem;
• cyfrową kartę podarunkową, bon albo kupon sprzedajesz w aplikacji przez zakup w aplikacji; fizyczna karta wysyłana pocztą może iść przez inny sposób płatności;
• aplikacja bez subskrypcji może dać okres próbny ograniczony w czasie, w formie darmowego zakupu w aplikacji o nazwie „XX-day Trial”, który przed startem podaje czas trwania, co zostanie utracone i ile trzeba będzie zapłacić;
• napiwki dla dewelopera są możliwe, przez zakup w aplikacji.

Sytuacje, które powodują odrzucenie 3.1.1

Co robi aplikacja	Dlaczego Apple odrzuca	Poprawka
Odblokowuje treść kupioną na twojej stronie	Brak odpowiednika w zakupie w aplikacji	Sprzedawać ją też przez zakup w aplikacji
Pokazuje „Zapłać na naszej stronie”	Odesłanie do innej płatności	Usunąć przycisk, chyba że jest wyjątek
Prosi o klucz licencyjny albo własny kod	Zakazany mechanizm odblokowania	Kody ofertowe Apple
Odblokowuje za kryptowalutę	Zakazany mechanizm odblokowania	Zakup w aplikacji
Sprzedaje kredyty, które wygasają	Obowiązek z 3.1.1	Trwałe kredyty i przywracanie
Sprzedaje skrzynkę bez prawdopodobieństw	Szanse niepokazane	Prawdopodobieństwa widoczne przed zakupem

Pierwszy wiersz jest najczęściej źle rozumiany. W odrzuceniu opublikowanym na forach Apple wiadomość mówi, że aplikacja „accesses digital content purchased outside the app”, czyli daje dostęp do treści kupionej gdzie indziej, „but that content isn't available to purchase using in-app purchase”. Apple nie ma pretensji o to, że masz stronę, która sprzedaje: ma pretensje o to, że aplikacja nie oferuje tego samego zakupu przez Apple.

Żeby dać darmowy dostęp albo zniżkę, Apple ma własny system: kody ofertowe (offer codes). Według dokumentacji StoreKit działają dla wszystkich typów zakupów w aplikacji: subskrypcji, produktów konsumpcyjnych i niekonsumpcyjnych. Tworzysz je w App Store Connect, a użytkownik wpisuje je w App Store albo w twojej aplikacji.

Wyjątki: kiedy zakup w aplikacji nie jest wymagany

Zasada 3.1.3 wymienia aplikacje, które mogą używać innego sposobu płatności. Oto tabela, której używam, żeby sprawdzić, gdzie pasuje projekt.

Twój przypadek	Wymagany zakup w aplikacji?	Zasada
Subskrypcja, pełna wersja, treść cyfrowa	Tak	3.1.1
Produkt fizyczny, usługa wykorzystywana poza aplikacją	Nie, inny sposób jest obowiązkowy	3.1.3(e)
Lekcja albo konsultacja na żywo, jeden na jeden	Nie	3.1.3(d)
Lekcja na żywo dla kilku osób	Tak	3.1.3(d)
Prasa, książki, muzyka, wideo kupione gdzie indziej	Nie, żeby mieć do nich dostęp	3.1.3(a)
Usługa wieloplatformowa kupiona na twojej stronie	Dostęp dozwolony, jeśli jest też w zakupie w aplikacji	3.1.3(b)
Narzędzie sprzedawane firmie dla jej pracowników	Nie	3.1.3(c)
Darmowa aplikacja towarzysząca narzędziu webowemu, bez zakupów	Nie	3.1.3(f)

Dwa ograniczenia. Aplikacja korzystająca z wyjątku nie może w aplikacji zachęcać do innego sposobu płatności, poza amerykańskim sklepem i przypadkami przewidzianymi przez Apple. Za to Apple precyzuje, że „Developers can send communications outside of the app”: możesz pisać do swoich użytkowników poza aplikacją, na przykład mailem.

Zasady według regionu w październiku 2026

Tu teksty zmieniają się szybko. Poniższe opiera się na dokumentach Apple przeczytanych 15 października 2026: przeczytaj je jeszcze raz, zanim zakodujesz zewnętrzną płatność.

Region	Co jest dozwolone oprócz zakupu w aplikacji
Stany Zjednoczone	Przyciski i linki do innej płatności, bez entitlementu
Unia Europejska	Alternatywna płatność w aplikacji i oferty poza aplikacją, z zasadami
Japonia, Brazylia, Korea Południowa	Własne programy, na wniosek o entitlement
Inne kraje	Żadnego przycisku, linku ani zachęty do innej płatności

Stany Zjednoczone

Zasada 3.1.1(a) precyzuje, że entitlementy „are not required for developers to include buttons, external links, or other calls to action in their United States storefront apps”. W amerykańskim sklepie przycisk do twojej strony jest więc dozwolony. Twój build jest wszędzie ten sam: jeśli dodajesz taki przycisk, aplikacja musi wiedzieć, w którym sklepie jest użytkownik. StoreKit podaje to przez Storefront.

Unia Europejska

Od 1 października 2026 obowiązują nowe warunki, według strony Apple o opcjach płatności w UE. Możesz zostać przy samym zakupie w aplikacji i niczego nie zmieniać. Możesz też zaproponować dostawcę płatności w aplikacji albo oferty poza aplikacją, na przykład na twojej stronie. Apple wymaga wtedy między innymi:

• entitlementu „StoreKit External Purchases or Offers”, a dla linku albo płatności w aplikacji systemowego okna informacyjnego;
• zakupu w aplikacji co najmniej tak samo widocznego jak druga opcja, gdy obie są na ekranie;
• żadnej wzmianki o tych płatnościach na twojej stronie w App Store;
• kontroli rodzicielskiej dla nieletnich i żadnych ofert poza aplikacją przed 13. rokiem życia, albo później, zależnie od kraju;
• tego samego wyboru we wszystkich sklepach UE przez 12 miesięcy.

Zależnie od wybranej opcji obowiązują prowizje. Przeczytaj ich sekcję na tej samej stronie, zanim zdecydujesz.

Inne kraje

W pozostałych miejscach zasada jest surowa: „apps and their metadata may not include buttons, external links, or other calls to action” prowadzących do innego sposobu płatności. Słowo „metadata” ma znaczenie: opis, który zapowiada „taniej na naszej stronie”, też podpada pod zasadę. Niektóre kraje, w tym Japonia, Brazylia i Korea Południowa, mają własne programy, wymienione w dokumentacji External Purchase.

Jak poprawić odrzucenie 3.1.1 i odpowiedzieć Apple

1. Znajdź wejście. Wiadomość wskazuje problematyczną treść albo ekran: treść kupioną gdzie indziej, przycisk, kod, link.
2. Zamknij je albo zdubluj. Albo usuwasz przycisk lub kod, albo sprzedajesz tę samą treść przez zakup w aplikacji.
3. Powołuj się na wyjątek tylko wtedy, gdy naprawdę cię dotyczy. Podaj punkt 3.1.3 i wyjaśnij w dwóch zdaniach, dlaczego twój przypadek się w nim mieści.
4. Daj recenzentowi coś do przetestowania. Konto demo i ścieżkę do paywalla w notatkach do recenzji, tak jak tłumaczę w poradniku o guideline 2.1.

Odpowiadasz w sekcji App Review w App Store Connect, zgodnie z procedurą odpowiadania App Review. Oto wzór dla najczęstszego przypadku, czyli treści kupionej na stronie. To przykład: podmień build, produkt i ścieżkę na swoje.

Hello,

Thank you for your review.

Issue: the app gave access to premium content purchased on our
website, without offering the same purchase in the app.

Fix in build X:
- Premium access is now available as an auto-renewable
  subscription through in-app purchase, on the paywall.
- The "Subscribe on our website" button has been removed.
- A "Restore Purchases" button is available on the paywall.

How to verify: launch the app and open any premium screen.
The paywall shows the in-app purchase options.

Best regards,

Przycisk i paywall są w kodzie: potrzebujesz nowego buildu. Jeśli nadal uważasz, że twój przypadek to wyjątek, Apple pozwala też odwołać się do App Review Board.

Podłącz zakup w aplikacji bez przepisywania wszystkiego

Dla początkującego najprostsza droga to utworzyć produkty w App Store Connect, a potem połączyć je z aplikacją przez RevenueCat: przepis znajdziesz w RevenueCat: jak wdrożyć subskrypcję w aplikacji. Jeśli wahasz się między dwoma modelami, przeczytaj subskrypcja czy jednorazowy zakup. Jeśli budujesz w narzędziu no-code, sprawdź, czy obsługuje zakup w aplikacji: to jeden z punktów w stworzyć aplikację bez kodowania.

Gdy tylko twój zakup w aplikacji jest subskrypcją, dochodzi 3.1.2: wyeksponowana kwota do zapłaty, okres, odnawianie, linki. Najczęstsze błędy na ekranie opisuję w paywall iOS: 7 błędów początkujących.

Checklista 3.1.1 przed wysłaniem

• Wszystko, co odblokowuje się w aplikacji (funkcja, treść, poziom, waluta), kupuje się przez zakup w aplikacji.
• Żaden przycisk, link ani tekst nie odsyła do zewnętrznej płatności, poza amerykańskim sklepem albo uzyskanym programem regionalnym.
• Opis twojej strony w sklepie nie wspomina o żadnym innym sposobie płatności.
• Treść sprzedawana na twojej stronie jest też w sprzedaży przez zakup w aplikacji.
• Żaden klucz licencyjny, kod QR, własny kod ani krypto niczego nie odblokowuje.
• Żeby dać dostęp, używasz kodów ofertowych Apple.
• Kupione kredyty nie wygasają, a przycisk „Restore Purchases” działa.
• Każda płatna skrzynka albo losowanie pokazuje prawdopodobieństwa przed zakupem.
• Produkt fizyczny albo usługa poza aplikacją idzie przez Apple Pay albo kartę, nie przez zakup w aplikacji.
• Twoje notatki do recenzji mówią, gdzie znaleźć zakupy i, jeśli powołujesz się na wyjątek, na który.

Sprawdź aplikację przed wysłaniem

Jeśli twoja aplikacja właśnie została odrzucona z powodu 3.1.1, Apple Review Kit pomoże ci znaleźć cytowaną zasadę, to, czego wymaga, oraz przykład poprawki i odpowiedzi. Jego notatki dla testera obejmują zakup w aplikacji. Jeśli chcesz, żeby spojrzał na to człowiek, zarezerwuj ze mną godzinę: przeczytamy wiadomość od Apple i poszukamy wejścia, które zauważyło. Cały proces jest na stronie aplikacja odrzucona przez Apple, a wdrożenie zakupu na stronie subskrypcja w aplikacji iOS.

Jeśli przygotowujesz swoje pierwsze wydanie, zrób darmową diagnozę: ułoży kroki we właściwej kolejności i wyśle ci moją checklistę przeciw odrzuceniom Apple. Żeby stworzyć aplikację mobilną, która od początku sprzedaje przez zakup w aplikacji, iOS Kit startuje z kodu, w którym paywall i subskrypcje są już gotowe.

Nikt nie zagwarantuje, że Apple zaakceptuje twoją aplikację. Mogę za to pomóc ci wybrać właściwy sposób płatności, zanim napiszesz kod.

Najczęściej zadawane pytania

Co oznacza „Guideline 3.1.1 - Business - Payments - In-App Purchase”?

To pełna nazwa zasady o zakupie w aplikacji w wiadomości od Apple. Oznacza, że twoja aplikacja daje dostęp do cyfrowej treści albo funkcji inną drogą niż zakup w aplikacji: płatność na stronie, kod, klucz licencyjny albo link do strony płatności.

Czy można dać link do swojej strony, żeby zapłacić taniej?

W amerykańskim sklepie tak: zasada pozwala na przyciski i linki bez entitlementu. W Unii Europejskiej jest to możliwe z entitlementem Apple i na jego warunkach. Gdzie indziej, poza programem regionalnym, ani aplikacja, ani jej strona w sklepie nie mogą odsyłać do innego sposobu płatności.

Czy można odblokować aplikację kodem promocyjnym?

Nie własnym kodem: 3.1.1 zakazuje własnych mechanizmów odblokowania, takich jak klucze licencyjne. Użyj kodów ofertowych Apple, tworzonych w App Store Connect. Działają dla subskrypcji i dla pozostałych typów zakupów w aplikacji.

Czy do sprzedaży produktu fizycznego albo usługi potrzebny jest zakup w aplikacji?

Nie. Produkt fizyczny albo usługa wykorzystywana poza aplikacją, jak dostarczony posiłek czy przejazd, musi iść przez inny sposób płatności, Apple Pay albo kartę płatniczą. Lekcja na żywo jeden na jeden też może się bez niego obyć, ale lekcja na żywo dla kilku osób już nie.

Czy klient z subskrypcją na mojej stronie może zalogować się w aplikacji?

Tak w przypadku usługi wieloplatformowej, pod warunkiem że ten sam dostęp jest też w sprzedaży przez zakup w aplikacji. To zasada 3.1.3(b). Bez tej oferty w aplikacji wracasz do typowego odrzucenia 3.1.1: treść kupiona gdzie indziej, której nie da się kupić przez Apple.

Czy RevenueCat wystarczy, żeby spełnić 3.1.1?

RevenueCat opiera się na zakupie w aplikacji Apple, więc nie tworzy problemu z 3.1.1. Nie usuwa jednak przycisku zewnętrznej płatności ani własnego kodu, które mogłyby być w twojej aplikacji. Zgodność trzeba sprawdzić ekran po ekranie, a także na stronie w sklepie.