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

RevenueCat mobil abonelik altyapısında en bilinen marka ve birçok ekip için de doğru cevap. Ama "en bilinen" ile "doğru" aynı şey değil ve brüt gelir üzerinden alınan %1'lik MTR ücreti, bir uygulama 100 bin dolar MTR'ı aştığında farklı hissettirmeye başlıyor. 2026 ortamı iki yıl öncesine göre daha kalabalık: Adapty paywall deneysel titizliğinde önde, Qonversion hâlâ küçük ekipler için en iyi analitik/fiyat oranını sunuyor, Apphud'un Rules engine'i win-back akışları için sadık bir kitleye sahip ve Chargebee ile Stripe Billing mobil IAP ile web checkout'u birleştiren hibrit mimarilerde sıkça karşımıza çıkıyor.

Bu yazı altı platformun (RevenueCat, Adapty, Qonversion, Apphud, Chargebee ve Stripe Billing) karar odaklı bir karşılaştırması. Amacı, kıdemli mobil ve backend geliştiricilerin belirli bir uygulama aşaması, platform karışımı ve bölge için doğru aracı seçmesine yardımcı olmak. Ayrıca DMA sonrası harici ödeme gerçeği, StoreKit 2 ile Google Play Billing v7 tuzakları ve satıcıların pazarlama sayfalarında nadiren geçen migrasyon maliyetleri de ele alınıyor.

2026 Manzarası#

Aynı slayt üzerinde logoları yan yana konulan iki grup araç 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). Seçim nadiren "hangi tek araç kazanır" şeklinde; çoğunlukla "hangi mobil platform artı hangi web platformu, tek bir kullanıcı kimliği üzerinden uzlaştırılacak" şeklinde oluyor.

Karar Çerçevesi#

Özellikler ve fiyatlandırmaya girmeden önce, çoğu ekibi mantıklı bir varsayılana yönlendiren bir karar diyagramı. 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.

İki gözlem. Birincisi, mobil öncelikli dört platform pazarlamanın gösterdiğinden çok daha benzer ve farklar temel altyapıdan çok paywall deney titizliği ve analitik derinliğinde yatıyor. İkincisi, Chargebee ve Stripe Billing 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 Gerçeğ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. Adanmış bir ödeme platformu ekibi olmayan hiçbir takım için tasarruf, maliyeti karşılamaz.

Dürüst uyarı: store komisyonları tüm bu ücretleri gölgede bırakıyor. Apple ve Google hâlâ brütten %15-30 alıyor ve RevenueCat ile Adapty arasındaki fark, Small Business Program veya AB'deki DMA indirimli oranlarına uygun olup olmadığına kıyasla yuvarlama hatasıdır.

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 calismalidirTask.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 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;  }}

Bunu bir kez dahili event bus'a çevir, satıcı değiştirmek iş mantığını değil sadece adapter'ı yeniden yazmak olur.

Migrasyon Değerlendirmeleri#

Abonelik platformu değiştirmek hangi yöne gidersen git zahmetlidir. En zor iki kısım SDK değişikliği değil; tarihsel cohort analitiği ve entitlement edge case'leri.

• 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. Her gelecekteki migrasyonu atlatılabilir yapan tek karar budur.

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üzdenin altına düştüğünde %100'e ramp yap.

Anti-Pattern'ler ve Yaygın Hatalar#

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 adanmış 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: 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 post-Epic: 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. Durum hareket halinde ve 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 bir flag değişikliği değil gerçek iş; ROI yalnızca mühendislik yatırımını 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.

2026'da sadece mobil uygulamalar için RevenueCat ve Adapty iki ciddi varsayılan. Adapty paywall deneyciliği ve AI odaklı iterasyonda önde; RevenueCat ekosistem genişliği, dokümantasyon ve fiili webhook taksonomisinde önde. Qonversion ve Apphud maliyete duyarlı ekipler ve analitik derinliği veya Rules tabanlı win-back gibi özel ihtiyaçlar için güçlü olmaya devam ediyor. Chargebee ve Stripe Billing hibrit bir mimarinin web tarafına ait, mobil IAP'ın yerine değil.

Sonuç#

Abonelik platformu seçimi bir kazanan seçmekten çok, aracı aşamaya, platform karışımına ve bölgeye eşleştirmekle ilgili. %1 MTR ücreti, paywall deney titizliği, analitik derinliği ve düzenleyici maruziyet hepsi önemli, ama hiçbiri kendi kanonik entitlement tablonu tutma mimari kararı kadar önemli değil. Bunu yaparsan, her gelecekteki migrasyon işinin yeniden yazımı değil, bir adapter'ın yeniden yazımı olur.

Sıfırdan başlıyorsan, yukarıdaki çerçeveden aşamana ve bölgene uyan varsayılanı seç, kendi entitlement store'unu tut ve mühendislik çabanı receipt validation'ı yeniden icat etmeye değil, paywall deneylerine ve edge case'lere harca.

Kaynaklar#

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