RevenueCat-Alternativen 2026: Die richtige Subscription-Plattform für mobile Apps wählen

RevenueCat ist die lauteste Marke in der mobilen Subscription-Infrastruktur, und für viele Teams ist sie auch die richtige Antwort. Aber "am lautesten" und "richtig" sind nicht dasselbe, und die 1%-MTR-Gebühr auf den Bruttoumsatz fühlt sich anders an, sobald eine App 100k MTR überschreitet. Die Landschaft 2026 ist auch voller als vor zwei Jahren: Adaptys Paywall-Experimentierung ist bei der Rigorosität vorn, Qonversion bietet für kleine Teams immer noch das beste Analytics-pro-Euro-Verhältnis, Apphuds Rules Engine hat eine treue Fangemeinde für Win-back-Flows, und Chargebee und Stripe Billing tauchen immer wieder in hybriden Architekturen auf, die mobile IAP mit Web-Checkout mischen.

Dieser Beitrag ist ein entscheidungsorientierter Vergleich von sechs Plattformen (RevenueCat, Adapty, Qonversion, Apphud, Chargebee und Stripe Billing) mit dem Ziel, erfahrenen Mobile- und Backend-Entwicklern zu helfen, die richtige für eine bestimmte App-Phase, Plattform-Mischung und Region zu wählen. Er deckt auch die Post-DMA-Realität externer Zahlungen, StoreKit 2 und Google Play Billing v7 Fallstricke und die Migrationskosten ab, die es selten auf Marketing-Seiten schaffen.

Die Landschaft 2026#

Zwei Gruppen von Tools konkurrieren um dasselbe Logo auf einem Slide-Deck, lösen aber unterschiedliche Probleme.

• Mobile-first-Infrastruktur: RevenueCat, Adapty, Qonversion, Apphud. Gebaut rund um StoreKit und Google Play Billing. Entitlements sind die Kernabstraktion. Paywall-Builder, A/B-Tests und Attribution-Integrationen sind Standard.
• Cross-Platform-Billing: Chargebee, Stripe Billing. Gebaut rund um Web-Subscriptions, Katalog, Steuern und Rechnungsstellung. Mobile ist ein nachträglicher Aufsatz, und für digitale Güter in einer mobilen App sind Apple und Google IAP außerhalb schmaler DMA- und US-Post-Epic-Ausnahmen immer noch Pflicht.

Die meisten ernsthaften Apps 2026 fahren ein hybrides Modell: IAP auf Mobile für digitale Güter, Web-Checkout (Stripe oder Chargebee) für Upgrades, B2B-Sitze und DMA-fähige externe Zahlungen. Die Wahl ist selten "welches eine Tool gewinnt" und viel öfter "welche mobile Plattform plus welche Web-Plattform, abgeglichen über eine einzige Nutzeridentität."

Entscheidungsrahmen#

Bevor wir in Features und Preise eintauchen, hier ein Entscheidungsdiagramm, das die meisten Teams zu einem vernünftigen Default leitet. Nimm es als Startpunkt, nicht als Urteil.

Die Zweige entsprechen echten Beschränkungen: Wenn du unter 2.500 Dollar MTR bist, tut es jeder Free-Tier, und zu optimieren ist Verschwendung von Engineering-Zeit. Über 100k MTR ist die 1%-Bruttogebühr bei RevenueCat eine Position, die dein Finance-Team bemerken wird, und Adapty, Apphud oder Qonversion kommen ins Spiel. Wenn du auch im Web abrechnen musst, landest du fast immer hybrid.

Feature-Vergleich#

Die Dimensionen, die bei einer Plattform-Entscheidung zählen, sind weniger, als Hersteller-Seiten vermuten lassen. Ignoriere die rohen Feature-Zahlen und konzentriere dich auf diese.

Zwei Beobachtungen. Erstens sind die vier Mobile-first-Plattformen ähnlicher, als ihr Marketing vermuten lässt, und die Unterschiede leben in der Paywall-Experimentierungs-Rigorosität und Analytics-Tiefe, nicht in grundlegender Sanitärtechnik. Zweitens sind Chargebee und Stripe Billing keine mobilen IAP-Plattformen; sie in dieselbe Liste zu setzen, ist ein Kategorienfehler, es sei denn, du willst sie gezielt für die Web-Hälfte eines Hybrid-Setups.

Preisrealität 2026#

Preis-Seiten sind zum Überfliegen geschrieben, also machen wir die Arithmetik, die zählt.

• RevenueCat: Kostenlos bis 2.500 Dollar MTR. Darüber 1% des Brutto-MTR, wobei Brutto den Umsatz vor Store-Provision bedeutet. Auf Nicht-Small-Business-Konten entspricht das ungefähr 1,43% deiner tatsächlichen Nettoeinnahmen, nachdem Apple und Google ihren Anteil genommen haben. Keine Sitzgebühren, keine Transaktionsgebühren.
• Adapty: Nach MTR gestaffelt mit einem kostenlosen Starter-Band. Pro-Pläne schalten A/B-Tests, KI und Integrationen frei. Revenue-Share-Preise bei höheren Stufen; veröffentlichte Zahlen sind weniger granular als bei RevenueCat und erfordern auf Skala meist ein Vertriebsgespräch.
• Qonversion: Free Plan typischerweise bis 10k Dollar MTR. Bezahlte Pläne liegen bei etwa 6 bis 8 Dollar pro 1.000 Dollar MTR, je nach Starter oder Growth. Das beste Analytics-pro-Euro-Verhältnis für kleine und mittlere Apps.
• Apphud: Kostenlose Stufe bis ungefähr 1k Dollar MTR. Pro Plan rund 49 Dollar pro Monat bis ungefähr 5k Dollar MTR, Expert Plan rund 59 Dollar pro Monat für höhere Bänder mit Server-to-Server-Webhooks, darüber individuelle Preise. Rules Engine auf bezahlten Stufen enthalten.
• Chargebee: Gestaffelte SaaS-Preise beginnend bei Performance- und Enterprise-Bändern, plus Umsatzanteil über Schwellen. Das Mobile SDK ist ein Legacy-Produkt, das vom neueren Omnichannel-Subscriptions-Angebot abgelöst wird.
• Stripe Billing: grob 0,5% bis 0,7% auf wiederkehrende Zahlungen (Stripe hat die meisten Kunden Mitte 2025 von 0,5% auf 0,7% umgestellt) zusätzlich zur Zahlungsabwicklung (grob 2,9% plus 30 Cent pro Transaktion), plus 0,4% für Revenue Recognition oder Sigma. Kein MTR-Konzept; stattdessen pro Transaktion.

Ein Rechenbeispiel, um die Trade-offs konkret zu machen. Stell dir eine App mit 100k Dollar MTR vor, gleichmäßig auf iOS und Android verteilt. Auf RevenueCat liegt die Gebühr bei rund 1.000 Dollar pro Monat. Auf Adapty oder Apphud in vergleichbaren Stufen sind die Kosten wettbewerbsfähig, erfordern aber normalerweise ein individuelles Gespräch. Auf Qonversion ist die rohe MTR-Mathematik oft am günstigsten, allerdings gibst du einige Wachstumsfeatures auf. Auf Chargebee oder Stripe Billing allein kannst du diesen Umsatz für digitale Güter innerhalb der App auf beiden Plattformen nicht legal einnehmen, also ist der Vergleich hinfällig.

Jetzt betrachte 500k Dollar MTR hybrid, aufgeteilt in 70% Mobile und 30% Web. RevenueCat für Mobile ist 3.500 Dollar pro Monat, Stripe für das Web-Stück rund 0,5% von 150k Dollar oder 750 Dollar, also gesamt etwa 4.250 Dollar. Die mobile Seite durch eine DIY-Chargebee-Integration zu ersetzen, sieht auf dem Papier günstiger aus, kostet aber deutlich mehr Engineering-Zeit für Receipt Validation, Grace-Period-Handling und Webhook-Sanitärtechnik. Für jedes Team unterhalb einer dedizierten Payments-Plattform-Gruppe übersteigt dieser Aufwand typischerweise die Ersparnis.

Der ehrliche Vorbehalt: Store-Provisionen stellen alle diese Gebühren in den Schatten. Apple und Google nehmen immer noch 15% bis 30% vom Brutto, und der Unterschied zwischen RevenueCat und Adapty ist ein Rundungsfehler im Vergleich dazu, ob du für das Small Business Program oder die DMA-reduzierten Raten in der EU qualifiziert bist.

StoreKit 2 und Google Play Billing v7 Fallstricke#

Hersteller-SDKs verbergen die meiste Komplexität, aber die Edge-Cases beißen immer noch. Das sind diejenigen, die in der Produktion am häufigsten stille Fehler verursachen, egal welche Plattform du wählst.

StoreKit 2 erfordert, dass du beim App-Start Transaction.updates abonnierst, bevor irgendeine UI-Arbeit passiert. Wenn du später zuhörst, können Promoted Offers, Ask-to-Buy-Käufe und elterliche Genehmigungen ankommen, während nichts zuhört, und die Transaktion verschwindet aus der Sicht deiner App, obwohl Apple sie abgeschlossen hat. Transaction.currentEntitlements enthält außerdem keine Einträge, die nach aktivem Status erstattet wurden; für ein vollständiges Bild brauchst du Server-Benachrichtigungen.

// Muss beim App-Start laufen, nicht nach Sign-In oder Paywall-OeffnenTask.detached {    for await result in Transaction.updates {        guard case .verified(let transaction) = result else { continue }        await handleTransaction(transaction)        await transaction.finish()    }}

Google Play Billing v7 hat mehrere veraltete Felder von ProductDetails.OneTimePurchaseOfferDetails entfernt und verlangt jetzt, dass PendingPurchasesParams beim Bauen des Clients explizit konfiguriert werden. queryPurchasesAsync gibt standardmäßig keine ausstehenden Käufe mehr zurück, was Flows, die sich auf das alte Verhalten verlassen haben, still bricht.

val pendingPurchasesParams = PendingPurchasesParams.newBuilder()    .enableOneTimeProducts()    .enablePrepaidPlans()    .build()
val billingClient = BillingClient.newBuilder(context)    .setListener(purchasesUpdatedListener)    .enablePendingPurchases(pendingPurchasesParams)    .build()

Andere Edge-Cases: Rückerstattungen kommen bei Apple über die Subscription Status API und Server-to-Server Notifications v2, bei Google über Voided-Purchases-Polling. Family-Sharing-Entitlements sehen anders aus als Primärkäufe. Upgrade- und Downgrade-Proration bringt naive Webhook-Handler zu Fall. Sandbox-Tester zählen nicht zum MTR, erzeugen aber Webhook-Rauschen, das Automatisierung in Produktionsintegrationen gebrochen hat.

Webhook-Idempotenz#

Jede mobile Subscription-Plattform liefert Webhooks aus, aber ihre Event-Taxonomien unterscheiden sich. RevenueCats ist die De-facto-Referenz, an der andere Anbieter gemessen werden: INITIAL_PURCHASE, RENEWAL, PRODUCT_CHANGE, CANCELLATION, EXPIRATION, BILLING_ISSUE, SUBSCRIBER_ALIAS und so weiter. Das nicht offensichtliche ist PRODUCT_CHANGE bei Upgrades, das vor oder nach dem entsprechenden RENEWAL ankommen kann, und Deduplizierung über original_transaction_id ist der sicherste Schlüssel.

Ein minimales idempotentes Handler-Pattern:

async function handleWebhook(event: RevenueCatEvent) {  const dedupKey = `${event.type}:${event.original_transaction_id}:${event.event_timestamp_ms}`;  const inserted = await db.processedEvents.insertIfAbsent(dedupKey);  if (!inserted) return; // bereits verarbeitet
  switch (event.type) {    case "INITIAL_PURCHASE":    case "RENEWAL":    case "PRODUCT_CHANGE":      await upsertEntitlement(event);      break;    case "CANCELLATION":    case "EXPIRATION":      await revokeEntitlement(event);      break;  }}

Übersetze das einmal in einen internen Event-Bus, und Anbieter zu wechseln wird eine Frage des Umschreibens des Adapters statt der Geschäftslogik.

Migrationsüberlegungen#

Subscription-Plattformen zu wechseln ist schmerzhaft, egal in welche Richtung du gehst. Die zwei härtesten Teile sind nicht der SDK-Wechsel; es sind historische Cohort-Analytics und Entitlement-Edge-Cases.

• Entitlement-Mapping: Produkt-IDs sind flach; Entitlement-IDs sind eine Abstraktion, die jede Plattform leicht anders modelliert. Lifetime-Abonnenten und grandfathered Preis-Cohorts brauchen explizite Behandlung.
• Historische Analytics: Die meisten Plattformen können historische Transaktionen nicht sauber importieren. Plane, mindestens ein oder zwei Verlängerungszyklen lang parallel zu laufen, und akzeptiere, dass die Cohort-Historie auf der neuen Seite leer startet.
• Webhook-Neuschreibung: Taxonomien unterscheiden sich. Ein dünner Adapter, der Anbieter-Events in ein kanonisches internes Event übersetzt, ist fast immer günstiger, als nachgelagerte Consumer umzuschreiben.
• SDK-Wechsel: Führe das neue SDK hinter einem Feature-Flag ein, begrenzt auf einen kleinen Prozentsatz der Nutzer. Validiere Entitlement-Parität mit dem alten SDK für mindestens einen vollen Verlängerungszyklus, bevor du umschaltest.
• Serverseitiger Abgleich: Halte eine kanonische user_id → entitlement-Tabelle in deiner eigenen Datenbank. Diese eine Entscheidung macht jede zukünftige Migration überlebbar.

Eine konkrete Skizze für einen Wechsel von Qonversion zu Adapty: Historische Käufe aus Qonversion als CSV exportieren, als Startzustand in Adapty importieren, beide SDKs für einen Verlängerungszyklus parallel auf einer 5%-Feature-Flag-Cohort laufen lassen, Entitlement-Tabellen täglich abgleichen, dann auf 100% hochfahren, sobald die Abweichung unter einem Bruchteil eines Prozents liegt.

Anti-Patterns und häufige Fallen#

Ein paar Muster tauchen in fast jeder Post-mortem in diesem Bereich auf.

• Den Entitlement-Store des Anbieters als Quelle der Wahrheit behandeln. Er ist ein Cache. Wenn der Anbieter einen Ausfall oder Webhook-Verzögerung hat, sollte deine App auf deinen eigenen kanonischen Store zurückfallen, nicht Nutzer aussperren.
• Annehmen, dass Stripe Billing IAP für digitale Güter in einer mobilen App ersetzen kann. Kann es nicht, außer unter schmalen DMA-Bedingungen in der EU oder spezifischen US-Post-Epic-Ausnahmen, und selbst dort ist der operative Overhead real.
• Unterdimensionierte A/B-Tests auf kleinen MAU-Apps. Bayesian-Methoden (Adapty) helfen, aber sie beseitigen die Disziplin zur Stichprobengröße nicht. Ein "Gewinner" auf 200 Nutzern pro Variante ist fast immer Rauschen.
• App Store Server Notifications v2 zugunsten von client-getriebenem State ignorieren. Der Client lügt. Ein jailbreaktes Gerät oder ein getöteter Prozess kann den Webhook-Rundweg überspringen.
• PRODUCT_CHANGE bei Upgrades vergessen. Nutzer werden doppelt belastet oder verlieren Entitlements für einen Abrechnungszyklus. Schreib Integrationstests für dieses spezifische Event.
• Eigene Receipt Validation schreiben, um das 1% zu sparen. Wenn du keine dedizierte Backend-Kapazität für Rückerstattungs-Edge-Cases, Grace-Periods, Family Sharing und Voided Purchases hast, ist die Anbietergebühr billiger als die On-Call-Last.

Regulatorische Verschiebungen: DMA und Post-Epic-Ökonomie#

Der EU Digital Markets Act und die US-Post-Epic-v.-Apple-Urteile haben die Ränder dessen, was möglich ist, verändert, nicht aber das Zentrum. Apple und Google IAP sind in den meisten Regionen für die meisten digitalen Güter-Flows immer noch Pflicht. Die Ausnahmen, die sich zu verstehen lohnen:

• EU DMA: External Purchase Link Entitlement erlaubt das Verlinken zu einem Web-Checkout aus einer EU-verteilten App heraus. Apples Core Technology Commission gilt (derzeit rund 5% in der EU), was niedriger ist als die Standard-Store-Provision, aber nicht null.
• US Post-Epic: Das Urteil des Ninth Circuit vom Dezember 2025 stellte fest, dass Apple seine bisherige Provision auf externe US-Zahlungen nicht einziehen darf, und verwies den Fall an das Bezirksgericht zurück, damit dieses eine angemessene Kostenerstattungsgebühr festlegt. Apple hat weiter Berufung eingelegt. Die Situation ist in Bewegung und sollte monatlich verfolgt werden.
• Google User Choice Billing: In mehreren Regionen mit reduzierter Provisionsrate live. Weniger dramatisch als die Apple-Änderungen, aber operativ einfacher.

Praktisch koppeln DMA-fähige Hybrid-Architekturen eine mobile Plattform (RevenueCat oder Adapty) für Standard-IAP mit Stripe Checkout für den externen Kauf-Flow, abgeglichen über eine einzige Nutzeridentität im Backend. Das ist echte Arbeit, kein Flag-Umschalten, und der ROI ist nur da für Apps mit genug EU-Umsatz, um die Engineering-Investition zu rechtfertigen.

Empfehlungen nach Szenario#

Wenn du den Entscheidungsrahmen in konkrete Empfehlungen zusammenfasst:

• Solo-Entwickler oder Indie, nur iOS, unter 2.500 Dollar MTR: RevenueCat Free Tier oder Apphud Free Tier. Null Betriebskosten, und du kannst später wechseln, wenn nötig.
• Frühes Startup, nur mobil, schnelle Paywall-Iteration: Adapty für die Experimentierungs-Rigorosität oder RevenueCat Paywalls v2, wenn dir Ökosystem und Dokumentation mehr wert sind als A/B-Test-Tiefe.
• Wachstumsphase-App mit analytik-lastigem Marketing-Team: Qonversion für Kosteneffizienz oder Adapty, wenn prädiktive LTV wichtig ist.
• Scale-up mit Mobile und Web und B2B-Sitzen: Hybrid. RevenueCat oder Adapty auf Mobile, Stripe Billing auf Web, serverseitig abgeglichen.
• Enterprise-SaaS mit etwas Mobile-Bezug: Chargebee als Billing of Record, mit einer mobilen Plattform als IAP-Receipt-Broker in Chargebee.
• EU-zielgerichtete App, die DMA-externe Zahlungen plant: Hybrides Stripe plus mobile Plattform, mit expliziter Behandlung der Core Technology Commission und des External Purchase Link Entitlement.

Für reine Mobile-Apps 2026 sind RevenueCat und Adapty die zwei ernsthaften Defaults. Adapty führt bei Paywall-Experimentierung und KI-getriebener Iteration; RevenueCat führt bei Ökosystem-Breite, Dokumentation und der De-facto-Webhook-Taxonomie. Qonversion und Apphud bleiben stark für kostensensitive Teams und für spezifische Bedürfnisse wie Analytics-Tiefe oder Rules-basiertes Win-back. Chargebee und Stripe Billing gehören auf die Web-Seite einer Hybrid-Architektur, nicht als mobiler IAP-Ersatz.

Fazit#

Die Wahl der Subscription-Plattform geht weniger darum, einen Gewinner zu küren, und mehr darum, das Werkzeug an Phase, Plattform-Mischung und Region anzupassen. Die 1%-MTR-Gebühr, die Paywall-Experimentierungs-Rigorosität, die Analytics-Tiefe und die regulatorische Exposition sind alle wichtig, aber keines davon ist so wichtig wie die eine architektonische Entscheidung, deine eigene kanonische Entitlement-Tabelle zu halten. Mach das, und jede zukünftige Migration ist eine Neuschreibung eines Adapters statt einer Neuschreibung deines Geschäfts.

Wenn du bei null anfängst, wähle aus dem obigen Rahmen den Default, der zu deiner Phase und Region passt, halte deinen eigenen Entitlement-Store und investiere deine Engineering-Mühe in Paywall-Experimente und Edge-Cases, nicht darin, Receipt Validation neu zu erfinden.

Referenzen#

• RevenueCat Pricing & Plans - Offizielle Preis-Seite mit MTR-Schwellen und der 1%-Gebührenstruktur.
• Navigating RevenueCat's new pricing for existing users - Offizielle Erklärung der aktualisierten MTR-basierten Preise.
• Announcing RevenueCat Paywalls v2 GA - Paywalls v2 Feature-Set und Experiments-Integration.
• Generate a paywall with AI (RevenueCat Changelog) - KI-Paywall-Generierung Update.
• The State of Subscription Apps 2026 - 2026 Benchmarks mit über 115.000 Apps.
• Why hybrid monetization is the default in 2026 - Hybride IAP + Web Rahmung.
• Adapty vs RevenueCat Comparison - Adaptys offizieller Vergleich zu A/B-Tests und KI-Prognosen.
• Adapty Paywall A/B Testing - Bayesian AB-Tests und KI-Gewinnerprognose.
• Qonversion Pricing - Starter und Growth MTR-Preisdetails.
• Qonversion: Handbook on App Store Receipt Validation - Edge-Cases bei der Receipt Validation.
• Apphud Pricing - Free- und Pro-Tier-Struktur mit MTR-Deckeln.
• Apphud Product Overview - Rules Engine und Infrastruktur-Positionierung.
• Chargebee Mobile Subscriptions Docs - Mobile Subscription-Flows und Legacy-SDK-Hinweise.
• Stripe: Accept in-app purchases on iOS and Android - Stripes offizielle Anleitung zu mobilen digitalen Gütern.
• Can You Use Stripe for In-App Purchases? (RevenueCat) - Post-Epic-Analyse zu Stripe für IAP.
• App-to-web external purchases (RevenueCat) - Praktischer Leitfaden für DMA-externe Käufe.
• New App Store Fees in 2026: EU DMA (FunnelFox) - 2026 EU DMA Gebührenstruktur-Übersicht.
• An overview of StoreKit 2 (RevenueCat) - StoreKit 2 Architektur und Transaction.updates-Modell.
• Server-side purchase validation on Google Play (Adapty) - Google Play Billing Validierungsleitfaden.