RevenueCat vs StoreKit 2 (kendi altyapın) 比較

マルチストア対応のサブスク基盤をSDK+バックエンドとしてレンタルする

VS
StoreKit 2 (kendi altyapın)

Appleのファーストパーティフレームワークだが、サーバー側は自分で書く

16 分で読了Services

クイック結論

閾値は明確だ。月間トラッキング収益(MTR)が2,500ドル未満ならRevenueCatは事実上無料——そこで比較すべきは1%ではなくゼロコストであり、自前基盤は常にそれより高くつく。App Storeのみで販売する単一製品かつ個人情報保護に敏感な製品では、純粋な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に対応する単一のエンタイトルメントモデル
  • SDKはMITライセンスのオープンソースで、データはREST API v2でエクスポート可能
  • Webhookは5回、増加する遅延(5〜80分)で自動的に再試行される
  • ダッシュボードにMRR、Revenue、Active/New Customersなどの指標がすぐに使える形で提供される
  • 公式の移行プランに関するコンサルティングを依頼できる(RevenueCatチームとの個別プラン)
  • ペイウォール、A/Bテスト、web-to-appファネルツール(Growth Tools)が標準で付属
  • iOS SDK 5.91.0(2026年9月23日)、Android SDK 10.23.0(2026年9月24日)——週次のリリースペース

短所

  • MTR2,500ドルを超えると各ストアからの収益が第三者の「processor」に流れる(越境データ移転の評価が必要)
  • ビジネスロジック(エンタイトルメント/オファリングモデル)がRevenueCatの抽象化に紐づく
  • ペイウォールとA/Bテストのデータも、購入データと同じ第三者の「processor」に集約される
  • purchases-androidリポジトリはpurchases-iosに比べてコミュニティ規模が小さい(560 vs 3,070スター)
  • 単一プラットフォームでシンプルな単一製品のアプリには、過剰な抽象化になりかねない

最適な用途

App Store+Play+Webで同時に販売されるサブスクリプション製品月間トラッキング収益が2,500ドル未満の初期段階のアプリペイウォールの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で動作変更)——保守負荷が継続的に発生
  • ペイウォールのA/Bテストやコホート/LTVダッシュボードなどのツールはゼロから構築する必要がある
  • Play RTDNの1〜22の番号を持つ18種類のサブスクリプション通知タイプをApp Store V2通知と1つのモデルに統合するのは、それ自体が別のエンジニアリング作業となる

最適な用途

単一プラットフォーム(App Storeのみ)のシンプルな単一製品サブスクリプションモデル収益データを一切第三者に渡したくない、個人情報保護に敏感なアプリすでに成熟したサーバーチームを持ち、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 - トランザクションの監視とエンタイトルメント確認(自前基盤)
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のみで販売する単一製品かつ個人情報保護に敏感な製品では、純粋なStoreKit 2も擁護できる。マルチストアの場合、RTDNの18種類の通知タイプとApp Store V2通知を並行して同期させ続けるのはコストがかさむ。おおまかな経験則として、MTRが50,000ドル以上になったら判断を再検討すべきだ。

無料相談を受ける
FAQ

よくある質問

月間トラッキング収益(MTR)が2,500ドル未満ならRevenueCatは事実上無料で、マルチストアのサーバー側検証、Webhook、返金管理を引き受けてくれる——この場合は概してRevenueCatが合理的だ。単一プラットフォームでシンプルな単一製品、かつ収益データを第三者に渡したくないアプリでは、純粋なStoreKit 2も擁護できる選択肢だ。マルチストアで成長中の製品では、自前基盤を書くことは通常より高くつく。

関連ブログ記事

すべての記事を見る
すべての比較