RevenueCat-iOS-Abos lokal testen? Remote-Mac-Ablauf 2026

Drei Testumgebungen decken unterschiedliche Prüfziele ab: RevenueCat Test Store prüft Ihre App-Logik, die StoreKit-Konfiguration lokale Apple-Transaktionen und Apple Sandbox den Plattformkauf. Die Dokumentation von RevenueCat zum Test Store und Apples Übersicht zu Xcode- und Sandbox-Tests beschreibt diese getrennten Einsatzbereiche.

Symptom: Der Kaufdialog funktioniert, aber Sie wissen nicht, ob damit auch die Apple-Transaktion korrekt geprüft ist.

Schnellster Weg: Testen Sie zuerst Kaufzustände und Entitlements im RevenueCat Test Store, danach lokale Transaktionen mit einer Xcode StoreKit-Konfiguration und schließlich den Plattformablauf in Apple Sandbox. Ein bestandener Test ersetzt keinen Test in den anderen Umgebungen.

Für Sie ist dieser Ablauf gedacht, wenn Sie RevenueCat neu in eine iOS-App integrieren und Kauf sowie Freischaltung überprüfen möchten.
Wenn Sie lokale StoreKit-Tests einrichten oder auf einem Remote Mac mit Xcode arbeiten, finden Sie weiter unten die jeweiligen Grenzen und Prüfschritte.
Suchen Sie nur eine Einführung in StoreKit-Produktmodelle, können Sie die folgenden Abnahmeabschnitte überspringen.

Vor dem ersten Kauf: Testziel und Umgebung festlegen

Behandeln Sie Test Store, StoreKit-Konfiguration und Apple Sandbox als unterschiedliche Prüfstrecken. Entscheiden Sie vor dem Einrichten, welche Aussage Sie nach einem Test belegen müssen: Reagiert Ihre App richtig auf einen Kauf? Funktioniert eine lokale StoreKit-Transaktion? Oder ist der plattformseitige Kaufablauf geprüft?

Die Bewertungen in der Tabelle sind eine redaktionelle Einschätzung der jeweiligen Testziele, keine Messwerte. Die Umgebungen sind nicht austauschbar: Ein Test Store-Kauf zeigt Ihnen, ob Ihre App auf einen simulierten Kaufzustand reagiert. Eine lokale StoreKit-Konfiguration prüft einen anderen Transaktionsweg. Apple Sandbox dient dazu, Plattformverhalten in einem dafür vorgesehenen Testablauf zu überprüfen.

Kann RevenueCat ohne ein in App Store Connect angelegtes Produkt getestet werden? Für die erste Prüfung der App-Logik können Sie den RevenueCat Test Store nutzen; dessen Testprodukte sind nicht dasselbe wie in App Store Connect angelegte Apple-Produkte. Sobald Sie eine lokale StoreKit-Konfiguration oder Apple Sandbox prüfen, müssen Sie dagegen die Anforderungen des jeweiligen Weges beachten. Prüfen Sie deshalb vor dem Test, welche Produktkennungen Ihre RevenueCat-Konfiguration erwartet und ob die gewählte StoreKit- oder Sandbox-Umgebung dazu passt.

Vor dem Testlauf: Produktzuordnung und Schlüssel kontrollieren

Legen Sie in RevenueCat Produkte und Entitlements so an, dass sich ein konkreter Kauf eindeutig einer erwarteten Freischaltung zuordnen lässt. Ein Produkt ist dabei nicht automatisch dasselbe wie ein Entitlement: Das Produkt bezeichnet den Kauf, das Entitlement die Berechtigung, die Ihre App nach dem Kauf gewährt. RevenueCat beschreibt die Zuordnung in seiner Anleitung zu iOS-Produkten und Entitlements.

Prüfen Sie vor dem ersten Kauf diese Punkte:

1. Produktkennung: Stimmen Produktkennung in App-Code, RevenueCat-Projekt und der ausgewählten StoreKit-Umgebung überein? Achten Sie auf abweichende Schreibweisen, zusätzliche Leerzeichen oder eine Kennung aus einem anderen Testlauf.
2. Entitlement-Zuordnung: Ist das Testprodukt dem Entitlement zugeordnet, das Ihre App tatsächlich abfragt? Ein Kauf kann technisch erfolgreich aussehen und trotzdem keinen Zugriff freischalten, wenn Ihre App ein anderes Entitlement prüft.
3. App-User-ID: Verwendet die App während des Tests die erwartete RevenueCat-Benutzerkennung? Wenn Sie wechselnde Testkonten verwenden, notieren Sie die Kennung pro Lauf, statt Ergebnisse verschiedener Konten zu vermischen.
4. Schlüsseltyp: Verwenden Sie im iOS-Client den vorgesehenen öffentlichen SDK-Schlüssel für die passende App beziehungsweise Plattform. Ein geheimer API-Schlüssel gehört nicht in den App-Code, ein öffentliches SDK-Kennzeichen nicht als Ersatz für einen serverseitigen Schlüssel.
5. Build und Scheme: Markieren Sie Test-Build und Release-Build eindeutig. Prüfen Sie beim Start, welches Scheme, welcher Schlüssel und welche Produktkonfiguration aktiv sind.
6. Ergebnisnachweis: Halten Sie Kaufzustand, CustomerInfo und den Status des erwarteten Entitlements fest. Protokolle dürfen keine geheimen Schlüssel oder unnötigen personenbezogenen Daten enthalten.

Die offizielle Anleitung zum Konfigurieren des RevenueCat-SDK ist die passende Prüfstelle für die SDK-Einrichtung. Verlassen Sie sich nicht auf den Namen einer Build-Konfiguration: Ein „Debug“-Scheme kann versehentlich mit einem Produktionsschlüssel laufen, und ein korrekt benannter Test-Build kann dennoch die falsche Produktkennung laden.

Hinweis zur Geheimhaltung: Speichern Sie geheime API-Schlüssel nicht in Quellcode, Screenshots, Terminalprotokollen oder gemeinsam zugänglichen Build-Artefakten. Auf einem Remote Mac sollte der Zugriff auf Testkonten und Schlüssel genauso gezielt begrenzt werden wie in Ihrer lokalen Entwicklungsumgebung.

Erster Kauf: App-Logik im RevenueCat Test Store prüfen

Beginnen Sie mit dem Test Store, wenn Sie zunächst die Reaktion Ihrer App auf einen Kauf überprüfen möchten. Der Vorteil dieses Schritts ist seine Abgrenzung: Sie können die Anbindung und den Zustandswechsel untersuchen, bevor Sie Fehler in Apple-Produkten, Plattformkonten oder lokalem StoreKit der App-Logik zuschreiben. Laut RevenueCat dient der Test Store zum Prüfen der Integration und simuliert dabei keinen echten Kauf über den Apple Store.

Gehen Sie in dieser Reihenfolge vor:

1. Wählen Sie in der Testkonfiguration ausdrücklich den RevenueCat Test Store und die dafür vorgesehene Testkonfiguration.
2. Laden Sie in der App die Produktdarstellung und prüfen Sie, ob das erwartete Testprodukt erscheint.
3. Lösen Sie einen erfolgreichen Testkauf aus und prüfen Sie, ob CustomerInfo aktualisiert wird.
4. Kontrollieren Sie, ob genau das erwartete Entitlement aktiv wird und die App die zugehörige Funktion freischaltet.
5. Wiederholen Sie den Ablauf mit einer abgebrochenen oder fehlgeschlagenen Kaufaktion, sofern dieser Zustand in Ihrer gewählten Testumgebung zur Verfügung steht. Die App sollte dabei keinen Zugriff freischalten, den sie nur einem bestätigten Kauf gewährt.
6. Protokollieren Sie Benutzerkennung, Produktkennung, Environment und Ergebnis, ohne geheime Schlüssel oder unnötige Kundendaten zu speichern.

Woran erkennen Sie, dass der Test Store für diesen Schritt genügt? Wenn Sie nur prüfen, ob Ihre App nach einem Kauf CustomerInfo verarbeitet, das richtige Entitlement aktiviert und Abbruch oder Fehler angemessen behandelt, ist er ein geeigneter erster Prüfpunkt. Er belegt jedoch nicht, dass Apple Sandbox dieselben Plattformvorgänge ausführt oder dass Apple-Produktinformationen korrekt hinterlegt sind. Vermerken Sie das Ergebnis daher ausdrücklich als App-Logiktest und nicht als Plattformabnahme.

Achten Sie beim Umstellen der Testumgebung auf die Schlüssel- und Produktkonfiguration. Mischen Sie nicht unbemerkt Test-Store-Produkte und Apple-Produkte in demselben Lauf. Wenn sich nach dem Wechsel der Umgebung Produktliste oder Entitlement-Verhalten verändert, prüfen Sie zuerst die aktive Konfiguration und die Zuordnung, bevor Sie Änderungen am Kaufcode vornehmen.

Lokale Wiederholung: Xcode StoreKit-Konfiguration einsetzen

Für reproduzierbare lokale StoreKit-Käufe legen Sie eine StoreKit-Konfigurationsdatei an und verknüpfen sie mit dem dafür vorgesehenen Xcode-Scheme. Die Datei ist ein lokales Testmittel: Sie erzeugt nicht automatisch ein Produkt in App Store Connect. Apple beschreibt die Einrichtung in seiner Xcode-Anleitung für StoreKit Testing.

Arbeiten Sie die Konfiguration in getrennten Schritten ab:

1. Erstellen oder wählen Sie eine StoreKit-Konfigurationsdatei für den Testlauf.
2. Tragen Sie Testprodukte mit Kennungen ein, die mit der Produktzuordnung in RevenueCat übereinstimmen.
3. Öffnen Sie die Einstellungen des dedizierten Schemes und wählen Sie die StoreKit-Konfigurationsdatei für den passenden Lauf aus.
4. Starten Sie die App über genau dieses Scheme und prüfen Sie, ob die lokal bereitgestellten Produkte geladen werden.
5. Führen Sie Kauf, Abbruch und Wiederherstellung beziehungsweise erneutes Laden des Status aus, sofern Ihr Testfall diese Aktionen umfasst.
6. Kontrollieren Sie CustomerInfo und Entitlement nach jedem Zustandswechsel erneut.

Wie verwenden Sie eine StoreKit-Konfigurationsdatei für RevenueCat-Abonnementtests? Entscheidend ist, dass Xcode die Datei für den aktiven Testlauf verwendet und die Produktkennungen zur RevenueCat-Konfiguration passen. Prüfen Sie außerdem die von RevenueCat für Ihre Integration beschriebene SDK-Testart und die Einstellungen für Zertifikate, soweit diese für Ihren konkreten Testweg relevant sind. Die unterstützten Verfahren können von der verwendeten Integration abhängen; übernehmen Sie daher keine Schalter oder Codebeispiele aus einem anderen Projekt, ohne sie mit der aktuellen RevenueCat-Dokumentation zu Apple- und lokalen StoreKit-Tests abzugleichen.

Ein lokaler Kauf ist kein Beleg für korrekte Plattformmetadaten. Produktname und Preis sollten Sie getrennt gegen die für die Veröffentlichung vorgesehene Konfiguration prüfen. Ebenso reicht ein erfolgreich abgeschlossener Simulatorlauf nicht aus, um Aussagen über Rückerstattungen, Kündigungen oder spätere Plattformereignisse zu treffen, die in diesem Lauf gar nicht durchgespielt wurden.

Plattformabnahme: Apple Sandbox vor dem Release verwenden

Wechseln Sie zu Apple Sandbox, wenn Sie den plattformseitigen Testkauf vor dem Release überprüfen müssen. Apple dokumentiert Sandbox-Käufe als eigenen Testweg; die Ergebnisse sind nicht mit einem lokalen StoreKit-Kauf gleichzusetzen. Verwenden Sie für diesen Lauf die vorgesehenen Testprodukte und Testkonten und halten Sie fest, dass Sie sich tatsächlich in der Sandbox befinden.

Trennen Sie zwei Abnahmefragen:

• Transaktionsweg: Kann die App den vorgesehenen Plattformkauf auslösen, das Ergebnis verarbeiten und das erwartete Entitlement freischalten?
• Produktdarstellung: Stimmen Produktname, Preis und weitere für den Kauf relevanten Angaben mit der vorgesehenen Store-Konfiguration überein?

Ein erfolgreiches Kaufresultat beantwortet nicht automatisch beide Fragen. Prüfen Sie die Produktdarstellung gesondert und vergleichen Sie die verwendeten Produktkennungen mit der RevenueCat-Zuordnung. Apple beschreibt die verfügbaren Sandbox-Testmöglichkeiten und ihre Bedingungen in der Übersicht zum Testen von In-App-Käufen in Sandbox.

Wählen Sie Simulator oder physisches Gerät nach dem Abnahmeziel und der Unterstützung Ihres konkreten Testwegs. Leiten Sie aus einem erfolgreichen Simulatorlauf nicht ab, dass ein physisches Gerät denselben Ablauf bereits bestanden hat. Umgekehrt sollten Sie einen fehlgeschlagenen Lauf nicht vorschnell dem Gerät zuschreiben: Prüfen Sie erst Konto, Produktkennung, Environment, Netzwerkzugriff und aktive App-Konfiguration.

Was muss nach dem Wechsel in Apple Sandbox erneut geprüft werden? Kontrollieren Sie den aktiven Build, den Plattform-Schlüssel, das Testkonto, die Produktkennung und die Zuordnung zum erwarteten Entitlement. Wiederholen Sie den Kauf über den vorgesehenen Sandbox-Ablauf und dokumentieren Sie das Ergebnis separat von Test Store und lokalem StoreKit. Ein anderer Schlüssel, ein anderes Produkt oder ein anderes Testkonto macht frühere Ergebnisse nicht automatisch übertragbar.

Remote Mac: Lauf reproduzieren und sauber abnehmen

Ein Remote Mac kann Xcode-Builds und Simulatorläufe übernehmen, wenn Sie für den Test eine macOS-Umgebung benötigen. Er ändert jedoch nicht die Abnahmegrenzen von RevenueCat Test Store, lokaler StoreKit-Konfiguration oder Apple Sandbox. Entscheidend ist, dass Sie auf dem entfernten Rechner denselben Quellstand und eine klar erkennbare Testkonfiguration verwenden.

Nutzen Sie für die Wiederholung diesen Ablauf:

1. Checken Sie den geprüften Commit aus und notieren Sie, welcher Stand getestet wird.
2. Installieren beziehungsweise wählen Sie die benötigte Xcode-Umgebung und öffnen Sie das dedizierte Test-Scheme.
3. Prüfen Sie vor dem Build erneut den aktiven Schlüsseltyp, die RevenueCat-Projektzuordnung und die Produktkennungen.
4. Bauen Sie die App und starten Sie den Simulator mit der für den jeweiligen Test vorgesehenen Konfiguration.
5. Wiederholen Sie den Test Store- oder StoreKit-Lauf; wechseln Sie für die Plattformabnahme ausdrücklich zur Apple Sandbox.
6. Erfassen Sie Testumgebung, Scheme, Commit, Testkonto-Kennung und Resultat in einem Laufprotokoll.
7. Entfernen oder sperren Sie Testzugänge nach dem Lauf, wenn sie nicht mehr benötigt werden, und prüfen Sie, dass Release-Builds nicht versehentlich mit Testschlüsseln konfiguriert sind.

Bei einem entfernten Rechner kommen zusätzliche Betriebsfragen hinzu: Wer kann die Sitzung öffnen? Wo liegen Schlüssel und Testkontodaten? Werden Screenshots, Konsolenausgaben oder Build-Artefakte gemeinsam abgelegt? Begrenzen Sie Zugriffe, verwenden Sie getrennte Konfigurationen und prüfen Sie Ihre Datenschutzvorgaben, bevor Sie personenbezogene Testdaten auf einem gemeinsam verwalteten System speichern. Für die Entscheidung zwischen dedizierter Hardware und Virtualisierung hilft der Überblick zu Bare-Metal- und virtualisierten macOS-Umgebungen; die Übersicht zu macOS-Mietkosten unterstützt Sie bei der Budgetplanung.

Kann ein iOS-Simulator auf einem Remote Mac RevenueCat-Käufe prüfen? Ja, sofern die von Ihnen gewählte Testmethode und Xcode-Umgebung den vorgesehenen Simulatorlauf unterstützen. Damit können Sie App-Logik und lokale StoreKit-Abläufe reproduzieren. Ein solcher Lauf ersetzt nicht die separate Prüfung in Apple Sandbox, wenn Sie den Plattformkauf abnehmen möchten. Halten Sie also im Ergebnisprotokoll fest, ob ein Test Store-, lokaler StoreKit- oder Sandbox-Lauf stattgefunden hat.

Ohne reproduzierbare Konfiguration führt ein Remote Mac eher zu zusätzlicher Fehlersuche als zu einer verlässlichen Abnahme. Wenn Sie die Xcode-Tests vom eigenen Arbeitsrechner trennen möchten, prüfen Sie vorab, ob die gemietete Umgebung für Ihre benötigten Simulator- und Plattformtests geeignet ist. MacDate bietet dafür eine Mac-Mietoption; vergleichen Sie die Laufzeit und den benötigten Zugriff mit den verfügbaren Mac-Konfigurationen. Für seltene Tests kann ein eigener Mac bereits ausreichen. Wenn Sie dagegen eine separate, erreichbare Xcode-Umgebung für wiederholte Builds brauchen, kann die Miete praktischer sein als ein zusätzlicher Rechner, der dauerhaft eingerichtet und aktualisiert werden muss.

Abschluss: Ergebnis nach Umgebung statt nach Bauchgefühl bewerten

Schließen Sie den Test nicht mit der Aussage „Kauf funktioniert“ ab. Halten Sie fest, welche Ebene geprüft wurde: RevenueCat Test Store für die App-Logik, Xcode StoreKit-Konfiguration für lokale Transaktionen oder Apple Sandbox für den Plattformablauf. Prüfen Sie Schlüssel, Produktkennungen, CustomerInfo und Entitlements nach jedem Umgebungswechsel erneut. So wissen Sie, welche Freigabe tatsächlich belegt ist und was vor dem Release noch offen bleibt.

Wenn Ihnen lokal kein Mac zur Verfügung steht oder Sie Xcode- und Simulatorläufe von Ihrer Entwicklungsmaschine trennen möchten, kann ein Remote Mac von MacDate den Testbetrieb ergänzen. Bewerten Sie vor der Miete, ob Sie nur gelegentlich bauen oder eine wiederholt nutzbare Umgebung für den gesamten Prüfablauf benötigen; für langfristige, kontinuierlich hohe Auslastung oder spezielle physische Schnittstellen kann ein eigener Mac die passendere Wahl sein.