RevenueCat - zarządzanie subskrypcjami w aplikacji mobilnej

Dodanie subskrypcji do aplikacji mobilnej wygląda w planie projektu na jedno zadanie: ekran z ceną i przycisk „Kup”. W praktyce to kilka tygodni pracy nad czymś, czego użytkownik nie widzi. Dwa sklepy z różnymi zasadami, odnowienia, okresy próbne, zwroty, nieudane płatności kartą i pytanie, które wraca co miesiąc: ile właściwie zarabiamy. RevenueCat to usługa, która upraszcza zarządzanie subskrypcjami w aplikacji mobilnej. Programiści dodają do aplikacji jedną bibliotekę, a RevenueCat zajmuje się komunikacją z App Store i Google Play, pilnuje statusu każdego subskrybenta i zbiera dane o przychodach w jednym panelu. Firma nie musi budować do tego własnego serwera.

Najłatwiej zrozumieć, co to daje, śledząc jedną subskrypcję od pierwszego ekranu z ofertą do dnia, w którym użytkownik rezygnuje. Tak ułożyliśmy ten tekst.

RevenueCat, czyli zarządzanie subskrypcjami w aplikacji mobilnej bez własnego backendu

Sprzedaż cyfrowych treści i funkcji w aplikacji na iPhone’a czy Androida musi przechodzić przez systemy płatności Apple i Google. Każdy z nich ma własne interfejsy, własne powiadomienia o zdarzeniach i własne zasady dotyczące odnowień czy zwrotów. Aplikacja dostępna na obu platformach musi obsłużyć oba systemy i jeszcze połączyć je w jedną spójną informację: czy ten konkretny użytkownik ma dostęp do wersji premium. RevenueCat stoi pomiędzy aplikacją a sklepami. Aplikacja pyta RevenueCat, a nie Apple czy Google, czy użytkownik ma aktywną subskrypcję. RevenueCat zna odpowiedź, bo odbiera wszystkie powiadomienia ze sklepów, weryfikuje zakupy i przechowuje historię każdego klienta.

Biblioteki RevenueCat są dostępne dla aplikacji natywnych w Swift i Kotlinie oraz dla aplikacji wieloplatformowych w React Native i Flutterze, a także dla Unity, Capacitora i Kotlin Multiplatform. W projektach na Expo integracja działa bez wychodzenia poza standardowy proces budowania aplikacji.

Dzień 0: ekran z ofertą

Użytkownik instaluje aplikację i po kilku ekranach powitalnych widzi paywall, czyli ekran z ofertą płatnej wersji. To jeden z najważniejszych ekranów w całym produkcie. Od jego treści, cen i momentu wyświetlenia zależy, ilu użytkowników w ogóle zacznie płacić. Według raportu State of Subscription Apps 2026, opartego na danych ponad 115 tys. aplikacji, sama decyzja o modelu robi ogromną różnicę. W aplikacjach z twardym paywallem, gdzie bez subskrypcji nie da się korzystać z produktu, mediana konwersji z okresu próbnego na płatną subskrypcję po 35 dniach wynosi 10,7%. W modelu freemium, z darmową wersją podstawową, to 2,1%. To dane z aplikacji korzystających z RevenueCat, ale skala różnicy dobrze pokazuje, dlaczego paywall wymaga eksperymentów.

RevenueCat pozwala zmieniać paywall bez publikowania nowej wersji aplikacji. Ceny, warianty planów, teksty i układ ustawia się w panelu, a aplikacja pobiera aktualną konfigurację przy uruchomieniu. To ważne, bo każda aktualizacja w sklepie wymaga przeglądu, a użytkownicy instalują nowe wersje z opóźnieniem. Na tym opierają się eksperymenty. Część użytkowników widzi ofertę z rocznym planem na pierwszym miejscu, część z miesięcznym, a panel pokazuje, która wersja przyniosła więcej przychodu, a nie tylko więcej kliknięć. To klasyczne testy A/B, przeniesione na najbardziej dochodowy ekran aplikacji.

Minuta 1: zakup i przyznanie dostępu

Użytkownik wybiera plan i potwierdza zakup Face ID lub odciskiem palca. Płatność obsługuje sklep, a aplikacja dostaje informację, że transakcja się udała. W tym miejscu pojawia się pierwszy problem, którego nie widać w makietach: tę informację trzeba zweryfikować, bo zakup da się podrobić na urządzeniu. RevenueCat sprawdza każdą transakcję bezpośrednio ze sklepem i dopiero wtedy przyznaje użytkownikowi uprawnienie, w RevenueCat nazywane entitlement. To pojęcie warto znać, bo upraszcza myślenie o produkcie. Plan miesięczny, roczny i dożywotni to trzy różne produkty w sklepie, ale wszystkie dają to samo uprawnienie „premium”. Aplikacja sprawdza tylko uprawnienie, a nie listę produktów. Drugi problem to wiele urządzeń. Użytkownik kupił subskrypcję na iPhonie, a teraz loguje się na tablecie z Androidem albo w wersji webowej. Jeśli aplikacja ma własne konta użytkowników, RevenueCat łączy zakupy z tym kontem i udostępnia uprawnienie na każdej platformie.

Coraz więcej aplikacji sprzedaje też subskrypcje poza sklepami, przez stronę internetową. RevenueCat obsługuje płatności webowe, także przez Stripe, i łączy je z zakupami w aplikacji. Dla użytkownika nie ma znaczenia, gdzie zapłacił. Dla firmy różnica jest istotna, bo prowizja sklepu za subskrypcje wynosi zwykle od 15 do 30%, a operatora płatności internetowych kilka procent.

Dzień 3: koniec okresu próbnego

Większość subskrypcji zaczyna się od darmowego okresu próbnego. To moment, w którym aplikacja traci najwięcej potencjalnych klientów, i to zwykle szybciej, niż zespół się spodziewa. Raport RevenueCat pokazuje, że 55,4% rezygnacji z trzydniowych okresów próbnych następuje jeszcze w dniu ich rozpoczęcia. Użytkownik włącza próbę i od razu ją anuluje, żeby nie zapomnieć. Dłuższe okresy próbne, od 17 do 32 dni, kończą się zakupem w 42,5% przypadków, krótsze niż cztery dni w 25,5%.

Nie znaczy to, że każda aplikacja powinna dawać miesiąc za darmo. Znaczy, że długość okresu próbnego to decyzja biznesowa, którą trzeba sprawdzić na własnych użytkownikach. RevenueCat pozwala testować różne warianty i od razu widzieć, jak przekładają się na przychód po kilku miesiącach. W tym czasie aplikacja powinna pokazać użytkownikowi wartość. Przypomnienie przed końcem próby albo podsumowanie tego, co zrobił w aplikacji, działa lepiej niż cisza do dnia pierwszej płatności. RevenueCat wysyła informacje o zdarzeniach do narzędzi marketingowych, więc takie wiadomości mogą wychodzić automatycznie, w odpowiednim momencie.

Miesiąc 13: odnowienie, które się nie udało

Rok później sklep próbuje pobrać opłatę za kolejny okres. Karta wygasła albo nie ma na niej środków. Użytkownik nie zrezygnował, ale subskrypcja może się zakończyć. To częstsze, niż się wydaje. Według tego samego raportu nieudane płatności odpowiadają za 31% rezygnacji w Google Play i 14% w App Store. To przychód tracony nie dlatego, że klient chce odejść, tylko dlatego, że nikt mu nie przypomniał o aktualizacji karty.

Sklepy mają mechanizmy, które dają czas na naprawienie płatności: okres karencji, w którym użytkownik zachowuje dostęp, i ponowne próby pobrania opłaty. RevenueCat śledzi te stany i przekazuje je do aplikacji. Aplikacja może wtedy pokazać komunikat „Twoja płatność się nie powiodła” z przyciskiem prowadzącym do ustawień sklepu, zamiast po cichu odebrać dostęp.

Dla aplikacji z subskrypcjami rocznymi ten moment ma szczególne znaczenie. Raport podaje, że około 72% subskrybentów planów rocznych rezygnuje w ciągu pierwszego roku, a 35% wszystkich rezygnacji z planów rocznych zapada już w pierwszym miesiącu, gdy użytkownik wyłącza automatyczne odnowienie. Churn, czyli odsetek klientów, którzy odchodzą, w modelu subskrypcyjnym jest liczbą, którą trzeba śledzić co miesiąc.

Dzień rezygnacji: anulowanie i próba zatrzymania

W końcu użytkownik decyduje się zrezygnować. Na iPhonie i Androidzie robi to w ustawieniach sklepu, a nie w aplikacji, więc firma często dowiaduje się o tym dopiero z raportu. RevenueCat ma moduł do obsługi klienta w aplikacji, nazwany Customer Center. Użytkownik może w nim zarządzać subskrypcją, poprosić o zwrot lub zmienić plan, a zanim zrezygnuje, zobaczyć ofertę zatrzymania, na przykład tańszy plan albo miesiąc ze zniżką. Pytanie o powód rezygnacji daje przy okazji dane, które trudno zdobyć inaczej.

Rezygnacja nie musi być końcem. Ci sami użytkownicy po kilku miesiącach mogą dostać ofertę powrotu, a RevenueCat wie, kto zrezygnował i kiedy. Dbanie o retencję klientów jest zwykle tańsze niż pozyskiwanie nowych, a w aplikacjach subskrypcyjnych tę różnicę widać bardzo wyraźnie w wynikach.

Za kulisami: dane, integracje i koszt

Przez cały ten czas RevenueCat zbiera dane w jednym miejscu. Panel pokazuje przychód cykliczny, liczbę aktywnych subskrypcji i okresów próbnych, konwersję, rezygnacje i przychód z użytkownika w czasie, w podziale na kraje i platformy. Bez takiego narzędzia te liczby trzeba składać z raportów dwóch sklepów, które różnią się formatem i terminami. Każde zdarzenie, od zakupu po rezygnację, RevenueCat może przesłać dalej przez webhook, czyli automatyczne powiadomienie wysyłane do innego systemu. Dzięki temu backend aplikacji, system CRM czy narzędzia analityczne wiedzą o zmianie statusu klienta w ciągu sekund. 

RevenueCat ma też gotowe integracje z popularnymi narzędziami do analityki i marketingu, w tym z Firebase. Według cennika RevenueCat usługa jest bezpłatna do 2500 USD miesięcznego przychodu śledzonego przez platformę. Powyżej tej kwoty opłata wynosi 1% przychodu. Duże aplikacje mogą negocjować indywidualne warunki w planie Enterprise.

Alternatywą jest własne rozwiązanie: obsługa StoreKit po stronie Apple i Google Play Billing po stronie Google, serwer weryfikujący zakupy i odbierający powiadomienia ze sklepów, własna baza subskrypcji i raporty. Przy aplikacji na obie platformy to zwykle od kilku tygodni do kilku miesięcy pracy, a potem stałe utrzymanie, bo sklepy co roku zmieniają swoje interfejsy. Przy przychodach rzędu kilkuset tysięcy złotych rocznie 1% dla RevenueCat to zwykle mniej niż koszt utrzymania takiego systemu.