RevenueCat vs StoreKit 2 (kendi altyapın) مقارنة

استأجر بنية اشتراكات متعددة المتاجر كـ SDK + خادم خلفي

VS
StoreKit 2 (kendi altyapın)

إطار عمل Apple من الطرف الأول، لكنك تكتب جانب الخادم بنفسك

16 دقائق للقراءةServices

الحكم السريع

العتبة واضحة: إذا كان الإيراد المتتبَّع شهريًا (MTR) أقل من $2,500، فإن RevenueCat مجاني عمليًا؛ وما تقارنه هناك ليس نسبة 1%، بل تكلفة صفر — بنيتك الخاصة تبقى دائمًا أغلى مقارنة بذلك. في منتج يُباع فقط عبر App Store، بمنتج واحد، وحسّاس من ناحية KVKK، يمكن الدفاع عن StoreKit 2 الخالص. إذا كنت تبيع عبر متاجر متعددة، فإن إبقاء 18 نوعًا من إشعارات RTDN متزامنة بالتوازي مع إشعارات App Store V2 يصبح مكلفًا؛ وكقاعدة عامة تقريبية، أعد وزن القرار عندما يتجاوز MTR $50,000.

RevenueCatStoreKit 2 (kendi altyapın)
اقرأ الخلاصة كاملة

مقارنة الدرجات

جارٍ تحميل الرسم البياني...

التقييم التفصيلي

التقييم التفصيلي: RevenueCat و StoreKit 2 (kendi altyapın) — درجات كل فئة من 10
الفئةRevenueCatStoreKit 2 (kendi altyapın)
الأداء
8/10
8/10
سهولة التعلّم
8/10
5/10
النظام البيئي
8/10
6/10
المجتمع
6/10
5/10
سوق العمل
5/10
6/10
الاستدامة المستقبلية
8/10
8/10

الإيجابيات والسلبيات

RevenueCat

الإيجابيات

  • مجاني بالكامل حتى $2,500 من الإيراد المتتبَّع شهريًا (MTR)، وما فوق ذلك 1% فقط
  • نموذج استحقاق (entitlement) واحد لـ App Store وGoogle Play وAmazon وStripe والويب
  • الـ SDKs مرخّصة بموجب MIT ومفتوحة المصدر، ويمكن تصدير البيانات عبر REST API v2
  • تُعاد محاولة الـ Webhooks تلقائيًا 5 مرات بتأخير متزايد (5-80 دقيقة)
  • لوحة التحكم تأتي جاهزة بمقاييس MRR وRevenue وActive/New Customers
  • يمكن طلب استشارة رسمية لخطة الترحيل (خطة مخصصة مع فريق RevenueCat)
  • أدوات Paywall واختبار A/B وقمع التحويل من الويب إلى التطبيق (Growth Tools) تأتي جاهزة
  • iOS SDK بإصدار 5.91.0 (23 سبتمبر 2026) وAndroid SDK بإصدار 10.23.0 (24 سبتمبر 2026) — وتيرة إصدار أسبوعية

السلبيات

  • فوق $2,500 من MTR، يتدفق الإيراد من كل متجر إلى 'processor' طرف ثالث (يتطلب تقييمًا بموجب المادة 9 من KVKK)
  • منطق عملك (نموذج entitlement/offering) يرتبط بتجريد RevenueCat
  • بيانات Paywall واختبار A/B تُجمع أيضًا في نفس 'processor' الطرف الثالث مع بيانات الشراء
  • مستودع purchases-android لديه مجتمع أصغر مقارنة بـ purchases-ios (560 مقابل 3,070 نجمة)
  • قد يجلب تجريدًا أكثر من اللازم في تطبيق أحادي المنصة وبسيط بمنتج واحد

الأنسب لـ

منتجات الاشتراك التي تُباع في وقت واحد عبر App Store وPlay والويبالتطبيقات في المرحلة المبكرة التي يقل فيها الإيراد المتتبَّع شهريًا عن $2,500الفرق الصغيرة التي تريد إعداد اختبار A/B لـ Paywall وتحليل الأفواج/LTV بسرعةمن لا يريدون كتابة مزامنة الاسترجاع/التراجع وحالة الاشتراك يدويًاالمنتجات التي تريد مصدر استحقاق واحد عبر منصات متعددة (iOS+Android+الويب)

StoreKit 2 (kendi altyapın)

الإيجابيات

  • لا توجد رسوم SDK — يأتي مع نظام تشغيل Apple، وتكلفة الترخيص الإضافية صفر
  • بيانات الإيراد/المستخدم لا تتدفق إلى أي طرف ثالث، لا يوجد 'processor' إضافي
  • AppTransaction والإيصالات موقّعة تشفيريًا من قِبل App Store
  • لا يوجد ارتباط بمزوّد (vendor lock-in) — البنية بالكامل بين يديك، ولا ينشأ اعتماد على RevenueCat
  • يمكن تعويض سجل الإشعارات لمدة 180 يومًا (30 يومًا في sandbox) عبر App Store Server API
  • مدعوم بدعم من الدرجة الأولى على منصة Apple نفسها وموثّق عبر جلسات WWDC

السلبيات

  • يغطي نظام Apple البيئي فقط؛ يتطلب جانب Play تكاملًا منفصلًا تمامًا (RTDN + Billing Library)
  • يجب عليك التحقق من الاستجابات الموقّعة بـ JWS على خادمك، وكتابة منطق retry/backoff بنفسك
  • أصبح App Store Server Notifications V1 غير مستخدم، ونقطة نهاية V2 إلزامية على خادمك
  • تُحدَّث Play Billing Library بشكل متكرر (إضافات API كبيرة في 8.3.0 و9.1.0، وتغييرات سلوكية في 9.0.0) — عبء الصيانة مستمر
  • يجب كتابة أدوات مثل اختبار A/B لـ Paywall ولوحة تحكم الأفواج/LTV من الصفر
  • اختزال 18 نوعًا من إشعارات الاشتراك في Play RTDN (المرقّمة من 1 إلى 22) مع إشعارات App Store V2 في نموذج واحد هو عمل هندسي منفصل

الأنسب لـ

نماذج اشتراك أحادية المنصة (App Store فقط)، بسيطة وبمنتج واحدالتطبيقات الحسّاسة من ناحية KVKK التي لا تريد نقل بيانات الإيراد لطرف ثالث بأي شكلالشركات المتوسطة إلى الكبيرة التي لديها بالفعل فريق خادم ناضج ولا تمانع التحقق عبر JWSالمنتجات المؤسسية طويلة الأمد التي تريد تجنّب الارتباط بمزوّد (vendor lock-in)قواعد العمل التي تتطلب تخصيصًا عاليًا ولا تتناسب مع تجريد RevenueCat

مقارنة الكود

RevenueCat
// RevenueCat - فحص الاستحقاق وإجراء الشراء (iOS SDK 5.x)
import RevenueCat

func configureRevenueCat() {
    Purchases.logLevel = .debug
    Purchases.configure(withAPIKey: "appl_XXXXXXXXXXXX")
}

func unlockProIfEntitled() async {
    do {
        let customerInfo = try await Purchases.shared.customerInfo()
        if customerInfo.entitlements["pro"]?.isActive == true {
            print("استحقاق Pro مُفعّل")
        }
    } catch {
        print("خطأ customerInfo: \(error)")
    }
}

func purchasePro() async {
    do {
        let offerings = try await Purchases.shared.offerings()
        guard let package = offerings.current?.availablePackages.first else { return }

        let result = try await Purchases.shared.purchase(package: package)
        if result.customerInfo.entitlements["pro"]?.isActive == true {
            print("تم الشراء بنجاح، Pro مُفعّل")
        }
    } catch {
        print("خطأ في الشراء: \(error)")
    }
}
StoreKit 2 (kendi altyapın)
// StoreKit 2 - الاستماع للمعاملات وفحص الاستحقاق (بنيتك الخاصة)
import StoreKit

func listenForTransactions() -> Task<Void, Error> {
    Task.detached {
        for await result in Transaction.updates {
            switch result {
            case .verified(let transaction):
                await grantEntitlement(for: transaction)
                await transaction.finish()
            case .unverified(_, let error):
                print("فشل التحقق: \(error)")
            }
        }
    }
}

func checkCurrentEntitlement() async -> Bool {
    for await result in Transaction.currentEntitlements {
        guard case .verified(let transaction) = result else { continue }
        if transaction.productID == "pro_monthly" {
            return true
        }
    }
    return false
}

func purchase(product: Product) async throws {
    let result = try await product.purchase()
    switch result {
    case .success(let verification):
        guard case .verified(let transaction) = verification else { return }
        await grantEntitlement(for: transaction)
        await transaction.finish()
    case .userCancelled, .pending:
        break
    @unknown default:
        break
    }
}

func grantEntitlement(for transaction: Transaction) async {
    // أرسل JWS إلى الخادم، وتحقّق بشكل متقاطع عبر App Store Server API
}

الخلاصة

العتبة واضحة: إذا كان الإيراد المتتبَّع شهريًا (MTR) أقل من $2,500، فإن RevenueCat مجاني عمليًا؛ وما تقارنه هناك ليس نسبة 1%، بل تكلفة صفر — بنيتك الخاصة تبقى دائمًا أغلى مقارنة بذلك. في منتج يُباع فقط عبر App Store، بمنتج واحد، وحسّاس من ناحية KVKK، يمكن الدفاع عن StoreKit 2 الخالص. إذا كنت تبيع عبر متاجر متعددة، فإن إبقاء 18 نوعًا من إشعارات RTDN متزامنة بالتوازي مع إشعارات App Store V2 يصبح مكلفًا؛ وكقاعدة عامة تقريبية، أعد وزن القرار عندما يتجاوز MTR $50,000.

احصل على استشارة مجانية
الأسئلة الشائعة

الأسئلة الشائعة

إذا كان الإيراد المتتبَّع شهريًا (MTR) أقل من $2,500، فإن RevenueCat مجاني عمليًا ويتولى مهام التحقق من جانب الخادم لمتاجر متعددة، وWebhook، وإدارة الاسترجاع — في هذه الحالة يكون RevenueCat منطقيًا غالبًا. في تطبيق أحادي المنصة، بمنتج واحد بسيط، ولا يريد تسليم بيانات الإيراد لطرف ثالث، يُعد StoreKit 2 الخالص خيارًا يمكن الدفاع عنه. أما في منتج متعدد المتاجر وينمو باستمرار، فكتابة بنيتك الخاصة تصبح عادةً أغلى تكلفة.

مقالات مدونة ذات صلة

عرض جميع المقالات
جميع المقارنات