Uygulamaya abonelik ekleme: RevenueCat ve paywall rehberi

Uygulamanızın abonelik gerektirdiğine karar verdiniz. Çoğu tüketici uygulaması için bu doğru karardır, çünkü abonelik, her ayın birinde sıfırdan başlamak yerine birikerek büyüyen tek gelir modelidir. Zor olan karar değil. Zor olan, ödeme ekranınızdaki (paywall) bir dokunuşla hesabınıza yatan para arasındaki altyapı. Üstelik bu altyapı, her birinin kendi kuralları, kendi hataları ve makbuzun ne olduğuna dair kendi anlayışı olan iki ayrı uygulama mağazasına yayılıyor.

Codixus'ta abonelikli uygulamalar geliştiriyoruz; App Store ve Google Play'de yayında olan kendi uygulama portföyümüzü de birebir aynı teknolojilerle geliştirip yayınlıyoruz. Yani bu yazı teori değil: her yeni projede başvurduğumuz kurulumu ve kurucuların bizi aramadan önce yaptığını gördüğümüz bir yığın hatayı anlatıyor.

StoreKit ve Play Billing entegrasyonunu neden kendiniz yazmamalısınız

İlk içgüdünüz doğrudan kaynağa gitmek olabilir. Apple size StoreKit'i veriyor, Google da Play Billing Library'yi. İkisi de sağlam, belgelenmiş ve ücretsiz. Peki neden bir ara katman için para ödeyesiniz?

Çünkü ödemeyi almak işin belki yüzde onu. Geri kalan yüzde doksanı ise durum yönetimi. Abonelik tek seferlik bir olay değil, uygulamanız kapalıyken zaman içinde değişmeye devam eden bir durumdur. Gece 3'te yenilenir. Kartın süresi dolduğu için ödemenin yeniden denendiği ek süreye (grace period) girer. Kullanıcı üç hafta sonra Apple'dan iade ister. Uygulamayı yeni bir telefona yeniden kurar ve erişiminin anında geri gelmesini bekler. Bunların her biri artık sizin yönetmeniz gereken bir durum geçişi; üstelik iki platformda ve her birinde farklı terimlerle anlatılıyor.

Mağazalar, ne kadar büyük bir işe giriştiğinizi saklamıyor. Google, Android'de dijital ürün satmanın zorunlu yolunun kendi faturalama sistemi olduğunu ve gerçek bir entegrasyonda cihazdaki kütüphanenin, satın alımları Play Developer API üzerinden doğrulayan bir sunucu tarafıyla (backend) birlikte çalıştığını söylüyor (Google Play Billing overview). Apple ise otomatik yenilenen aboneliklerin "süreleri sonunda, kullanıcı iptal etmeyi seçene kadar otomatik olarak yenileneceğini" belirtiyor (Apple auto-renewable subscriptions). Bu iki cümleyi bir kez daha okuyun. Yenileme de iptal de mağazanın saatine göre olur, sizin saatinize göre değil. Size gereken, tek işi kimin erişimi olduğuna dair kaydınızı mağazanın kaydıyla sürekli senkronize tutmak olan bir sistem.

RevenueCat tam olarak bu sistem. İki mağazayı tek bir SDK'nin arkasında toplar, abonelik durumunu tutar ve uygulamanızın çalışırken önemsediği tek soruyu yanıtlar: bu kullanıcının şu anda erişimi var mı, evet ya da hayır. Bunu kendiniz de yapabilirsiniz. Biz de yaptık. Zaten çözülmüş bir sorun için mühendislik bütçenizden ciddi bir pay götürür ve bir yıl sonra bile canlı ortamdaki uç durumları yamalamaya devam edersiniz.

Gerçekten anlamanız gereken model

RevenueCat'in üç kavramı var. Bunları doğru anlarsanız gerisi kendiliğinden yerine oturur.

Entitlement (erişim hakkı): kullanıcının ne için ödediği

Entitlement bir erişim seviyesidir. RevenueCat bunu "bir kullanıcının 'hak sahibi' olduğu erişim seviyesi, özellik ya da içerik" diye tanımlıyor (RevenueCat entitlements). Çoğu uygulamanın tam olarak bir tanesine ihtiyacı vardır, adı da "pro" olsun. Kodunuz ürün kimliklerine ya da makbuzlara hiç bakmaz, "pro" entitlement'ının aktif olup olmadığına bakar ve özelliğe erişimi buna bağlar. Bu tek dolaylı katman sayesinde ileride yeni bir fiyat, yeni bir paket, hatta koskoca ikinci bir mağaza eklediğinizde arayüzünüzdeki erişim kontrollerinin hiçbirine dokunmanız gerekmez.

Offering ve package: sattığınız şey

Offering, ödeme ekranında gösterdiğiniz ürün grubudur. Package ise farklı platformlardaki eşdeğer ürünleri bir araya getirir; böylece "yıllık" package'ınız, uygulamanız aradaki farkı bilmeden doğru iOS ürününe ve doğru Android ürününe işaret eder. Bunun ticari önemi, size verdiği kontrolde yatıyor. RevenueCat'e göre, "RevenueCat'te Offering'leri yapılandırdıysanız, kullanıcılara hangi ürünlerin gösterileceğini uygulama güncellemesi gerektirmeden kontrol edebilirsiniz" ve değişiklikler "tüm kullanıcılar için hemen yürürlüğe girer" (RevenueCat offerings and packages). Yani yeni bir fiyatı denemek, varsayılan paketi değiştirmek ya da bir kampanya yürütmek için yeni bir sürüm yükleyip App Store incelemesini beklemeniz gerekmez, hepsini bir panelden yapabilirsiniz.

React Native ve Expo uygulamasına entegrasyon

Bizim tarafta bu, TypeScript ile Expo ve React Native anlamına geliyor; entegrasyonu da react-native-purchases SDK'siyle yapıyoruz. SDK'yi kurar, native parçaların development build'inize dahil olması için config plugin'i eklersiniz; ardından uygulama açılışında herkese açık (public) API anahtarınızla bir kez yapılandırırsınız. Bundan sonra akışın neredeyse tamamını iki çağrı taşır: ödeme ekranını göstermek için güncel offering'i çekmek ve kullanıcının dokunduğu package için purchase çağırmak.

Her satın alımdan sonra ve uygulama sıfırdan her açıldığında SDK'den müşteri bilgisini istersiniz ve entitlement'ı okursunuz. "pro" aktifse erişim verin. Değilse ödeme ekranını ya da ücretsiz deneyimi gösterin. Kendi veritabanınızda "isPro" tutup ona sonsuza kadar güvenmeyin. Entitlement'ı her an güncel olan cevap olarak görün; uygulama kapalıyken gerçekleşen bir iadeyi ya da süre dolmasını yansıtan odur. Ayrıca entitlement'ları yeniden eşitleyen, görünür bir "Satın Alımları Geri Yükle" (Restore Purchases) düğmesi koyun. Apple geri yükleme seçeneğini zorunlu tutuyor; yeni cihaza geçen kullanıcılar da bu düğmeyi arar.

Doğru bilgi sunucuda: doğrulama ve webhook'lar

İstemci tarafındaki entitlement kontrolleri bir ekranı kilitlemek için yeterlidir. Size maliyet çıkaran bir backend özelliğini, örneğin bir yapay zeka çağrısını ya da sunucuda oluşturulan bir dışa aktarmayı çalıştırmak için yeterli değildir. Maliyetli her işin erişim kontrolünü kendi sunucunuzda yapın; sunucunuz da abonelik değişikliklerini telefonun söylediğine inanmak yerine güvenilir bir kanaldan öğrensin.

Bu kanal da webhook'lar. RevenueCat, "herhangi bir olay gerçekleştiğinde size bildirim gönderebilir"; bunu, olayı JSON olarak taşıyan bir POST isteğiyle endpoint'inize iletir, sunucunuz da 200 döndürerek isteği başarıyla aldığını bildirir (RevenueCat webhooks). İlk satın alma, her yenileme, iptaller, ödeme sorunları ve iadeler size bu yolla ulaşır. Bizim projelerimizde bir Bun servisi bu webhook'u alır, doğrular ve abonelik durumunu Supabase Postgres'e yazar. Böylece backend'inizde erişim kontrolü, analitik ve iptal eden kullanıcıyı geri kazanma mesajları için güvenebileceğiniz, esas alınan bir kayıt olur. Kurucuların atlayıp sonra pişman olduğu parça bu, çünkü o olmadan sunucunuz yalnızca tahmin yürütür.

Abonelik, bir uygulamadan para kazanmanın birkaç yolundan yalnızca biri. Hangi modeli seçeceğinizi hâlâ tartıyorsanız, fiyatlandırmaya karar vermeden önce mobil uygulama gelir modelleri yazımızdaki ayrıntılı karşılaştırmayı okuyun.

Ödeme ekranı nereye, ne zaman konur

Entegrasyon işin kolay kısmı. Gelirin kazanıldığı ya da kaybedildiği yer, ödeme ekranının konumu. Kullanıcı henüz hiçbir değer görmeden gözüne sokulan bir ödeme ekranı, ona çoğunlukla ödeme ekranlarını kapatmayı öğretir. Hiç çıkmayan bir ödeme ekranı ise uygulamanızın ücretsiz olduğunu öğretir.

Dönüşüm getiren yerleşim, ödeme ekranını kullanıcının değeri görüp satın alma isteğinin oluştuğu ana koyar. Kullanıcı ne için geldiyse o sonuca ulaşsın: bitmiş düzenleme, cevap, kazanım. Bir sonrakini ya da onun premium sürümünü kilitleyin. Tüm uygulamayı kilitleyen ödeme ekranları (hard paywall) açıkça premium bir üründe işe yarayabilir, ama çoğu uygulamada önce değeri gösterip kullanıcının istediği anda devreye giren bir kilit daha iyi sonuç verir. Offering'ler uzaktan yönetildiği için bunu bir kez tahmin edip sonuçlarıyla yaşamak zorunda değilsiniz. Makul bir varsayılanla çıkın, dönüşümü izleyin, paketi ya da fiyatı panelden değiştirin. Ödeme ekranının yerleşimi ve analitik konusunda destek isterseniz, abonelikli uygulama geliştirme hizmetimiz tam olarak bunu yapıyor. 30 dakikalık görüşme planlayın, dönüşüm huninizi birlikte inceleyelim.

Ücretsiz deneme meselesi: açık konuşalım

Ücretsiz denemeler bedava bir kazanç gibi görünür. Bedava değildir. Apple, ücretsiz denemeyi bir tanıtım teklifi (introductory offer) olarak destekliyor: "abonelikleri hemen başlar, ancak teklif süresi bitene kadar faturalandırılmazlar" ve teklif abonelik grubu başına bir kez kullanılabilir (Apple introductory offers). Bundan iki sonuç çıkar. Birincisi, deneme ancak kullanıcı iptal etmeyi unutursa ya da gerçekten değer gördüyse ücretli yenilemeye dönüşür; mağaza iptali kolaylaştırdığı için zayıf bir ürün, boş yere bir haftalık kullanımı bağışlamış olur. İkincisi, uygulamanız ücretli bir yapay zeka modelini ya da kullanım başına maliyet çıkaran herhangi bir backend'i çağırıyorsa, deneme ücretli aboneliğe dönüşene kadar her deneme kullanıcısı, karşılığında hiç gelir olmayan gerçek bir maliyettir.

Maliyeti yüksek uygulamalarda varsayılan tercihimiz şu: önce denemesiz yayına çıkmak, ödeme ekranının tek başına dönüşüm getirdiğini kanıtlamak, sonra kısa bir deneme süresini bir deney olarak sınamak. Deneme bir hediye değil, bir kaldıraçtır. Deneme sırasındaki kayıt oranını değil, deneme sonrasındaki ücretli dönüşüm oranını ölçün.

Yayından önce sandbox'ta test edin

İki mağaza da tüm satın alma döngüsünü sahte parayla çalıştırabileceğiniz bir sandbox sunuyor. RevenueCat "ortamı (production ya da sandbox) otomatik olarak algılar", bu yüzden orada test etmek için ek bir yapılandırma gerekmez (RevenueCat sandbox testing). RevenueCat'in şu tavsiyesi tekrarlamaya değer: meta verileri değil, akışı test edin, çünkü mağazalar sandbox'ta çoğu zaman yanlış fiyat ve ürün bilgisi döndürür. Kontrol listenizi davranış odaklı tutun. Bir satın alma başlatın, tamamlayın, entitlement'ın aktifleştiğini doğrulayın, uygulamayı tamamen kapatıp yeniden açın ve erişimin korunduğunu kontrol edin. Sonra iptal edin ve erişimin sona erdiğinden emin olun. Bu adımlar sandbox'ta sorunsuz geçiyorsa canlı ortamdaki akışınız da sağlam kalır.

Sık sorulan sorular

RevenueCat kullanırsam yine de Apple ve Google geliştirici hesabı gerekir mi?

Evet. RevenueCat mağazaların üzerinde çalışır, onların yerini almaz. Ürünlerinizi ve fiyatlarınızı App Store Connect'te ve Google Play Console'da oluşturur, sonra RevenueCat'te bunlara referans verirsiniz. Her ödemeyi işleyen ve vergiyi halleden yine mağazadır.

RevenueCat ücretsiz mi?

Takip edilen gelirde azımsanmayacak bir tutara kadar ücretsiz bir paketi var; bu eşiğin üzerinde ücretli paketler devreye giriyor. Erken aşamadaki bir uygulamada bu ücretsiz paket genellikle yayından epey sonrasına kadar yeter. Bütçenizi planlamadan önce RevenueCat'in güncel fiyat sayfasına bakın, çünkü paketler değişebiliyor.

Expo uygulamasına eject etmeden abonelik ekleyebilir miyim?

Evet. Eski managed workflow'u değil, config plugin'li bir development build kullanırsınız; bu sayede react-native-purchases gibi native modüller çalışır, Expo araçlarını da korursunuz. 2026'da Expo uygulamalarını canlıya çıkarmanın standart yolu bu; kendi uygulamalarımızda da bu kurulumu kullanıyoruz.

Abonelik entegrasyonu ne kadar sürer?

Entegrasyonun kendisi hafta değil gün işidir. Asıl zaman iki mağazadaki ürün kurulumuna, ödeme ekranı tasarımına, webhook'ların sunucu tarafında işlenmesine ve yenileme, iptal, geri yükleme senaryolarının sandbox'ta test edilmesine gider. Codixus projelerinde bu iş normal takvimin içine sığar; ikinci haftanın sonunda gerçek cihazda çalışan bir TestFlight sürümü elinizde olur.

Bunu sizin için yapmamızı ister misiniz? 30 dakikalık görüşme planlayın. Bize uygulamanızı ve fiyatlandırma fikrinizi anlatın; daha kimse kod yazmadan ödeme ekranını, entitlement'ları ve backend'i birlikte netleştirelim. 30 dakikalık görüşme planlayın.