Sie möchten Abonnements bündeln, ohne versehentlich bestehende Einzelkäufe abzuschaffen?

Schnellentscheidung: Bleiben Abonnements einzeln kaufbar und kommt nur eine gemeinsame Kaufoption hinzu, prüfen Sie zuerst ein Bundle. Sollen mehrere Apps als ein Dienst mit nicht separat angebotenen Abonnements funktionieren, prüfen Sie eine Suite. Für Kooperationen zwischen Entwicklern kommt ein Multi-Developer-Bundle infrage. Vor der Umsetzung müssen Sie StoreKit 2, die Zielsysteme und Apples Antrags- und Konfigurationsablauf abgleichen.

Dieser Leitfaden richtet sich an Sie, wenn Sie eine iOS-App mit mehreren Abonnementangeboten betreiben und eine gemeinsame Option erwägen.
Er hilft Ihnen ebenso, wenn Sie mehrere Apps über ein zusammenhängendes Abo zugänglich machen wollen.
Planen Sie eine Zusammenarbeit mit anderen Entwicklern, finden Sie hier die Punkte, die vor einem Antrag geklärt sein müssen.

Zuletzt aktualisiert am 25.10.2026. Die Angaben wurden mit Apples Dokumentation zu Bundles und Suites, der WWDC-2026-Erläuterung zu In-App-Käufen und den unten verlinkten StoreKit-Testhinweisen abgeglichen. Da Apple Voraussetzungen und Abläufe ändern kann, sollten Sie die verlinkten Vorgaben vor dem Antrag erneut prüfen.

Einzelne App: Bundle statt Suite prüfen

Wenn Sie nur eine App betreiben, ist die Zahl Ihrer Abonnements allein kein Grund, eine Suite zu wählen. Entscheidend ist, ob die einzelnen Angebote weiterhin eigenständig kaufbar sein sollen. Apple beschreibt Bundles als Möglichkeit, bestehende Abonnements gemeinsam anzubieten, während die einzelnen Abos weiterhin separat erhältlich sein können. Prüfen Sie dazu Apples Beschreibung der Bundles und Suites.

Erstellen Sie zunächst eine Bestandsaufnahme, bevor Sie Produkte in App Store Connect ändern:

  • SKU und Produktkennung: Welche Abonnements existieren, und welche davon sollen in ein gemeinsames Angebot einfließen?
  • Einzelkauf: Soll ein Nutzer weiterhin nur ein bestimmtes Abonnement erwerben können?
  • Berechtigungen: Welche Funktionen und Inhalte werden durch jedes einzelne Abo freigeschaltet?
  • Gemeinsames Angebot: Was erhält der Nutzer zusätzlich oder anders, wenn er die Kombination kauft?
  • Bestandskunden: Wie soll Ihre App bereits erworbene Zugriffsrechte im neuen Produktmodell erkennen und darstellen?

Diese Liste schützt vor einem häufigen Produktfehler: Ein gemeinsamer Kauf wird definiert, ohne festzulegen, wie Einzelangebote daneben weiter funktionieren. Dann passen Produktseite, Kaufablauf und tatsächlich freigeschaltete Funktionen möglicherweise nicht zusammen. Halten Sie daher für jedes Produkt fest, welche Berechtigung es auslöst und welche App diese Berechtigung anerkennt.

StoreKit 2 ist dabei nicht nur ein Schalter für eine neue Verkaufsoption. Sie müssen nachvollziehen, wie Ihre App den Kaufstatus ermittelt und wie sie daraus Rechte ableitet. Apple verlangt StoreKit 2 für die beschriebenen Bundles und Suites. Wenn Ihr bestehendes Abo-System auf einer älteren Implementierung beruht, prüfen Sie den Anpassungsbedarf für Kaufabwicklung und Berechtigungsprüfung, statt vorschnell eine vollständige Neuentwicklung anzunehmen. Die relevante Grenze ist der betroffene Ablauf: Erkennen Ihre bestehenden App-Komponenten den Kauf und wenden sie die zugehörigen Rechte korrekt an?

Mehrere eigene Apps: Produktgrenze vor der Suite festlegen

Bei mehreren Apps liegt die Suite als Idee nahe. Die richtige Entscheidung hängt jedoch nicht daran, ob Sie mehrere App-Store-Einträge verwalten. Fragen Sie stattdessen: Kauft der Nutzer eine Gruppe von Apps als zusammengehörigen Dienst, oder sollen die Abonnements der einzelnen Apps eigenständig bleiben und zusätzlich gemeinsam erhältlich sein?

Prüfen Sie die Produktgrenze anhand der Nutzererfahrung:

  • Ein App-Zugang: Wenn ein Abonnement nur eine App freischaltet und die anderen Angebote unabhängig bleiben sollen, ist eine Suite nicht allein wegen Ihres App-Portfolios begründet.
  • Gemeinsamer Zugang: Wenn der Kauf einen zusammenhängenden Dienst über mehrere Apps freischalten soll und die Abonnements nicht separat verkauft werden, prüfen Sie die Suite.
  • Kombination mit Einzeloptionen: Wenn Nutzer weiterhin einzelne Angebote kaufen können sollen und daneben ein gemeinsamer Kauf sinnvoll ist, prüfen Sie ein Bundle.
  • Unterschiedliche Rechte: Wenn dieselbe Kaufoption je App andere Funktionen freischaltet, müssen Sie diese Rechte vor der Produktauswahl vereinheitlichen oder eindeutig dokumentieren.

Hinweis: Entscheiden Sie nicht allein nach der Zahl Ihrer Apps. Eine Suite verändert die Produktlogik, die Sie Ihren Nutzern erklären müssen. Stimmen Kaufoption, App-Zugang und Berechtigungsprüfung nicht überein, lässt sich der Fehler nicht durch eine sauber konfigurierte Store-Seite beheben.

Ein hilfreiches Dokument für die interne Abstimmung ist eine Rechteübersicht: Notieren Sie für jedes Abonnement, welche App es erkennt, welche Inhalte oder Funktionen es freigibt und ob der Nutzer es separat erwerben kann. Diese Übersicht ist keine Apple-Freigabe und ersetzt keine technische Prüfung. Sie macht aber sichtbar, ob Ihre geplante Produktgrenze zur tatsächlichen Implementierung passt.

Für das bestehende App-Produktmodell gelten außerdem die üblichen Anforderungen an die Abo-Konfiguration. Apples Dokumentation zu automatisch verlängerbaren Abonnements ist dafür eine ergänzende Referenz. Verwenden Sie sie für die Prüfung der regulären Abo-Einrichtung; verwechseln Sie diese allgemeine Produktpflege nicht mit der separaten Bewerbung und Konfiguration von Bundles oder Suites.

Zusammenarbeit zwischen Entwicklern: Bundle und Zuständigkeiten trennen

Wenn mehrere Entwickler ihre Abonnements in einem gemeinsamen Angebot zusammenführen möchten, sieht Apples Dokumentation Multi-Developer-Bundles als möglichen Fall vor. Ein gemeinsames Interesse oder eine unterschriebene Kooperationsabsicht bedeutet jedoch nicht, dass das Angebot bereits zur Veröffentlichung zugelassen ist. Der Antrag und die nachfolgenden Konfigurationsschritte bleiben eigene Voraussetzungen.

Klären Sie vorab, wer für welche Teile verantwortlich ist:

  • Teilnehmende Produkte: Welche Abonnements sollen tatsächlich Teil des gemeinsamen Angebots werden?
  • Rechteinhaber: Wer stellt die Inhalte oder Funktionen bereit, die ein bestimmtes Abo freischaltet?
  • Laufender Betrieb: Wer reagiert auf Fehler, Änderungen und Fragen zu den eigenen App-Rechten?
  • Produktänderungen: Wie erfahren die anderen Beteiligten von Änderungen an Preisen, Funktionen oder Verfügbarkeit?
  • Unterlagen: Welche Angaben und ergänzenden Vereinbarungen verlangt Apple im Antragsprozess?

Die rechtliche und operative Aufteilung sollte nicht erst nach der technischen Implementierung entstehen. Wenn ein Nutzer ein gemeinsames Angebot kauft, muss jede beteiligte App den für sie relevanten Berechtigungsstatus zuverlässig verarbeiten. Ist unklar, wer die jeweilige Leistung bereitstellt oder wie Änderungen abgestimmt werden, ist der Antrag noch nicht der nächste sinnvolle Schritt.

Fassen Sie die Vereinbarungen in einem gemeinsamen Produktblatt zusammen. Es sollte Teilnahme, Zuständigkeiten, Rechteprüfung und Änderungsprozess enthalten. Stimmen alle Beteiligten diesem Blatt zu, können Sie die benötigten Informationen für Apples Antrag und die anschließende Einrichtung zusammentragen. Verwechseln Sie dabei weder eine eingereichte Bewerbung noch eine erhaltene Rückmeldung mit einer abgeschlossenen Konfiguration oder einer Freigabe zur Veröffentlichung.

Ältere Abo-Implementierung: StoreKit 2 und Zielsysteme zuerst prüfen

Apple nennt für Bundles und Suites iOS 27, iPadOS 27, macOS 27 oder tvOS 27 oder höher sowie StoreKit 2 als Voraussetzungen. Prüfen Sie diese Anforderungen anhand der offiziellen Teilnahmebedingungen, bevor Sie die Funktion in Ihre Roadmap aufnehmen. Daraus folgt nicht, dass Sie Ihre gesamte App neu schreiben müssen. Es folgt, dass die betroffenen Kauf- und Rechteabläufe auf die Anforderungen abgestimmt werden müssen.

Gehen Sie bei einer bestehenden Implementierung in dieser Reihenfolge vor:

  1. Zielsystem festhalten: Dokumentieren Sie, welche Mindestversionen Ihre App unterstützt und welche Nutzer die neue Angebotsform nutzen können sollen. Vergleichen Sie diese Angaben mit Apples genannten Systemanforderungen.
  2. Kaufpfad nachzeichnen: Beschreiben Sie, wo die App Produkte lädt, einen Kauf anstößt und nach Abschluss den Status verarbeitet.
  3. Berechtigungen abgleichen: Prüfen Sie, ob einzelne App-Bereiche ihre Zugriffsrechte aus demselben verlässlichen Kaufstatus ableiten.
  4. Migrationsumfang begrenzen: Markieren Sie konkret die Stellen, an denen Ihre bestehende Implementierung nicht mit StoreKit 2 oder dem geplanten Produktmodell übereinstimmt.
  5. Rückwärtskompatibilität planen: Legen Sie fest, welches Verhalten Nutzer auf nicht unterstützten Systemen sehen. Behaupten Sie nicht, die neue Kaufoption sei dort verfügbar, wenn Apples Voraussetzungen nicht erfüllt sind.

Diese Bestandsaufnahme trennt eine notwendige Anpassung von einer unnötigen Komplettmigration. Wenn Ihr bestehender Ablauf bereits auf StoreKit 2 basiert, kann der Änderungsumfang auf neue Produktdarstellung, Berechtigungszuordnung und Tests begrenzt sein. Wenn nicht, ist zuerst zu ermitteln, welche Kauf- und Prüfkomponenten ersetzt oder erweitert werden müssen. Die technische Bestandsaufnahme ist eine eigene Planungsaufgabe und keine Aussage darüber, ob Apple einen Antrag genehmigt.

Antrag, Tests und Veröffentlichung als getrennte Meilensteine planen

Ein häufiger Planungsfehler besteht darin, lokale Tests, den Antrag und die Store-Konfiguration als einen einzigen Arbeitsschritt zu behandeln. Das sind unterschiedliche Meilensteine. Apple beschreibt einen Ablauf, in dem Sie zunächst die Teilnahme beantragen, eine Bestätigung abwarten, gegebenenfalls weitere Abonnementangaben einreichen und anschließend die Konfiguration vervollständigen. Prüfen Sie den aktuellen Stand direkt in Apples Dokumentation zu Bundles und Suites; eine Bewerbung ist keine Garantie für eine Genehmigung.

Meilenstein: Produktdefinition. Schließen Sie die SKU- und Rechteübersicht ab. Entscheiden Sie, ob einzelne Abonnements separat bleiben sollen, ob mehrere Apps gemeinsam Zugang gewähren und ob weitere Entwickler beteiligt sind. Erst wenn diese Produktregeln verständlich sind, sollte das Team festlegen, welche Angebotsform beantragt wird.

Meilenstein: technische Prüfung. Erfassen Sie StoreKit-2-Stand, Zielsysteme und Zuständigkeiten für die Rechteprüfung. Benennen Sie die betroffenen App-Komponenten, bevor Sie Änderungen beginnen. So lässt sich nachvollziehen, ob Fehler aus der Produktkonfiguration, der Kaufverarbeitung oder der App-internen Freischaltung stammen.

Meilenstein: Antrag und Rückmeldung. Reichen Sie die von Apple geforderten Angaben ein und dokumentieren Sie den Status. Planen Sie Zeit für Rückfragen oder ergänzende Unterlagen ein, statt einen Veröffentlichungstermin so zu kalkulieren, als wäre die Zustimmung bereits sicher.

Meilenstein: Konfiguration. Erst nach der erforderlichen Rückmeldung arbeiten Sie die vorgesehenen Abonnementdaten und die Store-Einrichtung ab. Apples Anleitung zum Erstellen und Einreichen von App Bundles in App Store Connect betrifft App Bundles. Diese herkömmliche Funktion ist nicht dasselbe wie ein StoreKit-Abonnement-Bundle oder eine Suite. Prüfen Sie daher, ob eine Anleitung für App Bundles tatsächlich zu Ihrem Vorhaben passt, bevor Sie daraus Schritte für die Abo-Konfiguration ableiten.

Meilenstein: lokale StoreKit-Prüfung. Mit Xcode 27 können Sie die vorgesehenen StoreKit-Szenarien in einer lokalen Testumgebung untersuchen. Apple beschreibt die Einrichtung im Leitfaden zum StoreKit-Testen in Xcode. Ein erfolgreicher lokaler Test belegt, dass der geprüfte Ablauf in dieser Umgebung funktioniert. Er belegt nicht, dass Antrag und App Store Connect-Konfiguration abgeschlossen sind.

Meilenstein: Sandbox und reale Kaufstrecke. Trennen Sie lokale Tests von Tests in der Sandbox und von der abschließenden Prüfung der Store-Konfiguration. Apples Hinweise zum StoreKit-Test über Entwicklungsphasen hinweg beschreiben diese unterschiedlichen Testbereiche. Führen Sie eine Abnahme erst dann als vollständig, wenn Kaufdarstellung, tatsächliches Kaufergebnis und Rechtefreigabe in jeder beteiligten App getrennt überprüft wurden.

Für die Abnahme sollten Sie ein Protokoll führen, das Produktkennung, Testumgebung, Kaufresultat und erwartete Berechtigung miteinander verknüpft. Speichern Sie keine unnötigen persönlichen Daten oder Geheimnisse im Testprotokoll. Bei Teamzugriffen auf Entwicklungsumgebungen sollten Zertifikate, Zugangsdaten und vertrauliche App-Informationen nach dem Prinzip der geringsten Berechtigung behandelt werden. Das reduziert vermeidbare Sicherheitsrisiken, ersetzt aber weder Ihre Datenschutzprüfung nach DSGVO noch Apples Vorgaben zur Produktkonfiguration.

Entscheidung in der Praxis: Abhakliste und klare Auswahlregeln

Nutzen Sie diese Abhakliste in der Produktbesprechung. Setzen Sie ein Häkchen erst, wenn das Team den Punkt anhand seiner vorhandenen Abonnements und App-Rechte beantworten kann:

  • [ ] Einzelkauf: Sollen die bestehenden Abonnements auch nach Einführung eines gemeinsamen Angebots weiterhin einzeln kaufbar sein?
  • [ ] App-Grenze: Soll der Kauf Zugang zu einer einzelnen App oder zu einer zusammenhängenden Gruppe mehrerer Apps gewähren?
  • [ ] Rechte: Ist für jedes Produkt dokumentiert, welche App welche Funktionen oder Inhalte freischaltet?
  • [ ] Kooperation: Sind bei mehreren Entwicklern Produkte, Rechteinhaber, Support und Änderungsverantwortung geklärt?
  • [ ] Technische Grundlage: Verarbeitet Ihre Implementierung StoreKit 2, und erfüllen die Zielsysteme die von Apple genannten Voraussetzungen?
  • [ ] Freigabestatus: Sind Antrag, Rückmeldung, ergänzende Angaben, Store-Konfiguration und Tests als getrennte Meilensteine eingeplant?

Leiten Sie die Entscheidung aus den Antworten ab:

  • Wenn Einzelabonnements weiter kaufbar bleiben sollen und Sie zusätzlich eine gemeinsame Kaufoption anbieten möchten, dann prüfen Sie zuerst ein Bundle. Wenn nicht, klären Sie, ob die einzelnen Angebote bestehen bleiben oder als gemeinsamer Dienst neu zugeschnitten werden sollen.
  • Wenn mehrere Apps als ein zusammenhängender Dienst angeboten werden sollen und die Abonnements nicht separat verkauft werden, dann prüfen Sie eine Suite. Wenn Nutzer weiterhin einzelne App-Abos wählen sollen, spricht das für die Prüfung eines Bundle-Modells statt für eine Suite allein aufgrund der App-Anzahl.
  • Wenn Abonnements verschiedener Entwickler zusammengeführt werden sollen, dann klären Sie vor der technischen Umsetzung die Teilnahme, Rechte und Zuständigkeiten für ein Multi-Developer-Bundle. Wenn diese Punkte offen sind, verschieben Sie den Antrag, bis die Beteiligten ein gemeinsames Produktblatt freigegeben haben.
  • Wenn StoreKit 2 oder die genannten Zielsysteme noch nicht abgedeckt sind, dann planen Sie zuerst eine begrenzte technische Bestandsaufnahme. Wenn die Voraussetzungen erfüllt sind, fahren Sie mit Antrag, Konfiguration und getrennten Teststufen fort.
  • Wenn ein lokaler StoreKit-Test erfolgreich ist, dann dokumentieren Sie nur den lokal geprüften Ablauf. Wenn App Store Connect noch nicht vollständig eingerichtet oder der Antrag nicht abgeschlossen ist, behandeln Sie die Veröffentlichung weiterhin als offen.

Diese Entscheidungshilfe verhindert zwei kostspielige Fehlentscheidungen: ein Produktmodell zu bauen, das nicht zu den gewünschten Einzelkäufen passt, und eine Veröffentlichung einzuplanen, bevor die externe Freigabe und Store-Konfiguration abgeschlossen sind. Wählen Sie die Angebotsform erst, nachdem Sie Produktrechte und Kaufwege schriftlich festgehalten haben.

Häufige Fragen zu Bundles und Suites

Was unterscheidet ein StoreKit Bundle von einer Suite?

Ein Bundle ist zu prüfen, wenn bestehende Abonnements weiterhin einzeln angeboten werden sollen und zusätzlich eine gemeinsame Kaufoption sinnvoll ist. Eine Suite passt eher, wenn mehrere Apps als zusammengehöriger Dienst angeboten werden und die Abonnements nicht unabhängig voneinander verkauft werden sollen. Entscheidend ist damit nicht die Zahl Ihrer Apps, sondern welche Kauf- und Nutzungsrechte Sie tatsächlich versprechen.

Welche Lösung passt zu einem einzelnen iOS-App-Projekt?

Bei einer einzelnen App sollten Sie zuerst feststellen, ob Ihre verschiedenen Abonnements auch nach Einführung des gemeinsamen Angebots weiterhin einzeln kaufbar bleiben sollen. Ist das der Fall, prüfen Sie ein Bundle. Eine Suite ist nicht automatisch die bessere Wahl, nur weil Ihre App mehrere Funktionen oder Tarife enthält. Ordnen Sie jedem Produkt die freigeschalteten Funktionen und die Kaufmöglichkeit zu.

Können mehrere Entwickler ein gemeinsames Abonnement-Bundle anbieten?

Apple führt Bundles mit mehreren Entwicklern als möglichen Anwendungsfall auf. Das bedeutet jedoch nicht, dass eine Kooperation schon für eine Veröffentlichung genügt. Klären Sie vor dem Antrag, welche Abonnements teilnehmen, wer die jeweiligen Rechte bereitstellt und wer für Support und Änderungen verantwortlich ist. Reichen Sie die erforderlichen Angaben ein und warten Sie die Bestätigung sowie die anschließende Konfiguration ab.

Welche System- und StoreKit-Voraussetzungen müssen Sie prüfen?

Apple nennt iOS 27, iPadOS 27, macOS 27 oder tvOS 27 oder höher sowie StoreKit 2 als Voraussetzungen für Bundles und Suites. Prüfen Sie daher, ob Ihre Zielgruppe diese Systemanforderungen erfüllen kann und ob Ihre App Kaufstatus und Berechtigungen mit StoreKit 2 verarbeitet. Ein lokaler StoreKit-Test ersetzt weder den Apple-Antrag noch die Konfiguration in App Store Connect.

Nächster Schritt: erst den Ablauf absichern, dann die Umgebung wählen

Ein Bundle oder eine Suite ist erst dann eine tragfähige Entscheidung, wenn Produktgrenzen, einzelne Kaufoptionen und Rechtevergabe zusammenpassen. Wenn Sie mit der Auswahl fertig sind, prüfen Sie den StoreKit-Ablauf zunächst in Ihrer vorhandenen Entwicklungsumgebung. Müssen Sie dafür erst eine eigene Mac-Hardware anschaffen, entstehen neben dem Kauf auch Aufwand für Wartung, Updates und den sicheren Zugriff; ein lokaler Rechner ist außerdem an seine Verfügbarkeit und seinen Speicher gebunden.

Für eine zeitlich begrenzte Implementierung oder zusätzliche Testumgebung kann ein gemieteter Mac eine flexiblere Alternative sein. Wenn Sie zunächst nachvollziehen möchten, welche Möglichkeiten VMSPIN für den Zugriff auf eine entfernte Mac-Umgebung beschreibt, finden Sie die Übersicht auf der deutschsprachigen VMSPIN-Seite. Wenn Sie anschließend Kosten und Mietoptionen für Ihre Testphase vergleichen möchten, helfen die Mietoptionen für Mac-Umgebungen. Prüfen Sie dabei, ob ein entfernter Mac zu Ihren Anforderungen an Zugriff, vertrauliche Entwicklungsdaten und wiederholbare Tests passt. Für ein dauerhaftes, intensives Projekt oder benötigte physische Schnittstellen kann ein eigener Mac weiterhin die bessere Wahl sein.