Xcode 27.2 RC: StoreKit-Angebotscodes testen? StoreKit-Tutorial 2026

Symptom: Der Einlösedialog erscheint, aber Sie wissen nicht, ob StoreKit die Transaktion und Ihre App die Berechtigung korrekt verarbeitet hat.
Schnellster Weg: Testen Sie die In-App-Einlösung mit einer StoreKit-Konfigurationsdatei und simulieren Sie die externe Einlösung im Transaction Manager. Prüfen Sie bei beiden Wegen Transaktionsupdate, Berechtigungsvergabe und Transaktionsabschluss. Das ersetzt keine Abnahme in der App-Store-Sandbox oder Produktion.

Dieser Ablauf ist für iOS-Entwickler gedacht, die Angebotscodes für In-App-Käufe oder Abonnements integrieren.
Er hilft Ihnen, die Einlösewege und die nachfolgende StoreKit-Verarbeitung getrennt zu prüfen.
Kleine Teams erhalten außerdem klare Grenzen dafür, welche Aussage ein lokaler Test tatsächlich belegt.

Zuletzt aktualisiert am 30.10.2026; Versions- und Uploadangaben anhand der Apple Developer-Veröffentlichung und der App-Store-Connect-Versionshinweise geprüft. Apple führt Xcode 27.2 RC als am 19.10.2026 veröffentlicht; die App-Store-Connect-Hinweise nennen die Möglichkeit, mit diesem RC-Build zu App Store und TestFlight hochzuladen. Das bestätigt weder einen identischen Status einer späteren Nicht-RC-Version noch eine echte Store-Transaktion. Apple Developer: Veröffentlichungsdatensatz zu Xcode 27.2 RC · App Store Connect: Versionshinweise

1. Testumfang: lokale Einlösung statt Store-Abnahme

Xcode StoreKit Testing eignet sich, um Einlöse- und Verarbeitungslogik in einer kontrollierten lokalen Umgebung zu prüfen. Sie können einen Angebotscode in der StoreKit-Konfigurationsdatei hinterlegen und den Einlöseablauf innerhalb der App testen. Für den externen Weg lässt sich der Transaction Manager verwenden. Apple beschreibt beide Pfade in den StoreKit-Hinweisen zu Tests während der Entwicklung.

Das Ergebnis beantwortet jedoch nur die Frage, ob Ihre App mit den lokal simulierten StoreKit-Ereignissen wie erwartet umgeht. Ein erfolgreicher lokaler Lauf bestätigt nicht automatisch, dass Produktdaten, Code-Eignung, Kontozuordnung oder serverseitige Abläufe in der App-Store-Sandbox und in der Produktion funktionieren. Behandeln Sie diese Umgebungen als getrennte Abnahmestufen.

Die Tabelle ist eine Entscheidungshilfe für die Teststufe, keine Rangliste. Wenn Ihr Fehler im App-eigenen Einlöseschritt liegt, beginnen Sie lokal in der App. Wenn der Einstieg außerhalb der App liegt, prüfen Sie zusätzlich den externen Ereignispfad. Für Freigaben, die eine echte Store-Umgebung betreffen, planen Sie eine separate Abnahme ein.

Achtung: Eine sichtbare Erfolgsanzeige im Systemdialog ist kein Nachweis dafür, dass Ihre App die Berechtigung freigeschaltet hat. Prüfen Sie immer auch die Verarbeitung nach dem Dialog.

2. Vorbereitung: Produkt und StoreKit-Konfiguration

Bevor Sie den Ablauf ausführen, trennen Sie lokale Testdaten von den Produktdaten in App Store Connect. Eine StoreKit-Konfigurationsdatei ist eine lokale Testgrundlage. Ihre dort hinterlegten Produktinformationen und Preise sind keine bestätigten Live-Preise und beweisen nicht, dass ein Angebotscode im echten Store für ein bestimmtes Konto eingelöst werden kann.

Öffnen Sie in Xcode die StoreKit-Konfiguration, die Ihr Testlauf verwenden soll. Prüfen Sie, ob das betreffende Produkt vorhanden ist und ob dafür ein Angebotscode eingerichtet wurde, der für den vorgesehenen Testfall zur Verfügung steht. Apple erklärt die Einrichtung in der Dokumentation zum StoreKit Testing in Xcode. Für die Unterstützung von Angebotscodes innerhalb der App beschreibt Apple außerdem die erforderlichen Schritte und den vorgesehenen Einlöseweg in der Dokumentation zu Angebotscodes in Apps.

Kontrollieren Sie vor dem Start insbesondere:

• Die App verwendet tatsächlich die gewünschte StoreKit-Konfigurationsdatei und nicht versehentlich eine andere Testkonfiguration.
• Das Produkt, der Code und die erwartete Berechtigung passen zu dem Szenario, das Sie ausführen wollen.
• Ihre App enthält einen erreichbaren Einstieg für die In-App-Einlösung, sofern Sie diesen Pfad testen.
• Die Transaktionsverarbeitung läuft bereits, wenn Sie die externe Einlösung simulieren möchten.
• Ihre Protokollierung erfasst genug Informationen für die Fehlersuche, aber keine unnötigen personenbezogenen Daten.

Beurteilen Sie die Konfiguration nicht danach, ob eine lokale Produktkachel „richtig bepreist“ aussieht. Für den Test der Berechtigungslogik zählt, ob das erwartete lokale Ereignis verarbeitet wird. Für die Validierung von realen Produkt- und Kontobedingungen brauchen Sie die dafür vorgesehene Store-Umgebung.

3. In-App-Einlösung: Dialog und Berechtigung getrennt prüfen

Starten Sie die App mit der ausgewählten StoreKit-Konfiguration und navigieren Sie zu dem Bereich, in dem Nutzer einen Angebotscode einlösen können. Öffnen Sie von dort den Systemdialog über den in Ihrer App implementierten StoreKit-Einstieg. Die Apple-Anleitung zur Unterstützung von Angebotscodes in Ihrer App beschreibt diesen App-internen Pfad.

Gehen Sie die Prüfung in dieser Reihenfolge durch:

1. Einlöseweg öffnen. Starten Sie den Vorgang aus Ihrer App heraus. Damit prüfen Sie nicht nur StoreKit, sondern auch, ob Ihr eigener Bildschirm und die Aktion den vorgesehenen Systemdialog aufrufen.
2. Konfigurierten Testfall auswählen. Verwenden Sie den in der lokalen Konfiguration vorbereiteten Angebotscode. Halten Sie fest, welcher Produkttyp und welche Berechtigung zu diesem Test gehören.
3. Einlösung bestätigen. Schließen Sie den Dialog regulär ab. Ein angezeigter Bestätigungszustand ist zunächst nur ein Hinweis auf den Abschluss des Dialogschritts.
4. StoreKit-Verarbeitung beobachten. Prüfen Sie, ob Ihre App das erwartete Transaktionsereignis erhält und dem richtigen Produkt beziehungsweise Konto zuordnet.
5. Berechtigung aktualisieren. Verifizieren Sie die konkrete Funktion, die für den Nutzer freigeschaltet werden soll. Ein Statuswechsel in der Oberfläche allein genügt nicht, wenn die zugrunde liegende Berechtigungslogik unverändert bleibt.
6. Transaktion abschließen. Beenden Sie eine verarbeitete Transaktion erst, nachdem Ihre App das Ereignis ausgewertet und die vorgesehene Zustandsänderung umgesetzt hat.

Halten Sie für jeden Durchlauf drei Ergebnisse getrennt fest: Dialog abgeschlossen, StoreKit-Ereignis verarbeitet und Berechtigung aktualisiert. Schlägt nur der letzte Punkt fehl, liegt der Fehler nicht zwangsläufig im Einlösedialog. Prüfen Sie dann Ihre Zuordnung zwischen Produkt, Konto und Berechtigung sowie den Code, der den App-Zustand verändert.

4. Externe Einlösung: Ereignisannahme ohne App-Einstieg

Bei einer externen Einlösung startet der Nutzer den Vorgang nicht über den Einlöseknopf Ihrer App. Deshalb testen Sie hier vor allem, ob Ihre Anwendung ein später eintreffendes StoreKit-Ereignis erkennt und verarbeitet. Apple beschreibt diesen Testweg in der Anleitung zum Testen von Käufen außerhalb der App.

Starten Sie zunächst die App mit der passenden Testkonfiguration und stellen Sie sicher, dass die Transaktionsbeobachtung aktiv ist. Verwenden Sie dann den Transaction Manager, um den vorgesehenen externen Einlösefall zu simulieren. Achten Sie darauf, dass die App während der Prüfung den Ereignispfad beobachten kann. Wird die App nicht ausgeführt oder ist die Verarbeitung nicht eingerichtet, lässt sich ein fehlendes Update schwer von einem fehlenden Listener unterscheiden.

Für StoreKit 2 ist Transaction.updates ein zentraler Mechanismus, über den Ihre App Transaktionsänderungen beobachten kann. Prüfen Sie den konkreten Ablauf anhand der Apple-Dokumentation zu Transaction.updates. Ihre Implementierung sollte das Ereignis nicht lediglich protokollieren: Sie muss das betroffene Produkt und den Nutzungszustand korrekt auswerten, die passende Berechtigung aktualisieren und die verarbeitete Transaktion abschließen.

Unterscheiden Sie dabei klar zwischen zwei Pfaden:

• In-App-Einlösung: Ihre App öffnet den Einlösedialog. Hier prüfen Sie den Einstieg, die Rückkehr in die App und die anschließende Verarbeitung.
• Externe Einlösung: Der Testmanager simuliert ein Ereignis außerhalb dieses Einstiegs. Hier prüfen Sie, ob Ihre App das Update auch ohne vorausgehenden Tap auf den eigenen Einlöseknopf übernimmt.

Ein bestandener externer Test zeigt, dass die lokale Ereignisverarbeitung für diesen Testfall funktioniert. Er beweist nicht, dass ein echter Nutzer im Store dieselben Voraussetzungen erfüllt oder dass ein Backend die Transaktion in der Produktionsumgebung korrekt verarbeitet.

Häufige Fragen im Testlauf

Was tun, wenn der Einlösedialog erfolgreich war, die Funktion aber gesperrt bleibt?

Verfolgen Sie den Ablauf ab dem Ereignis, nicht nur ab der Oberfläche. Prüfen Sie, ob Ihre App das erwartete StoreKit-Update erhält, ob es dem richtigen Produkt zugeordnet wird und ob die Berechtigungslogik danach tatsächlich ausgeführt wird. Kontrollieren Sie außerdem, ob die UI den aktualisierten Zustand neu lädt. So unterscheiden Sie einen Fehler in der Ereignisverarbeitung von einem Fehler bei der Darstellung.

Kann ein lokaler Angebotscode-Test die Sandbox-Abnahme ersetzen?

Nein. Die lokale StoreKit-Konfiguration dient dazu, definierte Abläufe während der Entwicklung zu testen. Sie ist kein Beleg für eine echte Transaktion, die Verfügbarkeit eines Codes in der App-Store-Sandbox oder das Verhalten eines Produktionskontos. Verwenden Sie lokale Tests für die App-Logik und planen Sie die Sandbox-Abnahme separat, wenn Sie Store- oder Kontobedingungen verifizieren müssen.

Warum kommen externe Updates nicht an, obwohl die App eine Einlösefunktion hat?

Der In-App-Einstieg und der Empfang eines externen Updates sind verschiedene Prüfungen. Eine funktionierende Einlöseaktion beweist nicht, dass Ihre App Transaktionsupdates unabhängig davon beobachtet. Kontrollieren Sie, ob die Beobachtung früh genug startet, während des simulierten Ereignisses aktiv bleibt und die eingehenden Transaktionen verarbeitet. Prüfen Sie anschließend Berechtigungsvergabe und Transaktionsabschluss.

Lässt sich die wiederholte Einlösung für jedes Produkt gleich zurücksetzen?

Nein. Vorhandene Transaktionen oder eine bereits gewährte Berechtigung können einen erneuten Durchlauf beeinflussen; das ist nicht als einheitliche Regel für alle Produkttypen zu behandeln. Kontrollieren Sie im Transaction Manager den für Ihren Testfall relevanten Zustand. Entfernen oder ändern Sie nur die anwendbaren Testtransaktionen und prüfen Sie danach, ob die App wirklich wieder im erwarteten Ausgangszustand startet.

5. Wiederholung: Transaktionszustand statt blindem Neustart

Wenn ein zweiter Durchlauf nicht dasselbe Ergebnis liefert wie der erste, setzen Sie nicht einfach voraus, dass der Test „festhängt“. Prüfen Sie zunächst, ob die vorherige Transaktion noch vorhanden ist oder die App bereits eine Berechtigung für das Produkt führt. Je nach Produkttyp und Testzustand kann eine bestehende Berechtigung beeinflussen, welche erneute Einlösung sinnvoll oder möglich ist.

Öffnen Sie den Transaction Manager und vergleichen Sie den aktuellen Zustand mit dem, den Ihr Testfall voraussetzt. Bereinigen Sie nur die Einträge, die für den konkreten erneuten Durchlauf vorgesehen sind. Starten Sie danach die App erneut und kontrollieren Sie, dass sie mit der beabsichtigten Konfiguration läuft. Die Dokumentation zum StoreKit Testing in Xcode ist die geeignete Referenz für die lokale Testumgebung; leiten Sie daraus keine allgemeine Regel ab, dass jede Produktart identisch zurückgesetzt werden kann.

Führen Sie den Wiederholungstest mit einem klaren Sollzustand durch: erwartetes Produkt, erwartete Berechtigung, erwartetes Ereignis und erwarteter Abschluss. Wenn Sie nur den Dialog erneut öffnen, ohne diese Zustände zu kontrollieren, können Sie nicht sauber feststellen, ob Sie denselben Fall wiederholen oder einen anderen Zustand testen.

Hinweis: Löschen Sie Testzustände nicht pauschal, bevor Sie den Fehler dokumentiert haben. Sonst geht möglicherweise genau der Zustand verloren, der erklärt, warum der zweite Durchlauf abweicht.

6. Freigabeentscheidung: lokale Evidenz und Remote-Mac-Betrieb

Erstellen Sie vor der Freigabe einen nachvollziehbaren Datensatz für den Test: verwendete Xcode-Version, ausgewählte StoreKit-Konfigurationsdatei, Einlöseweg, eingegangenes Ereignis, Berechtigungszustand und Transaktionsabschluss. Für Xcode 27.2 RC nennen die Apple Developer Release Notes den Veröffentlichungstag 19.10.2026. Die App-Store-Connect-Versionshinweise führen den RC-Build als für App Store und TestFlight nutzbar auf. Das sind Versions- und Uploadinformationen, keine Bestätigung, dass lokale StoreKit-Tests eine Sandbox- oder Produktionsprüfung ersetzen.

Nutzen Sie für die Freigabe drei getrennte Aussagen:

• Umgebung erreichbar: Sie können den Mac und das Projekt bedienen. Das sagt noch nichts darüber aus, ob StoreKit Testing korrekt gestartet wurde.
• Lokaler Test bestanden: Der konfigurierte In-App- oder externe Testlauf erzeugt das erwartete Ereignis, die Berechtigung wird aktualisiert und die Transaktion wird verarbeitet.
• Store-Abnahme bestanden: Die relevanten Abläufe wurden zusätzlich in der vorgesehenen App-Store-Umgebung geprüft. Das ist eine eigene Aussage und darf nicht aus einem lokalen Ergebnis abgeleitet werden.

Wenn Sie regelmäßig Builds erstellen und denselben StoreKit-Test auf einem entfernten Mac wiederholen wollen, beurteilen Sie zunächst, ob Ihre Arbeitsweise eine dauerhaft verfügbare macOS-Umgebung benötigt. Ein lokaler Mac ist für langfristige, konstante Auslastung oder Arbeiten mit benötigten physischen Anschlüssen oft die passendere Lösung. Eine entfernte Mac-Umgebung kann dagegen für zeitlich begrenzte Tests oder wiederkehrende Xcode-Läufe sinnvoll sein, wenn Sie keine eigene Maschine dafür bereitstellen möchten. Prüfen Sie die Unterschiede zwischen Bare Metal und macOS-Virtualisierung und die Angaben zu Mac-Mietkosten, bevor Sie sich festlegen.

Ein Remote Mac ersetzt weder Ihre StoreKit-Teststrategie noch die Sandbox-Abnahme. Er stellt lediglich eine macOS-Umgebung bereit, in der Sie den beschriebenen Ablauf wiederholen können. Wenn Ihr lokaler Rechner durch parallele Builds oder knappen Speicher zum Engpass wird, vergleichen Sie die laufenden Kosten und den Verwaltungsaufwand mit einer eigenen Maschine. Für einen vorübergehenden Test- oder Build-Bedarf können Sie sich die Mac-Umgebungen von MacDate ansehen; bei dauerhaftem Schwerlastbetrieb oder notwendiger lokaler Hardware ist ein eigener Mac möglicherweise die bessere Entscheidung.