Doğrudan Maliyet: $2.500 Eşiği Neden Somut
RevenueCat'in fiyatlandırması iki kademeli: aylık $2.500 takip edilen gelire (MTR) kadar tamamen ücretsiz, bu eşiği aştığın andan itibaren o ayki izlenen gelirin %1'i kadar ücret başlıyor — gizli katman veya kullanıcı-başı limit yok (revenuecat.com/pricing/). Paywall ve A/B testi araçları aynı %1'in içinde — sayfa kapanışı: "Our entire suite of features comes standard"; Growth Tools ek bir kalem değil.
Saf StoreKit 2 tarafında SDK'nın kendisi ücretsizdir ama bu görünür ücretsizlik yanıltıcı: geliştirici, App Store Server API entegrasyonunu, JWS doğrulamasını, webhook alıcısını ve — çok mağazalıysa — Google Play RTDN entegrasyonunu kendi yazar. Bu işin mühendislik-saati karşılığı, MTR onbinlerce dolara çıkana kadar genellikle o %1'i aşar. Sonuç: erken ve orta ölçekli uygulamalarda $2.500 eşiği, "ücretsiz SDK ama pahalı entegrasyon" ile "ücretli SDK ama bedava entegrasyon" arasındaki gerçek dengeyi netleştiriyor. Mağaza komisyonu (Apple: Small Business Program'da %15, üstünde standart oran; Google'da abonelikte AEA/Birleşik Krallık/ABD işlemleri için %10+%5, diğer pazarlarda — Türkiye dâhil — %15) her iki senaryoda da aynı — bu maliyet RevenueCat/StoreKit seçiminden bağımsız.
Sunucu Tarafı Doğrulama Yükü
StoreKit 2 + kendi backend'inde, App Store Server API'nin JWS-imzalı yanıtlarını sunucunda doğrulamak, Get All Subscription Statuses / Get Transaction History / Get Refund History çağrılarını orkestre etmek ve Get Notification History ile 180 günlük (sandbox'ta 30 günlük) kaçırılan bildirim penceresini telafi etmek senin sorumluluğunda (developer.apple.com/documentation/appstoreserverapi). App Store Server Notifications V1 kullanımdan kaldırıldı, V2 endpoint'ini sunucunda zorunlu olarak implemente etmen gerekiyor.
RevenueCat bu katmanı SDK + backend olarak soyutlar: sen yalnızca customerInfo().entitlements["pro"].isActive gibi bir sorguyla entitlement durumunu okursun, imza doğrulama ve retry mantığı RevenueCat'in sunucusunda çözülür. İstersen webhook da dinleyebilirsin — başarısız teslimat 5 kez, artan gecikmeyle (5, 10, 20, 40, 80 dakika) otomatik yeniden denenir (revenuecat.com/docs/webhooks). Sen bir geliştirici olarak hangi tarafı seçersen seç, doğrulama mantığının bir yerde yazılması şart; fark, o mantığın senin sunucunda mı yoksa RevenueCat'in sunucusunda mı yaşadığı.
Çok Mağazalı Tek Gerçeklik Kaynağı
RevenueCat açıkça "App Store, Google Play, Amazon ve web abonelikleri arasında tek gerçeklik kaynağı" iddiasında ve dokümanlarında "günde milyarlarca API çağrısı RevenueCat sunucularında durum kontrol ediyor" diyor (revenuecat.com/docs/migrating-to-revenuecat/migration-paths). Entitlement kavramı, aynı projede yer alan tüm uygulamalar arasında paylaşılır (revenuecat.com/docs/getting-started/entitlements) — yani kullanıcı hangi mağazadan satın aldıysa alsın, senin kodun tek bir "pro mu değil mi" sorgusu yapar.
Saf StoreKit 2 seçtiğinde bu tekilleştirme senin işin. Apple tarafında App Store Server Notifications V2 kendi bildirim şemasını kullanırken, Google Play tarafında tamamen farklı bir protokol var: Cloud Pub/Sub tabanlı Real-time Developer Notifications, base64 kodlu mesajlar ve 1'den 22'ye kadar giden ayrı bir notificationType numaralandırması (developer.android.com/google/play/billing/rtdn-reference). Bu iki farklı payload şemasını, iki farklı imza doğrulama mantığını ve iki farklı abonelik-durumu temsilini kendi veri modelinde birleştirmek — RevenueCat'in tam olarak çözdüğü problem budur. Tek platformlu (yalnız App Store) kalıyorsan bu maliyet oluşmaz.
Webhook, İade ve Analitik/LTV Araçları
RevenueCat'in webhook event matrisi App Store, Google Play, Amazon, Stripe, Promo, Roku, Paddle ve RevenueCat Billing sütunlarını tek bir formatta normalize eder (revenuecat.com/docs/integrations/webhooks/event-types-and-fields); dashboard'da MRR, Revenue (mağaza kesintisi öncesi brüt, son 28 gün), Active Trials, Active/New Customers gibi metrikler hazır gelir (revenuecat.com/docs/dashboard-and-metrics/overview). Sen bu verileri sıfırdan hesaplamak zorunda kalmazsın.
StoreKit 2 + kendi backend'inde bu analitiklerin hiçbiri hazır değil: App Store Server API ve Play Developer API'nin ham verisinden MRR, kohort, LTV gibi metrikleri kendin türetmen gerekir. Paywall A/B testi de aynı şekilde — RevenueCat'in Growth Tools'u hazır bir deney altyapısı sunarken, StoreKit 2'nin kendisi hiçbir paywall deneyi yeteneği içermez; bunu React/SwiftUI tarafında sıfırdan kodlaman gerekir. İade yönetimi tarafında da StoreKit 2 Get Refund History çağrısını sağlar ama senin sunucunda bu bilgiyi entitlement'a çevirecek mantığı sen yazarsın; RevenueCat webhook üzerinden bunu otomatik senkronize eder.
Vendor Lock-in ve Veri Taşınabilirliği
RevenueCat'in SDK'ları (purchases-ios, purchases-android) MIT lisanslı ve açık kaynaktır (GitHub API'de license.key:"mit" — 24 Eylül 2026); kod düzeyinde bir kilitlenme yok. REST API v2 ile müşteri ve işlem verisi dışa aktarılabilir (revenuecat.com/docs/api-v2) ve resmi bir migrasyon danışmanlığı sunuluyor: "RevenueCat ekibinden biriyle çalışarak özel migrasyon planını oluştur" (revenuecat.com/docs/migrating-to-revenuecat/migration-paths). Yine de iş mantığın — entitlement modeli, offering yapısı — RevenueCat'in soyutlamasına bağlanır; bir gün ayrılmak istersen bu modeli native koda "deşifre etmen" gerekir.
Saf StoreKit 2 + kendi sunucunda böyle bir geçiş maliyeti hiç oluşmaz, çünkü veri zaten first-party'dir ve taşınacak bir üçüncü taraf yok. Bu, uzun ömürlü kurumsal ürünler veya vendor bağımsızlığını stratejik önceliğe koyan ekipler için StoreKit 2'yi savunulabilir kılan bir gerekçe.
KVKK/Veri Yerleşimi ve Üçüncü Tarafa Gelir Verisi Aktarımı
Bu, iki yaklaşım arasındaki en somut hukuki farktır. RevenueCat kullanıldığında gelir ve kullanıcı verisi bir üçüncü taraf "processor" rolüne akar (revenuecat.com/gdpr/: "RevenueCat is considered a 'processor'"), bir DPA (veri işleme sözleşmesi) imzalanması ve KVKK madde 9 kapsamında yurt dışına aktarım değerlendirmesi yapılması gerekir. Veri silme talepleri ayrı bir e-posta süreciyle ([email protected]) yönetilir — bu, mevcut bir onay/aydınlatma metnine ek madde eklemeyi gerektirebilir.
Saf StoreKit 2 + kendi sunucun modelinde veri akışı yalnızca Apple (birinci taraf mağaza, kullanıcının zaten işlem yaptığı taraf) ile senin sunucun arasındadır — ek bir üçüncü taraf veri işlemcisi devreye girmez. Tek platformlu, basit ve gelir verisini hiçbir şekilde dışarı vermek istemeyen bir uygulama için bu, saf StoreKit 2'yi savunulabilir kılan en net gerekçedir. Sen KVKK'ya hassas bir ürün yapıyorsan, bu maddeyi maliyet karşılaştırmasının önüne koymalısın.