App Store Connect: In-App-Käufe einreichen? Neuer Add for Review-Ablauf 2026

App Store Connect In-App-Käufe einreichen: Das erste Produkt eines jeweiligen In-App-Kauf-Typs muss weiterhin zusammen mit einer neuen App-Version zur Prüfung eingereicht werden. Erst wenn für diesen Typ bereits ein Produkt genehmigt wurde und eine genehmigte App-Version vorhanden ist, kann ein später hinzugefügtes Produkt unter den vorgesehenen Bedingungen separat geprüft werden. Dafür wird 2026 der Eintrag Add for Review aus dem Bereich des jeweiligen In-App-Kaufs oder Abonnements verwendet.

Diese Anleitung richtet sich an drei Gruppen: an unabhängige Entwickler, die erstmals Verbrauchs-, Nicht-Verbrauchsartikel oder Abonnements einrichten; an Teams, die weitere Produkte oder Tarifstufen ergänzen; und an kleine Teams, die Builds auf einem Remote Mac erzeugen und den Prüfprozess wiederholbar organisieren möchten.

Stand der Anleitung: 29.08.2026. Die Angaben wurden anhand der offiziellen Anleitung zur Einreichung eines In-App-Kaufs, der App-Store-Connect-Versionshinweise und der Apple-Anforderungen für Einreichungen geprüft.

1. Zuerst die Einreichungsberechtigung des Produkts feststellen

Der häufigste Fehler entsteht nicht beim Klick auf „Submit for Review“, sondern bereits bei der falschen Annahme, dass ein erfolgreich getesteter Kauf automatisch separat eingereicht werden darf. Vor dem Anlegen eines Entwurfs sollte deshalb jedes Produkt anhand von drei Bedingungen bewertet werden:

1. Welcher In-App-Kauf-Typ liegt vor?
2. Gibt es für genau diesen Typ bereits ein genehmigtes Produkt?
3. Existiert für die App bereits eine genehmigte Version?

Dabei reicht es nicht aus, dass irgendein anderer Kauf oder ein Abonnement genehmigt wurde. Die Regel bezieht sich auf den jeweiligen Typ. Ein genehmigter Verbrauchsartikel ersetzt daher nicht automatisch das erforderliche Erstprodukt eines Nicht-Verbrauchsartikels oder einer automatischen Verlängerung.

Die Apple-Hilfe zu Erst- und Folgeprodukten bestätigt den entscheidenden Unterschied: Das erste Produkt eines Typs wird an eine neue App-Version gebunden; spätere Produkte können, sofern die Voraussetzungen erfüllt sind, ohne neue Binärdatei eingereicht werden.

Muss der erste In-App-Kauf mit einer neuen App-Version eingereicht werden?
Ja, wenn es sich um das erste Produkt dieses Typs handelt. Das gilt auch dann, wenn das Produkt im Sandbox-Test bereits erfolgreich gekauft und wiederhergestellt werden kann. Der Test beweist die technische Funktion, nicht die Erfüllung der Anforderungen für die App-Review-Metadaten und die erste Einreichung.

Die Produktarten nicht vermischen

Bei Verbrauchsartikeln wird der Kauf typischerweise nach Verbrauch erneut erworben. Nicht-Verbrauchsartikel bleiben dem Account dauerhaft zugeordnet. Automatisch verlängerbare Abonnements gehören zu einer Subscription Group und benötigen eine nachvollziehbare Gruppenstruktur. Nicht verlängerbare Abonnements haben wiederum eine andere Verkaufserwartung.

Für die Entscheidung genügt deshalb nicht die Frage, ob „schon ein Kauf“ existiert. Das Team sollte in einer internen Produktliste den exakten Typ, die Product ID, die zugehörige Subscription Group und den Status des bisherigen Produkts festhalten. Product ID, Bundle ID, Team ID, Accountdaten, Screenshots und Protokolle gehören in geteilten Dokumenten ausschließlich in redigierter Form.

2. Vor dem Entwurf alle Review-Daten vervollständigen

Ist das Produkt für eine Einreichung qualifiziert, folgt die Materialprüfung. Ein Produkt kann im App-Code erreichbar sein und trotzdem wegen fehlender oder widersprüchlicher Angaben nicht bereit für die Prüfung sein.

Zu kontrollieren sind insbesondere:

• Produktstatus und Verfügbarkeit;
• Anzeigename und Beschreibung für jede erforderliche Lokalisierung;
• Preisstufe und Verkaufsländer beziehungsweise Verkaufsregionen;
• Review-Screenshot, sofern für die Prüfung erforderlich;
• Review Notes mit einer verständlichen Beschreibung des Kaufwegs;
• Testzugang oder Hinweise, falls die gekaufte Funktion nicht sofort sichtbar ist;
• bei Abonnements die korrekte Zuordnung zur Subscription Group;
• mindestens ein tatsächlich zugeordnetes Abonnement in der Gruppe.

Apple beschreibt die Bearbeitung dieser Angaben in der Dokumentation zu In-App-Kauf-Informationen. Diese Angaben sollten vor dem Zusammenstellen des Entwurfs geprüft werden, weil eine spätere Änderung an einer Produktbeschreibung oder einem Screenshot eine andere Fehlerursache hat als ein nicht verarbeitetes Build.

Warum lässt sich ein neues Abonnement trotz erfolgreichem Kauf nicht separat senden?
In der Regel fehlt mindestens eine Einreichungsvoraussetzung: Es ist das erste Abonnement dieses Typs, die App besitzt noch keine genehmigte Version, die Subscription Group ist nicht korrekt verbunden oder die Review-Informationen sind unvollständig. Ein Sandbox-Erfolg stellt nur die Testumgebung und den technischen Kaufpfad unter Beweis.

Sandbox, TestFlight und Review getrennt bewerten

Die folgenden Zustände dürfen nicht miteinander gleichgesetzt werden:

• Produkt konfiguriert: Die Daten wurden in App Store Connect gespeichert.
• Sandbox-Test erfolgreich: Der Kauf wurde in der Testumgebung ausgeführt.
• Build hochgeladen: Eine Binärdatei wurde an App Store Connect übertragen.
• Build verarbeitet: Apple hat die Upload-Verarbeitung abgeschlossen.
• Zur Prüfung eingereicht: Der relevante Entwurf wurde an App Review gesendet.
• Genehmigt und verfügbar: Die Prüfung ist abgeschlossen und die Freigabe ist für den Verkauf wirksam.

Diese Trennung verhindert, dass ein Team aus einem grünen Test- oder Build-Status vorschnell auf eine genehmigte Verkaufskonfiguration schließt. Eine Übersicht der Statuswerte für App-Uploads hilft bei der Unterscheidung zwischen Übertragung, Verarbeitung und tatsächlicher Einreichung.

3. Den Add-for-Review-Entwurf richtig zusammenstellen

Der neue Ablauf beginnt im Bereich In-App Purchases oder Subscriptions, nicht zwingend auf der Seite der App-Version. Dort wird das betreffende Produkt für die Prüfung ausgewählt und mit Add for Review zu einem bestehenden Entwurf hinzugefügt oder in einem neuen Einreichungsentwurf gesammelt.

Wo befindet sich Add for Review in App Store Connect?
Der Eintrag befindet sich in der jeweiligen Verwaltungsansicht für In-App-Käufe beziehungsweise Abonnements, wenn das Produkt für eine Einreichung bereit ist. Je nach Produktstatus und bestehender App-Version wird es einem vorhandenen Entwurf hinzugefügt oder App Store Connect führt durch die Erstellung einer neuen Einreichung. Entscheidend ist nicht die sichtbare Position des Buttons, sondern dass das Produkt anschließend im richtigen Review-Entwurf erscheint.

Bei einem ersten Abonnement müssen App-Version, Subscription Group und das erste Abonnement gemeinsam vorbereitet werden. Bei einem qualifizierten Folgeprodukt kann der Entwurf dagegen auf das Produkt beschränkt bleiben. Die Berechtigung zur separaten Einreichung sollte vor dem Hinzufügen geprüft werden, statt erst nach einem fehlgeschlagenen Submit darauf zu reagieren.

Wie gelangen In-App-Kauf und App-Version in dieselbe Prüfung?
Zunächst wird die App-Version mit dem für die Prüfung vorgesehenen Build vorbereitet. Danach wird im Bereich des In-App-Kaufs oder der Subscription Group Add for Review verwendet. Im anschließenden Entwurf müssen beide Objekte sichtbar sein: die App-Version einschließlich Build und das Produkt beziehungsweise die Gruppe mit den Review-Daten. Fehlt eines der Objekte, sollte nicht eingereicht werden.

Einreichungsentwurf vor dem Absenden prüfen

• [ ] Der Produkttyp wurde mit dem internen Produktregister abgeglichen.
• [ ] Es wurde festgestellt, ob es das erste Produkt dieses Typs ist.
• [ ] Eine bestehende genehmigte App-Version wurde verifiziert.
• [ ] Lokalisierung, Preis und Verkaufsgebiete sind vollständig.
• [ ] Review-Screenshot und Review Notes zeigen den tatsächlichen Kaufweg.
• [ ] Bei einem Abonnement ist die Subscription Group korrekt zugeordnet.
• [ ] Die App-Version enthält den richtigen Build.
• [ ] Die gekaufte Funktion ist innerhalb der App erreichbar.
• [ ] Der Entwurf enthält alle für diesen Fall erforderlichen Objekte.
• [ ] Product ID, Bundle ID und Team-ID stimmen mit dem Release überein.
• [ ] Keine Zugangsdaten, Screenshots oder Logs enthalten unredigierte personenbezogene Daten.

Die Übersicht zum Einreichen für App Review ist für die letzte Kontrolle wichtiger als eine bloße Sichtprüfung der Produktseite. Der Entwurf muss in sich vollständig sein; ein einzelner gespeicherter Datensatz außerhalb des Entwurfs gilt nicht als eingereicht.

4. Einen neuen Build nur dann zuordnen, wenn er tatsächlich erforderlich ist

Wenn das erste Produkt eines Typs eingereicht wird, ist eine neue App-Version erforderlich. Der Build sollte daher zuerst auf dem vorgesehenen Mac erstellt, signiert und hochgeladen werden. Anschließend wird in der App-Version genau dieser Build ausgewählt. Bei einem qualifizierten Folgeprodukt ohne Änderung am Binärprogramm ist ein neuer Build dagegen nicht automatisch notwendig.

Muss nach einer Ablehnung des In-App-Kaufs ein neuer Build hochgeladen werden?
Nein, nicht automatisch. Wenn Apple ausschließlich Produktdaten, Review Notes, Screenshots oder andere Angaben des In-App-Kaufs beanstandet, sollten diese Angaben über die Review-Nachrichten korrigiert und anschließend mit Update Review beziehungsweise Resubmit erneut eingereicht werden. Ein unveränderter Build muss nicht allein wegen einer Produktablehnung erneut hochgeladen werden. Ein neuer Build ist nur sinnvoll oder erforderlich, wenn auch die App-Funktion, die Kaufdarstellung, die Berechtigung oder die App-Version selbst geändert werden muss.

Xcode 26 und Xcode 27 Beta nicht vermischen

Für einen produktiven App-Store-Release sollte das Team den stabil freigegebenen Distributionsweg mit Xcode 26 verwenden. Ein mit Xcode 27 beta 6 erzeugter Build darf nach der bestätigten Abgrenzung für interne und externe TestFlight-Tests eingesetzt werden; daraus folgt jedoch nicht, dass dieser Beta-Build bereits für die reguläre Kundenverteilung im App Store freigegeben ist. Die aktuellen Apple-Versionshinweise sind vor jedem Release zu prüfen, weil sich die unterstützten Build-Versionen ändern können.

Auf einem Remote Mac kommen zusätzliche Prüfungen hinzu:

1. Die passende Xcode-Version und das gewünschte SDK werden installiert.
2. Das Projekt wird mit einem reproduzierbaren Release-Schema gebaut.
3. Signatur, Team-Zuordnung und Provisioning Profile werden kontrolliert.
4. Der Build wird mit den vorgesehenen Upload-Anmeldedaten übertragen.
5. Der Upload- und Verarbeitungsstatus wird in App Store Connect abgewartet.
6. Erst danach wird der Build der App-Version zugeordnet.
7. Bei einer Verbindungsunterbrechung wird anhand des letzten bestätigten Status fortgesetzt, nicht durch blinde Wiederholung.

Die Zugangsdaten sollten nach dem Prinzip der geringsten Berechtigung getrennt werden. Ein Entwicklerkonto für tägliche Arbeit muss nicht dauerhaft über dieselben Veröffentlichungsrechte wie ein automatisierter Upload-Prozess verfügen. Die Übersicht zu Rollen und Kontoberechtigungen dient als Referenz für diese Aufteilung.

5. Nach dem Absenden objektbezogen reagieren

Nach Submit for Review sollte das Team nicht nur den Status der App betrachten. App-Version, In-App-Kauf, Subscription Group und eigentliche Review-Einreichung können unterschiedliche Zustände anzeigen. Ein bereits verarbeiteter Build bedeutet daher weder, dass das Produkt geprüft wurde, noch dass die App zum Verkauf bereitsteht.

Die Definitionen für App-, Versions- und Submission-Status sollten bei jeder Statusprüfung als Referenz dienen. Besonders hilfreich ist eine kleine Fehlerzuordnung:

• Build bleibt in Verarbeitung: Upload- oder Verarbeitungsproblem prüfen.
• Produkt fehlt im Entwurf: Add-for-Review-Zuordnung und Produktstatus prüfen.
• Abonnement wird abgelehnt: Subscription Group, Produktdaten und Review Notes prüfen.
• App-Version wird abgelehnt: App-Funktion, Metadaten oder Build-bezogene Hinweise prüfen.
• Produkt abgelehnt, App-Version unverändert: Produktnachricht korrigieren und Update Review verwenden.
• Mehrere Objekte gemeinsam abgelehnt: Die Review-Nachrichten je Objekt lesen, statt nur den Sammelstatus zu behandeln.

Nach einer Ablehnung sollte zuerst die konkrete Nachricht geöffnet werden. Danach wird festgehalten, welches Objekt geändert wurde, wer die Änderung vorgenommen hat und ob ein neuer Build wirklich notwendig ist. Eine erneute Binärdatei ohne funktionale Änderung erhöht nicht automatisch die Aussicht auf Genehmigung und erschwert die spätere Nachvollziehbarkeit.

Für kleine Teams empfiehlt sich ein Release-Protokoll mit vier getrennten Spalten: Produktstatus, Buildstatus, Reviewstatus und Verkaufsstatus. So lässt sich erkennen, ob die Blockade in der Konfiguration, im Upload, in der Prüfung oder in der tatsächlichen Verfügbarkeit liegt.

6. Den Ablauf für Folgeprodukte dauerhaft dokumentieren

Nach der ersten erfolgreichen Einreichung sollte der nächste Produkt-Release bewusst als Prozessprobe behandelt werden. Das Team kann damit prüfen, ob ein Folgeprodukt tatsächlich unabhängig eingereicht werden kann und ob die Zuständigkeiten zwischen Entwicklung, Release und Review geklärt sind.

Ein belastbares Register enthält mindestens:

• Produktname und Product ID;
• exakten Produkttyp;
• Subscription Group, falls zutreffend;
• Datum und Version der ersten Genehmigung;
• zugehörige App-Version;
• Speicherort der Review-Screenshots und Review Notes;
• verantwortliche Person für Produktdaten;
• verantwortliche Person für Build und Signierung;
• erforderliche Kontorolle;
• Ergebnis von Upload, Verarbeitung und Review;
• dokumentierte Wiederherstellung bei einer Unterbrechung.

Die Build-Erstellung, die Einreichung und die Verwaltung der Zugangsdaten sollten voneinander getrennt werden. Dadurch muss der tägliche Entwicklungszugang nicht mit langfristig gespeicherten Veröffentlichungsschlüsseln ausgestattet sein. Für GDPR- und DSGVO-konforme Abläufe gehören außerdem Logs, Screenshots und Kontoinformationen nur in geschützte Speicherorte; unredigierte Team- oder Kundendaten haben in einem öffentlichen Fehlerbericht nichts verloren.

Die Entscheidung vor dem nächsten Release

Diese Tabelle ersetzt keine Statusprüfung in App Store Connect, verhindert aber die drei typischen Fehlentscheidungen: ein Folgeprodukt fälschlich an eine neue Version zu binden, ein Erstprodukt ohne neue Version einzureichen oder nach einer Produktablehnung unnötig eine unveränderte Binärdatei hochzuladen.

7. Aktuelle Arbeitsumgebung gegen Remote-Mac-Lösung abwägen

Ein Windows- oder Linux-Arbeitsplatz kann für Quellcode, Design, Backend und viele vorbereitende Aufgaben ausreichen. Für einen stabilen iOS-Veröffentlichungsprozess bleiben jedoch mehrere Abhängigkeiten: Xcode benötigt macOS, Signierung und Provisioning müssen in einer passenden Apple-Umgebung ausgeführt werden, und ein Build-Rechner muss für Uploads und Wiederholungen verfügbar sein. Eine rein lokale Ersatzumgebung ist deshalb als dauerhafte Release-Infrastruktur nicht immer die sinnvollste Wahl.

Auch ein gemeinsam genutzter Büro-Mac hat konkrete Nachteile: Er ist nicht zwingend rund um die Uhr erreichbar, konkurriert mit der Arbeit anderer Personen und kann bei einem fehlgeschlagenen Upload nicht zuverlässig als kontinuierlicher Dienst weiterlaufen. Ein eigener Mac ist technisch klar, verursacht aber Anschaffungskosten, Wartung, Speicherbedarf und eine ungenutzte Kapitalbindung, wenn nur gelegentlich signiert oder eingereicht wird.

Für ein Team, das nur zu bestimmten Releases eine stabile Xcode-Umgebung benötigt, kann ein Remote Mac von RUVCLOUD deshalb die passendere Zwischenlösung sein: Die Umgebung bleibt für Build, Signierung und Upload erreichbar, ohne dass für seltene Veröffentlichungen dauerhaft eigene Hardware betrieben werden muss. Vor einer Entscheidung sollten allerdings Netzwerkqualität, benötigte Laufzeit, physische Gerätezugriffe und die gewünschte Mietdauer ehrlich bewertet werden. Bei dauerhaft hoher Last oder notwendigem USB-Zugriff ist ein eigener Mac unter Umständen besser geeignet.

Wer die nächste Einreichung unter realen Bedingungen vorbereiten möchte, kann zunächst die Remote-Mac-Umgebung von RUVCLOUD prüfen. Für eine länger planbare Nutzung sind außerdem die Mietoptionen und Preise relevant; dabei sollte nicht nur der Monatsbetrag, sondern auch die benötigte Verfügbarkeit und der Aufwand für Wiederherstellung verglichen werden.

Die eigentliche Empfehlung lautet daher: Erst den Produkttyp und den Genehmigungsstatus feststellen, danach den Add-for-Review-Entwurf mit den passenden Objekten erstellen und erst dann entscheiden, ob ein neuer Build notwendig ist. Wenn der lokale Mac fehlt oder nicht zuverlässig für die nächste Veröffentlichung bereitsteht, kann eine zeitweise gemietete Mac-Umgebung von RUVCLOUD die Lücke für Build, Upload und Wiederholung schließen.