RevenueCat vs StoreKit 2 (kendi altyapın) Vergleich

Miete Multi-Store-Abo-Infrastruktur als SDK + Backend

VS
StoreKit 2 (kendi altyapın)

Apples First-Party-Framework, aber die Serverseite schreibst du selbst

16 Min. LesezeitServices

Schnelles Fazit

Die Schwelle ist eindeutig: Liegt der monatlich verfolgte Umsatz (MTR) unter $2.500, ist RevenueCat praktisch kostenlos – dort vergleichst du nicht mit 1 %, sondern mit null Kosten, und deine eigene Infrastruktur bleibt daneben immer teurer. Bei einem Produkt, das nur über den App Store verkauft wird, ein einziges Produkt hat und datenschutzsensibel ist, lässt sich reines StoreKit 2 verteidigen. Bist du in mehreren Stores aktiv, wird es teuer, die 18 Benachrichtigungstypen der RTDN parallel mit den App-Store-V2-Benachrichtigungen synchron zu halten; als grobe Faustregel solltest du die Entscheidung ab einem MTR von $50.000+ neu abwägen.

RevenueCatStoreKit 2 (kendi altyapın)
Vollständiges Fazit lesen

Punktevergleich

Diagramm wird geladen...

Detaillierte Bewertung

Detaillierte Bewertung: RevenueCat und StoreKit 2 (kendi altyapın) — Bewertungen pro Kategorie auf einer Skala von 1 bis 10
KategorieRevenueCatStoreKit 2 (kendi altyapın)
Performance
8/10
8/10
Erlernbarkeit
8/10
5/10
Ökosystem
8/10
6/10
Community
6/10
5/10
Arbeitsmarkt
5/10
6/10
Zukunftssicherheit
8/10
8/10

Vor- und Nachteile

RevenueCat

Vorteile

  • Bis zu einem monatlich verfolgten Umsatz (MTR) von $2.500 komplett kostenlos, darüber nur 1 %
  • Ein einziges Entitlement-Modell für App Store + Google Play + Amazon + Stripe + Web
  • SDKs sind MIT-lizenziert und Open Source, Daten lassen sich über die REST API v2 exportieren
  • Webhooks werden automatisch 5-mal mit steigender Verzögerung (5–80 Min.) erneut zugestellt
  • Fertige Metriken wie MRR, Revenue, Active/New Customers sind direkt im Dashboard verfügbar
  • Eine offizielle Migrationsberatung kann angefragt werden (individueller Plan mit dem RevenueCat-Team)
  • Paywall-, A/B-Test- und Web-to-App-Funnel-Tools (Growth Tools) sind bereits enthalten
  • iOS-SDK 5.91.0 (23. Sep. 2026) und Android-SDK 10.23.0 (24. Sep. 2026) — wöchentlicher Release-Rhythmus

Nachteile

  • Oberhalb von $2.500 MTR fließt der Umsatz aus jedem Store an einen dritten 'Processor' (eine Prüfung der Datenübermittlung ist erforderlich)
  • Deine Geschäftslogik (Entitlement-/Offering-Modell) wird an die Abstraktion von RevenueCat gebunden
  • Paywall- und A/B-Test-Daten werden beim selben Drittanbieter-Processor gesammelt wie die Kaufdaten
  • Das purchases-android-Repo hat eine kleinere Community als purchases-ios (560 vs. 3.070 Sterne)
  • Kann bei einer einfachen Single-Platform-App mit nur einem Produkt unnötig viel Abstraktion mit sich bringen

Am besten geeignet für

Abo-Produkte, die gleichzeitig über App Store + Play + Web verkauft werdenFrühphasen-Apps mit einem monatlich verfolgten Umsatz unter $2.500Kleine Teams, die Paywall-A/B-Tests und Kohorten-/LTV-Analysen schnell aufsetzen möchtenTeams, die Rückerstattungs- und Abo-Status-Synchronisation nicht manuell schreiben möchtenProdukte, die für iOS+Android+Web eine einzige Entitlement-Quelle wollen

StoreKit 2 (kendi altyapın)

Vorteile

  • Keine SDK-Gebühr — kommt mit dem Apple-Betriebssystem, keine zusätzlichen Lizenzkosten
  • Umsatz-/Nutzerdaten fließen an keinen Dritten, es gibt keinen zusätzlichen 'Processor'
  • AppTransaction und Belege werden vom App Store kryptografisch signiert
  • Kein Vendor-Lock-in — die Architektur liegt vollständig bei dir, keine Abhängigkeit von RevenueCat
  • Mit der App Store Server API lässt sich ein 180-tägiges (im Sandbox 30-tägiges) Benachrichtigungsfenster nachträglich abgleichen
  • Wird auf Apples eigener Plattform erstklassig unterstützt und in WWDC-Sessions dokumentiert

Nachteile

  • Deckt nur das Apple-Ökosystem ab; für die Play-Seite ist eine komplett separate Integration (RTDN + Billing Library) nötig
  • Du musst die JWS-signierten Antworten auf deinem Server validieren und die Retry-/Backoff-Logik selbst schreiben
  • App Store Server Notifications V1 wurde eingestellt, der V2-Endpoint ist auf deinem Server zwingend erforderlich
  • Die Play Billing Library wird häufig aktualisiert (8.3.0 und 9.1.0 mit großen API-Erweiterungen, 9.0.0 mit Verhaltensänderungen) — laufender Wartungsaufwand
  • Tools wie Paywall-A/B-Tests oder ein Kohorten-/LTV-Dashboard müssen von Grund auf selbst geschrieben werden
  • Die 18 von 1 bis 22 nummerierten Abo-Benachrichtigungstypen der Play RTDN mit den App-Store-V2-Benachrichtigungen auf ein einziges Modell zu reduzieren, ist ein eigenständiges Engineering-Projekt

Am besten geeignet für

Single-Platform-Modelle (nur App Store) mit einem einzigen, einfachen Abo-ProduktDatenschutzsensible Apps, die Umsatzdaten unter keinen Umständen an Dritte weitergeben wollenMittelgroße bis große Unternehmen mit einem bereits erfahrenen Server-Team, für die JWS-Validierung kein Problem istLanglebige Unternehmensprodukte, die Vendor-Lock-in vermeiden wollenGeschäftsregeln mit hohem Individualisierungsbedarf, die nicht in RevenueCats Abstraktion passen

Code-Vergleich

RevenueCat
// RevenueCat - Entitlement-Prüfung und Kauf (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-Entitlement aktiv")
        }
    } catch {
        print("customerInfo Fehler: \(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("Kauf erfolgreich, Pro aktiv")
        }
    } catch {
        print("Kauffehler: \(error)")
    }
}
StoreKit 2 (kendi altyapın)
// StoreKit 2 - Transaction-Listening und Entitlement-Prüfung (eigene Infrastruktur)
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("Verifizierung fehlgeschlagen: \(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 an den Server senden, mit der App Store Server API gegenprüfen
}

Fazit

Die Schwelle ist eindeutig: Liegt der monatlich verfolgte Umsatz (MTR) unter $2.500, ist RevenueCat praktisch kostenlos – dort vergleichst du nicht mit 1 %, sondern mit null Kosten, und deine eigene Infrastruktur bleibt daneben immer teurer. Bei einem Produkt, das nur über den App Store verkauft wird, ein einziges Produkt hat und datenschutzsensibel ist, lässt sich reines StoreKit 2 verteidigen. Bist du in mehreren Stores aktiv, wird es teuer, die 18 Benachrichtigungstypen der RTDN parallel mit den App-Store-V2-Benachrichtigungen synchron zu halten; als grobe Faustregel solltest du die Entscheidung ab einem MTR von $50.000+ neu abwägen.

Kostenlose Beratung erhalten
FAQ

Häufig gestellte Fragen

Liegt der monatlich verfolgte Umsatz (MTR) unter $2.500, ist RevenueCat praktisch kostenlos und übernimmt die serverseitige Multi-Store-Validierung, Webhooks und die Rückerstattungsverwaltung – in diesem Fall ist RevenueCat meist sinnvoll. Bei einer Single-Platform-App mit einem einzigen einfachen Produkt, die Umsatzdaten nicht an Dritte weitergeben möchte, ist reines StoreKit 2 eine vertretbare Option. Bei einem wachsenden Multi-Store-Produkt kommt eine selbst geschriebene Infrastruktur meist teurer.

Verwandte Blogartikel

Alle Artikel ansehen
Alle Vergleiche