2026'da RevenueCat Alternatifleri: Mobil Uygulamalar için Abonelik Platformu Seçimi

Mobil abonelik altyapısı katmanlı bir seçimdir: cihaz üstündeki SDK ve entitlement motoru, onun arkasındaki faturalama/katalog/vergi katmanı ve en üstteki paywall, deneyleme ve analitik araçları. İlk katmanda RevenueCat varsayılandır ve diğer iki katmanı da çoğu ekip için yeterince iyi karşılar. Brüt gelir üzerinden alınan %1 MTR ücreti yaklaşık 100 bin dolar MTR’ın üstünde matematiği değiştiriyor ve 2026 pazarında varsayılanı tek bir eksende geçen alternatifler var: paywall deneylemede Adapty, analitik/fiyat oranında Qonversion, win-back akışlarında Apphud, çapraz platform faturalamada Chargebee ve Stripe Billing.

Ciddi ciddi karşılaştırmaya değer altı platform var ve aralarındaki seçim uygulama aşamasına, platform karışımına ve bölgeye göre değişiyor. DMA sonrası harici ödeme kuralları, StoreKit 2 ile Google Play Billing v7 tuzakları ve satıcı pazarlama sayfalarında nadiren yer alan migrasyon maliyetleri cevabı kaydırıyor.

2026’da Pazarın Tablosu#

İki araç grubu aynı sunum slaytında yan yana anılıyor ama farklı problemleri çözüyor.

• Mobil öncelikli altyapı: RevenueCat, Adapty, Qonversion, Apphud. StoreKit ve Google Play Billing etrafında kurulmuş. Çekirdek soyutlama entitlement. Paywall builder’ları, A/B testi ve attribution entegrasyonları standart.
• Çapraz platform faturalandırma: Chargebee, Stripe Billing. Web abonelikleri, katalog, vergi ve fatura etrafında kurulmuş. Mobil sonradan eklenmiş bir parça ve bir mobil uygulamada dijital ürünler için Apple ve Google IAP, dar DMA ve ABD post-Epic istisnaları dışında hâlâ zorunlu.

2026’daki ciddi uygulamaların çoğu hibrit bir model işletiyor: dijital ürünler için mobilde IAP, yükseltmeler, B2B koltuklar ve DMA kapsamındaki harici ödemeler için web checkout (Stripe veya Chargebee). Asıl soru şu: hangi mobil platform hangi web platformuyla eşleşecek ve ikisi tek bir kullanıcı kimliği üzerinden nasıl uzlaştırılacak.

Karar Çerçevesi#

Aşağıdaki diyagram, hiçbir özellik veya fiyat detayına girmeden çoğu ekibi mantıklı bir varsayılana yönlendiriyor. Bunu bir başlangıç noktası olarak kullan, kesin hüküm olarak değil.

Dallar gerçek kısıtlarla eşleşiyor: 2.5 bin dolar MTR altındaysan, herhangi bir free tier iş görür ve optimize etmek mühendislik zamanı israfıdır. 100 bin dolar MTR üstünde RevenueCat’in brüt üzerinden %1 ücreti, finans ekibinin fark edeceği bir kalem olur ve Adapty, Apphud veya Qonversion devreye girer. Webde de faturalama yapman gerekiyorsa, neredeyse her zaman hibrit olursun.

Özellik Karşılaştırması#

Bir platform kararında önemli olan boyutlar, satıcı sayfalarının gösterdiğinden azdır. Ham özellik sayılarını görmezden gel ve şunlara odaklan.

Boyut	RevenueCat	Adapty	Qonversion	Apphud	Chargebee	Stripe Billing
Paywall Builder	Paywalls v2, AI üretim	Olgun builder, remote config	Daha hafif	Görsel editör + Rules	Sadece web checkout	Sadece web checkout
A/B Testi	Experiments, entegre	Bayesian + AI kazanan tahmini	Temel	Sağlam	Mobil için yok	Mobil için yok
Analitik Derinliği	Charts + Customer Center	Gelir + LTV tahmini	Küçük uygulamalar için tarihsel olarak en güçlü	Gerçek zamanlı	SaaS MRR/ARR	Sigma / dashboard’lar
Attribution	AppsFlyer, Adjust, Branch, Singular, Amplitude, Mixpanel	Aynı set, derin	Aynı set	Aynı set	Mobil için zayıf	Mobil için zayıf
Receipt Validation	Sunucu taraflı, dahil	Sunucu taraflı, dahil	Sunucu taraflı, dahil	Sunucu taraflı, dahil	Wrapper var	Yok; kendin getir
Entitlements Modeli	Entitlements API (fiili standart)	Access Levels	Entitlements	Entitlements	Uzlaştırma katmanı, iade edge case’lerinde sorunlu	Yalnızca Subscriptions
Webhook’lar	Referans taksonomi	Tam set	Tam set	Tam set	Tam set	Tam set
Çapraz Platform Sync	iOS, Android, web, Stripe	iOS, Android, web	iOS, Android, web	iOS, Android, web	Web öncelikli	Web öncelikli

Mobil öncelikli dört platform pazarlamanın gösterdiğinden çok daha benzer: temel altyapı dördünde de neredeyse aynı, asıl farklar paywall deney titizliği ve analitik derinliğinde ortaya çıkıyor. Chargebee ve Stripe Billing ise hiç mobil IAP platformu değil; bir hibrit yapının web yarısı için kasıtlı olarak seçmiyorsan, bunları aynı listeye koymak kategori hatasıdır.

2026’da Fiyatlandırma Matematiği#

Fiyatlandırma sayfaları göz atılmak için yazılır, o yüzden önemli olan aritmetiği biz yapalım.

• RevenueCat: 2.500 dolar MTR’a kadar ücretsiz. Üstünde brüt MTR’ın %1’i, burada brüt store komisyonu öncesi gelir demek. Small Business hesapları dışında bu, Apple ve Google payını aldıktan sonra kalan net gelirin kabaca %1,43’üne denk geliyor. Koltuk ücreti yok, işlem başına ücret yok.
• Adapty: MTR’a göre kademeli, free starter bandı dahil. Pro planlar A/B testi, AI ve entegrasyonları açıyor. Yüksek kademelerde gelir paylaşımı fiyatlandırması; yayınlanan rakamlar RevenueCat’ten daha az granüler ve ölçekte genelde bir satış görüşmesi gerektiriyor.
• Qonversion: Free plan tipik olarak 10 bin dolar MTR’a kadar. Ücretli planlar Starter veya Growth’a bağlı olarak 1.000 dolar MTR başına yaklaşık 6-8 dolar. Küçük ve orta uygulamalar için en iyi analitik/fiyat oranı.
• Apphud: Kabaca 1.000 dolar MTR’a kadar ücretsiz kademe. Pro plan ayda yaklaşık 49 dolar, kabaca 5.000 dolar MTR’a kadar; Expert plan ayda yaklaşık 59 dolar, server-to-server webhook’larla daha yüksek bantlar için; üstünde özel fiyatlandırma. Rules engine ücretli planlarda dahil.
• Chargebee: Performance ve Enterprise bantlarında başlayan SaaS kademeli fiyatlandırma, artı eşik üstünde gelirden yüzde. Mobil SDK, yeni Omnichannel Subscriptions ürünüyle yer değiştiren eski bir ürün.
• Stripe Billing: Ödeme işleme üstüne (kabaca %2,9 + işlem başına 30 sent) tekrarlayan ücretler için kabaca %0,5 ila %0,7 (Stripe 2025 ortasında çoğu müşteriyi %0,5’ten %0,7’ye taşıdı), artı Revenue Recognition veya Sigma için %0,4. MTR kavramı yok; işlem başına.

Takasları somutlaştıran bir örnek. iOS ve Android arasında eşit bölünmüş 100 bin dolar MTR’lı bir uygulamayı düşün. RevenueCat’te ücret ayda kabaca 1.000 dolar. Adapty veya Apphud’da benzer kademelerde maliyet rekabetçi ama genelde özel görüşme gerektiriyor. Qonversion’da ham MTR matematiği genelde en ucuzu, ancak bazı büyüme özelliklerinden vazgeçiyorsun. Tek başına Chargebee veya Stripe Billing ile bu geliri uygulama içinde dijital ürünler için yasal olarak toplayamazsın; karşılaştırma geçersiz.

Şimdi 500 bin dolar MTR’lı, %70 mobil ve %30 web dağılımlı bir hibrit düşün. Mobil için RevenueCat ayda 3.500 dolar, web dilimi için Stripe 150 bin doların kabaca %0,5’i yani 750 dolar, toplam yaklaşık 4.250 dolar. Mobil tarafı DIY bir Chargebee entegrasyonuyla değiştirmek kağıt üzerinde daha ucuz görünür ama receipt validation, grace period yönetimi ve webhook sıhhi tesisatı için mühendislik zamanında anlamlı ölçüde daha pahalıya patlar. Ayrı bir ödeme platformu ekibi olmayan takımlarda bu ek yük, genelde tasarrufu aşar.

Store komisyonları tüm bu ücretleri gölgede bırakıyor. Apple ve Google hâlâ brütten %15-30 alıyor; RevenueCat ile Adapty arasındaki fiyat farkı, Small Business Program veya AB’deki DMA indirimli oranlarına uygun olup olmadığının yanında küçük kalıyor.

StoreKit 2 ve Google Play Billing v7 Tuzakları#

Satıcı SDK’ları karmaşıklığın çoğunu gizler, ama edge case’ler hâlâ ısırıyor. Hangi platformu seçersen seç, üretimde en sık sessiz hatalara yol açanlar bunlar.

StoreKit 2, uygulama açılışında herhangi bir UI işinden önce Transaction.updates’e abone olmayı gerektiriyor. Daha sonra dinlersen, promoted offer’lar, Ask-to-Buy satın alımları ve ebeveyn onayları hiçbir şey dinlemezken gelebilir ve Apple işlemi tamamlamış olsa bile işlem uygulaman açısından kaybolur. Transaction.currentEntitlements ayrıca aktif olduktan sonra iade edilmiş kayıtları içermez; tam bir resim için sunucu bildirimlerine ihtiyacın var.

// Oturum acilisindan veya paywall'dan degil, uygulama baslatmasinda calismalidir
Task.detached {
    for await result in Transaction.updates {
        guard case .verified(let transaction) = result else { continue }
        await handleTransaction(transaction)
        await transaction.finish()
    }
}

Google Play Billing v7 ProductDetails.OneTimePurchaseOfferDetails üzerindeki bazı deprecated alanları kaldırdı ve client kurulurken PendingPurchasesParams’ın açıkça yapılandırılmasını gerektiriyor. queryPurchasesAsync artık varsayılan olarak pending satın alımları döndürmüyor, bu da eski davranışa güvenen akışları sessizce bozuyor.

val pendingPurchasesParams = PendingPurchasesParams.newBuilder()
    .enableOneTimeProducts()
    .enablePrepaidPlans()
    .build()

val billingClient = BillingClient.newBuilder(context)
    .setListener(purchasesUpdatedListener)
    .enablePendingPurchases(pendingPurchasesParams)
    .build()

Diğer edge case’ler: iadeler Apple’da Subscription Status API ve Server-to-Server Notifications v2 üzerinden, Google’da voided purchases polling ile geliyor. Family sharing entitlement’ları birincil satın alımlardan farklı görünür. Yükseltme ve düşürme oranlaması (proration) naif webhook handler’larını tökezletir. Sandbox test kullanıcıları MTR’a sayılmaz ama üretim entegrasyonlarını bozan webhook gürültüsü üretir.

Webhook’larda Idempotency#

Her mobil abonelik platformu webhook gönderir ama event taksonomileri farklıdır. RevenueCat’inki diğerlerinin yargılandığı fiili referanstır: INITIAL_PURCHASE, RENEWAL, PRODUCT_CHANGE, CANCELLATION, EXPIRATION, BILLING_ISSUE, SUBSCRIBER_ALIAS ve benzeri. Aşikar olmayan kısım, yükseltmeler sırasında gelen PRODUCT_CHANGE; bu, ilgili RENEWAL’dan önce veya sonra gelebilir ve original_transaction_id üzerinden deduplikasyon en güvenli anahtardır.

Minimum idempotent handler deseni:

async function handleWebhook(event: RevenueCatEvent) {
  const dedupKey = `${event.type}:${event.original_transaction_id}:${event.event_timestamp_ms}`;
  const inserted = await db.processedEvents.insertIfAbsent(dedupKey);
  if (!inserted) return; // zaten islendi

  switch (event.type) {
    case "INITIAL_PURCHASE":
    case "RENEWAL":
    case "PRODUCT_CHANGE":
      await upsertEntitlement(event);
      break;
    case "CANCELLATION":
    case "EXPIRATION":
      await revokeEntitlement(event);
      break;
  }
}

Migrasyonun Zor Kısımları#

Abonelik platformu değiştirmek hangi yöne gidersen git zahmetlidir. SDK değişikliği rutin iştir; takvimi uzatan şey tarihsel cohort analitiği ve entitlement edge case’leridir.

• Entitlement eşleştirme: Product ID’ler düzdür; entitlement ID’ler her platformun biraz farklı modellediği bir soyutlamadır. Lifetime aboneler ve grandfathered fiyat cohort’ları açık işlem gerektirir.
• Tarihsel analitik: Çoğu platform tarihsel işlemleri temiz bir şekilde içe aktaramaz. En az bir veya iki yenileme döngüsü boyunca çift çalıştırmayı planla ve yeni tarafta cohort geçmişinin boş başlayacağını kabul et.
• Webhook yeniden yazımı: Taksonomiler farklı. Satıcı eventlerini kanonik iç eventlere çeviren ince bir adapter, downstream tüketicileri yeniden yazmaktan neredeyse her zaman daha ucuzdur.
• SDK değişimi: Yeni SDK’yı feature flag arkasında küçük bir kullanıcı yüzdesine sınırlı olarak devreye al. Geçmeden önce en az bir tam yenileme döngüsü için eski SDK ile entitlement paritesini doğrula.
• Sunucu taraflı uzlaştırma: Kendi veritabanında kanonik bir user_id → entitlement tablosu tut.

Qonversion’dan Adapty’ye geçiş için somut bir eskiz: Qonversion’dan tarihsel satın alımları CSV olarak dışa aktar, başlangıç durumu olarak Adapty’ye yükle, bir yenileme döngüsü boyunca %5’lik bir feature-flag cohort’unda iki SDK’yı paralel çalıştır, entitlement tablolarını günlük uzlaştır, sapma yüzde birin altına indiğinde %100’e ramp yap.

Post-Mortem’lerde Tekrarlanan Kalıplar#

Bu alandaki neredeyse her post-mortem’de ortaya çıkan birkaç desen.

• Satıcının entitlement store’unu gerçek kaynağı olarak kabul etmek. O bir cache. Satıcıda arıza veya webhook gecikmesi olduğunda, uygulaman kullanıcıları kilitlemek yerine kendi kanonik store’una düşmeli.
• Stripe Billing’in mobil uygulamada dijital ürünler için IAP’ı değiştirebileceğini varsaymak. AB’de dar DMA koşulları veya belirli ABD post-Epic istisnaları dışında edemez, oralarda bile operasyonel yük gerçek.
• Küçük MAU uygulamalarında yetersiz güçte A/B testleri. Bayesian yöntemler (Adapty) yardımcı olur ama örnek boyutu disiplinini ortadan kaldırmaz. Varyant başına 200 kullanıcıda bir “kazanan” neredeyse her zaman gürültüdür.
• App Store Server Notifications v2’yi göz ardı edip client-driven state’e güvenmek. Client yalan söyler. Jailbreak’li bir cihaz veya öldürülmüş bir süreç webhook turunu atlayabilir.
• Yükseltmelerde PRODUCT_CHANGE’i unutmak. Kullanıcılar çift ücretlendirilir veya bir faturalama döngüsü için entitlement kaybeder. Bu spesifik event için entegrasyon testleri yaz.
• %1’den tasarruf etmek için kendi receipt validation’ını yazmak. İade edge case’leri, grace period’lar, family sharing ve voided purchases için ayrılmış backend kapasiten yoksa, satıcı ücreti on-call yükünden daha ucuzdur.

Düzenleyici Değişimler: DMA ve Post-Epic Ekonomisi#

AB Dijital Pazarlar Yasası ve ABD post-Epic v. Apple kararları mümkün olanın kenarlarını değiştirdi, ama merkezini değil. Apple ve Google IAP, çoğu bölgede çoğu dijital ürün akışı için hâlâ zorunlu. Anlaşılmaya değer istisnalar:

AB DMA kapsamında External Purchase Link Entitlement, AB’de dağıtılan bir uygulamanın içinden bir web checkout’a bağlanmaya izin veriyor; Apple’ın Core Technology Commission’ı geçerli (şu anda AB’de %5 civarı), standart store komisyonundan düşük ama sıfır değil. ABD’de Dokuzuncu Devre’nin Aralık 2025 kararı, Apple’ın ABD harici ödemelerinde önceki komisyonunu alamayacağına hükmetti ama makul bir maliyet karşılama ücreti belirlemesi için davayı bölge mahkemesine geri gönderdi; Apple daha ileri temyize gitti ve durum hareket halinde, aylık takip edilmeli. Google User Choice Billing birkaç bölgede indirimli komisyon oranıyla canlı; Apple değişikliklerinden daha az dramatik ama operasyonel olarak daha basit.

Pratikte, DMA uygun hibrit mimariler standart IAP için bir mobil platformu (RevenueCat veya Adapty) harici satın alma akışı için Stripe Checkout ile eşleştiriyor, backend’de tek bir kullanıcı kimliği üzerinden uzlaştırılıyor. Bu gerçek bir mühendislik işi; ROI yalnızca yatırımı haklı kılacak kadar AB geliri olan uygulamalarda var.

Senaryolara Göre Öneriler#

Karar çerçevesini somut önerilere toplarsak:

• Solo geliştirici veya indie, sadece iOS, 2.5 bin dolar MTR altı: RevenueCat free tier veya Apphud free tier. Sıfır operasyonel maliyet, gerekirse sonra değiştirebilirsin.
• Erken aşama startup, sadece mobil, hızlı paywall iterasyonu: Deney titizliği için Adapty veya A/B test derinliğinden çok ekosistem ve dokümana değer veriyorsan RevenueCat Paywalls v2.
• Analitik ağırlıklı pazarlama ekibine sahip büyüme aşamasındaki mobil uygulama: Maliyet verimliliği için Qonversion veya tahmine dayalı LTV önemliyse Adapty.
• Mobil + web + B2B koltuklarıyla scale-up: Hibrit. Mobilde RevenueCat veya Adapty, webde Stripe Billing, sunucu taraflı uzlaştırma.
• Biraz mobil teması olan kurumsal SaaS: Billing of record olarak Chargebee, Chargebee’ye IAP receipt broker görevi gören bir mobil platform.
• DMA harici ödemeler planlayan AB hedefli uygulama: Core Technology Commission ve External Purchase Link Entitlement’ın açık yönetimiyle hibrit Stripe + mobil platform.

Sonuç#

RevenueCat, sadece mobil uygulamalarda free tier’dan brüt üzerinden %1 ücretin pazarlık etmeye değer hale geldiği noktaya kadar varsayılan olarak duruyor; o eşiğin üstünde de ekosistemi sayesinde savunulabilir bir seçim. Varsayılanı üç baskıdan biri onu aştığında değiştir: paywall deneyleme derinliği, MTR dolarına düşen analitik maliyeti veya kendi billing of record’unu gerektirecek kadar büyüyen bir web gelir payı. Hangi yolu seçersen seç, kanonik user_id → entitlement tablosunu kendi veritabanında tut, böylece kurulumun geri kalanı geri alınabilir kalır.

Kaynaklar#

• RevenueCat Pricing & Plans (yeni sekmede açılır) - MTR eşikleri ve %1 ücret yapısıyla resmi fiyatlandırma sayfası.
• Navigating RevenueCat’s new pricing for existing users (yeni sekmede açılır) - Güncellenmiş MTR tabanlı fiyatlandırmanın resmi açıklaması.
• Announcing RevenueCat Paywalls v2 GA (yeni sekmede açılır) - Paywalls v2 özellik seti ve Experiments entegrasyonu.
• Generate a paywall with AI (RevenueCat Changelog) (yeni sekmede açılır) - AI paywall üretimi güncellemesi.
• The State of Subscription Apps 2026 (yeni sekmede açılır) - 115 binden fazla uygulamayı kapsayan 2026 benchmark’ları.
• Why hybrid monetization is the default in 2026 (yeni sekmede açılır) - Hibrit IAP + web çerçevelemesi.
• Adapty vs RevenueCat Comparison (yeni sekmede açılır) - A/B testi ve AI tahminlerini kapsayan Adapty’nin resmi karşılaştırması.
• Adapty Paywall A/B Testing (yeni sekmede açılır) - Bayesian AB testi ve AI kazanan tahmini.
• Qonversion Pricing (yeni sekmede açılır) - Starter ve Growth MTR fiyatlandırma detayları.
• Qonversion: Handbook on App Store Receipt Validation (yeni sekmede açılır) - Receipt validation edge case’leri.
• Apphud Pricing (yeni sekmede açılır) - MTR tavanlarıyla Free ve Pro kademe yapısı.
• Apphud Product Overview (yeni sekmede açılır) - Rules engine ve altyapı konumlandırması.
• Chargebee Mobile Subscriptions Docs (yeni sekmede açılır) - Mobil abonelik akışları ve eski SDK notları.
• Stripe: Accept in-app purchases on iOS and Android (yeni sekmede açılır) - Stripe’ın resmi mobil dijital ürün rehberi.
• Can You Use Stripe for In-App Purchases? (RevenueCat) (yeni sekmede açılır) - IAP için Stripe’ın post-Epic analizi.
• App-to-web external purchases (RevenueCat) (yeni sekmede açılır) - Pratik DMA harici satın alma rehberi.
• New App Store Fees in 2026: EU DMA (FunnelFox) (yeni sekmede açılır) - 2026 AB DMA ücret yapısı dökümü.
• An overview of StoreKit 2 (RevenueCat) (yeni sekmede açılır) - StoreKit 2 mimarisi ve Transaction.updates modeli.
• Server-side purchase validation on Google Play (Adapty) (yeni sekmede açılır) - Google Play Billing doğrulama rehberi.