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 方案是站得住脚的。如果是多商店场景,把 RTDN 的 18 种通知类型和 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

优点

  • 月度跟踪收入(MTR)在 $2,500 以内完全免费,超出部分仅收取 1%
  • 为 App Store、Google Play、Amazon、Stripe 和 Web 提供统一的权益(entitlement)模型
  • SDK 采用 MIT 许可、开源,数据可通过 REST API v2 导出
  • Webhook 会以递增延迟(5-80 分钟)自动重试最多 5 次
  • 仪表盘自带 MRR、Revenue、Active/New Customers 等现成指标
  • 可以申请官方迁移方案咨询(与 RevenueCat 团队定制专属方案)
  • Paywall、A/B 测试和 Web-to-App 转化漏斗工具(Growth Tools)开箱即用
  • iOS SDK 5.91.0(2026 年 9 月 23 日)与 Android SDK 10.23.0(2026 年 9 月 24 日)——保持每周发布节奏

缺点

  • MTR 超过 $2,500 后,各商店的收入都会流向第三方「processor」(需要依据 KVKK 第 9 条进行评估)
  • 你的业务逻辑(权益/Offering 模型)会绑定在 RevenueCat 的抽象层上
  • Paywall 和 A/B 测试数据与购买数据一样,都汇总在同一个第三方「processor」中
  • purchases-android 仓库的社区规模小于 purchases-ios(560 星 vs 3,070 星)
  • 对于单平台、产品单一的简单应用,可能带来过度的抽象

最适合

同时在 App Store、Play 和 Web 上销售的订阅产品月度跟踪收入低于 $2,500 的早期阶段应用希望快速搭建 Paywall A/B 测试及队列/LTV 分析的小团队不想手写退款和订阅状态同步逻辑的团队希望在 iOS+Android+Web 多平台上拥有统一权益数据源的产品

StoreKit 2 (kendi altyapın)

优点

  • 没有 SDK 费用——随 Apple 操作系统自带,没有额外的许可成本
  • 收入/用户数据不会流向任何第三方,不存在额外的「processor」
  • AppTransaction 和收据均由 App Store 进行加密签名
  • 没有供应商锁定——架构完全掌握在你手中,不依赖 RevenueCat
  • 可以通过 App Store Server API 补齐 180 天(沙盒环境为 30 天)的通知历史
  • 在 Apple 自家平台上获得一等支持,并有 WWDC 分享作为文档

缺点

  • 只覆盖 Apple 生态系统;Play 这边需要完全独立的集成(RTDN + Billing Library)
  • 必须在服务器上验证 JWS 签名响应,并自行编写重试/退避逻辑
  • App Store Server Notifications V1 已被弃用,服务器端必须实现 V2 端点
  • Play Billing Library 更新频繁(8.3.0 和 9.1.0 带来重大 API 新增,9.0.0 带来行为变更)——维护负担持续存在
  • Paywall A/B 测试、队列/LTV 仪表盘等工具都需要从零开发
  • 将 Play RTDN 编号 1 至 22 中的 18 种订阅通知类型与 App Store V2 通知归并成统一模型,是另一项独立的工程工作

最适合

单一平台(仅 App Store)、产品单一的简单订阅模式完全不希望把收入数据交给第三方、对数据合规(KVKK)敏感的应用已经拥有成熟后端团队、不介意自行处理 JWS 验证的中大型公司希望避免供应商锁定、生命周期较长的企业级产品需要高度定制、无法适配 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 - 监听 Transaction 与权益检查(自建基础设施)
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 方案是站得住脚的。如果是多商店场景,把 RTDN 的 18 种通知类型和 App Store V2 通知并行同步维护起来成本很高;按一个粗略的经验法则,当 MTR 达到 $50,000+ 时,应该重新权衡这个决定。

获取免费咨询
常见问题

常见问题

如果月度跟踪收入(MTR)低于 $2,500,RevenueCat 实际上是免费的,并且会承担多商店服务器端验证、webhook、退款管理等工作——这种情况下通常选择 RevenueCat 更合理。对于单一平台、产品简单、不希望把收入数据交给第三方的应用,纯 StoreKit 2 是一个站得住脚的选择。对于多商店、处于增长期的产品,自建基础设施通常成本更高。

相关博客文章

查看全部文章
全部对比