Guideline 3.1.1: Wann In-App-Kauf Pflicht ist

Die Guideline 3.1.1 schreibt Apples In-App-Kauf vor, sobald deine App digitale Inhalte oder Funktionen freischaltet: Abo, Vollversion, Spielwährung, Premium-Inhalte. Eine Ablehnung nach 3.1.1 heißt, dass Apple einen anderen Zugang zu diesen Inhalten gefunden hat: Bezahlung auf deiner Website, Lizenzschlüssel, eigener Code, Button zu einer Bezahlseite. Die Lösung führt über den In-App-Kauf, außer dein Fall fällt unter eine Ausnahme oder eine regionale Regel.

Ich veröffentliche meine eigenen iOS-Apps, und die mit Abo verkaufen es über Apples In-App-Kauf. Ich habe nie eine Ablehnung nach 3.1.1 bekommen, und ich werde dir nichts anderes erzählen. Dieser Guide stützt sich auf den offiziellen Text in der Fassung vom 8. Juni 2026, gelesen am 15. Oktober 2026, und auf die regionalen Bedingungen, die Apple veröffentlicht. Den verwandten Fall der Abos, mit zwei echten Ablehnungen, findest du im Guide zur Guideline 3.1.2.

Was sagt die Guideline 3.1.1?

Die 3.1.1, „In-App Purchase“, eröffnet den Abschnitt 3.1 „Payments“ der App Review Guidelines. Daher der Betreff der Mail: „Guideline 3.1.1 - Business - Payments - In-App Purchase“. Der erste Satz sagt das Wesentliche: Um Funktionen in deiner App freizuschalten, „you must use in-app purchase“, du musst den In-App-Kauf nutzen. Apple nennt Abos, Spielwährungen, Level, Premium-Inhalte und die Vollversion.

Der nächste Satz zielt auf Umgehungen. Eine App darf keinen eigenen Mechanismus nutzen, um Inhalte freizuschalten: Apple nennt Lizenzschlüssel, Augmented-Reality-Marker, QR-Codes, Kryptowährungen und Krypto-Wallets.

Dieselbe Regel enthält Pflichten, die oft vergessen werden:

• Per In-App-Kauf gekaufte Credits und Währungen verfallen nicht, und jeder wiederherstellbare Kauf hat einen Wiederherstellungsmechanismus;
• eine bezahlte Truhe oder Ziehung („Loot Box“) zeigt vor dem Kauf die Chancen für jede Art von Gegenstand an;
• eine digitale Geschenkkarte, ein Gutschein oder Coupon wird in der App per In-App-Kauf verkauft; eine physische Karte, die per Post verschickt wird, darf über ein anderes Zahlungsmittel laufen;
• eine App ohne Abo kann eine zeitlich begrenzte Testphase anbieten, als kostenlosen In-App-Kauf mit dem Namen „XX-day Trial“, der vor dem Start die Dauer angibt, was danach wegfällt und was man zahlen muss;
• Trinkgeld an den Entwickler ist möglich, per In-App-Kauf.

Situationen, die eine Ablehnung nach 3.1.1 auslösen

Was die App macht	Warum Apple ablehnt	Die Lösung
Schaltet auf deiner Website gekaufte Inhalte frei	Kein gleichwertiger In-App-Kauf	Auch per In-App-Kauf verkaufen
Zeigt „Auf unserer Website bezahlen“ an	Verweis auf andere Bezahlung	Button entfernen, außer bei Ausnahme
Verlangt Lizenzschlüssel oder eigenen Code	Verbotener Freischaltmechanismus	Apples Angebotscodes
Schaltet gegen Kryptowährung frei	Verbotener Freischaltmechanismus	In-App-Kauf
Verkauft Credits, die verfallen	Pflicht aus der 3.1.1	Dauerhafte Credits und Wiederherstellung
Verkauft eine Truhe ohne Wahrscheinlichkeiten	Chancen nicht angezeigt	Wahrscheinlichkeiten vor dem Kauf sichtbar

Die erste Zeile wird am häufigsten missverstanden. In einer Ablehnung, die in den Apple-Foren gepostet wurde, heißt es, dass die App „accesses digital content purchased outside the app“, also auf woanders gekaufte Inhalte zugreift, „but that content isn't available to purchase using in-app purchase“. Apple stört nicht, dass du eine Website hast, die verkauft: Apple stört, dass die App nicht denselben Kauf über Apple anbietet.

Um kostenlosen Zugang oder einen Rabatt anzubieten, hat Apple ein eigenes System: Angebotscodes (Offer Codes). Laut StoreKit-Dokumentation funktionieren sie für alle Arten von In-App-Käufen: Abos, Verbrauchsartikel und Nicht-Verbrauchsartikel. Du erstellst sie in App Store Connect, und der Nutzer gibt sie im App Store oder in deiner App ein.

Die Ausnahmen: wann kein In-App-Kauf nötig ist

Die Regel 3.1.3 listet die Apps auf, die ein anderes Zahlungsmittel nutzen dürfen. Hier das Raster, mit dem ich ein Projekt einordne.

Dein Fall	In-App-Kauf Pflicht?	Regel
Abo, Vollversion, digitaler Inhalt	Ja	3.1.1
Physisches Produkt, Dienstleistung außerhalb der App	Nein, anderes Zahlungsmittel Pflicht	3.1.3(e)
Live-Unterricht oder -Beratung, eins zu eins	Nein	3.1.3(d)
Live-Unterricht in der Gruppe	Ja	3.1.3(d)
Presse, Bücher, Musik, Video, woanders gekauft	Nein, für den Zugriff	3.1.3(a)
Plattformübergreifender Dienst, auf Website gekauft	Zugriff erlaubt, wenn auch als In-App-Kauf	3.1.3(b)
Tool, an ein Unternehmen für Mitarbeiter verkauft	Nein	3.1.3(c)
Kostenlose Begleit-App zu einem Web-Tool, ohne Kauf	Nein	3.1.3(f)

Zwei Grenzen. Eine App, die eine Ausnahme nutzt, darf in der App nicht zu einem anderen Zahlungsmittel drängen, außer im US-Storefront und in den von Apple vorgesehenen Fällen. Dafür stellt Apple klar: „Developers can send communications outside of the app“. Du darfst deinen Nutzern außerhalb der App schreiben, zum Beispiel per E-Mail.

Die Regeln nach Region im Oktober 2026

Hier ändern sich die Texte schnell. Das Folgende basiert auf Apples Texten, gelesen am 15. Oktober 2026: Lies sie erneut, bevor du eine externe Bezahlung programmierst.

Region	Was zusätzlich zum In-App-Kauf erlaubt ist
USA	Buttons und Links zu anderer Bezahlung, ohne Entitlement
Europäische Union	Alternative Bezahlung in der App und Angebote außerhalb, mit Regeln
Japan, Brasilien, Südkorea	Eigene Programme, auf Antrag eines Entitlements
Andere Länder	Kein Button, Link oder Aufruf zu anderer Bezahlung

USA

Die Regel 3.1.1(a) stellt klar, dass Entitlements „are not required for developers to include buttons, external links, or other calls to action in their United States storefront apps“. Im US-Storefront ist ein Button zu deiner Website also erlaubt. Dein Binary ist aber überall dasselbe: Wenn du diesen Button einbaust, muss die App wissen, in welchem Storefront der Nutzer ist. StoreKit liefert das mit Storefront.

Europäische Union

Seit dem 1. Oktober 2026 gelten neue Bedingungen, laut Apples Seite zu den Zahlungsoptionen in der EU. Du kannst einfach nur beim In-App-Kauf bleiben, ohne etwas zu ändern. Du kannst aber auch einen Zahlungsanbieter in der App anbieten oder Angebote außerhalb der App, zum Beispiel auf deiner Website. Apple verlangt dann unter anderem:

• das Entitlement „StoreKit External Purchases or Offers“ und, für einen Link oder eine Bezahlung in der App, das Informationsfenster des Systems;
• den In-App-Kauf mindestens so sichtbar wie die andere Option, wenn beide auf dem Bildschirm sind;
• keine Erwähnung dieser Zahlungen in deinem App-Store-Eintrag;
• eine Kindersicherung für Minderjährige und keine Angebote außerhalb der App unter 13 Jahren, oder höher je nach Land;
• dieselbe Wahl in allen EU-Storefronts für 12 Monate.

Je nach gewählter Option fallen Provisionen an. Lies den entsprechenden Abschnitt auf derselben Seite, bevor du dich entscheidest.

Andere Länder

Anderswo bleibt die Regel streng: „apps and their metadata may not include buttons, external links, or other calls to action“ zu einem anderen Zahlungsmittel. Das Wort „metadata“ zählt: Eine Beschreibung mit „günstiger auf unserer Website“ fällt ebenfalls unter die Regel. Einige Länder, darunter Japan, Brasilien und Südkorea, haben eigene Programme, aufgelistet in der External-Purchase-Dokumentation.

Eine Ablehnung nach 3.1.1 beheben und Apple antworten

1. Finde den Zugang. Die Nachricht nennt den betroffenen Inhalt oder Bildschirm: woanders gekaufte Inhalte, Button, Code, Link.
2. Schließ ihn oder biete eine Alternative. Entweder entfernst du Button oder Code, oder du verkaufst denselben Inhalt per In-App-Kauf.
3. Beruf dich nur auf eine Ausnahme, wenn sie wirklich zutrifft. Nenne den Buchstaben der 3.1.3 und erkläre in zwei Sätzen, warum dein Fall darunter fällt.
4. Gib dem Prüfer etwas zum Testen. Ein Demo-Konto und den Weg zur Paywall, in den Review-Notizen, wie ich es im Guide zur Guideline 2.1 erkläre.

Du antwortest im Bereich App Review von App Store Connect, nach dem Ablauf zum Antworten an App Review. Hier eine Vorlage für den häufigsten Fall, auf der Website gekaufte Inhalte. Es ist ein Beispiel: Ersetze Build, Produkt und Ablauf durch deine eigenen.

Hello,

Thank you for your review.

Issue: the app gave access to premium content purchased on our
website, without offering the same purchase in the app.

Fix in build X:
- Premium access is now available as an auto-renewable
  subscription through in-app purchase, on the paywall.
- The "Subscribe on our website" button has been removed.
- A "Restore Purchases" button is available on the paywall.

How to verify: launch the app and open any premium screen.
The paywall shows the in-app purchase options.

Best regards,

Button und Paywall stecken im Code: Du brauchst einen neuen Build. Wenn du weiterhin überzeugt bist, dass dein Fall eine Ausnahme ist, kannst du laut Apple auch Einspruch beim App Review Board einlegen.

Den In-App-Kauf einbauen, ohne alles neu zu schreiben

Für Einsteiger ist der einfachste Weg, die Produkte in App Store Connect anzulegen und sie dann mit RevenueCat an die App anzubinden: Die Anleitung steht in RevenueCat: ein In-App-Abo einrichten. Wenn du zwischen den beiden Modellen schwankst, lies Abo oder Einmalkauf. Wenn du mit einem No-Code-Tool baust, prüf, ob es In-App-Käufe kann: Das ist ein Punkt in eine App ohne Programmieren erstellen.

Sobald dein In-App-Kauf ein Abo ist, kommt die 3.1.2 dazu: abgerechneter Betrag hervorgehoben, Laufzeit, Verlängerung, Links. Die häufigsten Fehler auf dem Bildschirm stehen in iOS-Paywall: 7 Anfängerfehler.

Die 3.1.1-Checkliste vor dem Einreichen

• Alles, was in der App freigeschaltet wird (Funktion, Inhalt, Level, Währung), ist per In-App-Kauf erhältlich.
• Kein Button, Link oder Text verweist auf eine externe Bezahlung, außer im US-Storefront oder mit einem erhaltenen regionalen Programm.
• Die Beschreibung deines Eintrags erwähnt kein anderes Zahlungsmittel.
• Ein auf deiner Website verkaufter Inhalt ist auch per In-App-Kauf in der App erhältlich.
• Kein Lizenzschlüssel, kein QR-Code, kein eigener Code und keine Kryptowährung schaltet irgendetwas frei.
• Um Zugang zu verschenken, nutzt du Apples Angebotscodes.
• Gekaufte Credits verfallen nicht, und ein Button „Restore Purchases“ funktioniert.
• Jede bezahlte Truhe oder Ziehung zeigt vor dem Kauf ihre Wahrscheinlichkeiten an.
• Ein physisches Produkt oder eine Dienstleistung außerhalb der App läuft über Apple Pay oder Karte, nicht über den In-App-Kauf.
• Deine Review-Notizen sagen, wo die Käufe zu finden sind und, falls du dich auf eine Ausnahme berufst, auf welche.

Deine App vor dem Einreichen prüfen

Wenn deine App gerade nach 3.1.1 abgelehnt wurde, hilft dir das Apple Review Kit, die zitierte Regel zu finden, zu verstehen, was sie verlangt, und liefert ein Beispiel für Korrektur und Antwort. Seine Notizen für den Prüfer decken den In-App-Kauf ab. Für einen menschlichen Blick buch eine Stunde mit mir: Wir lesen Apples Nachricht und suchen den Zugang, den Apple gesehen hat. Das komplette Vorgehen steht auf der Seite von Apple abgelehnte App, die Einrichtung des Kaufs auf der Seite iOS-In-App-Abo.

Wenn du deinen ersten Release vorbereitest, mach deine kostenlose Diagnose: Sie bringt die Schritte in die richtige Reihenfolge und schickt dir meine Checkliste gegen Apple-Ablehnungen. Um eine mobile App zu erstellen, die von Anfang an per In-App-Kauf verkauft, startet das iOS Kit mit einem Code, in dem Paywall und Abos schon eingebaut sind.

Niemand kann garantieren, dass Apple deine App annimmt. Was ich tun kann: dir helfen, das richtige Zahlungsmittel zu wählen, bevor du den Code schreibst.

Häufige Fragen

Was bedeutet „Guideline 3.1.1 - Business - Payments - In-App Purchase“?

Das ist der vollständige Titel der Regel zum In-App-Kauf in Apples Nachricht. Er zeigt an, dass deine App auf einem anderen Weg als dem In-App-Kauf Zugang zu digitalen Inhalten oder Funktionen gibt: Bezahlung auf einer Website, Code, Lizenzschlüssel oder Link zu einer Bezahlseite.

Darf ich auf meine Website verlinken, wo es günstiger ist?

Im US-Storefront ja: Die Regel erlaubt Buttons und Links ohne Entitlement. In der Europäischen Union geht das mit Apples Entitlement und unter dessen Bedingungen. Anderswo dürfen weder die App noch ihr Eintrag auf ein anderes Zahlungsmittel verweisen, außer mit einem regionalen Programm.

Darf ich meine App mit einem Promo-Code freischalten?

Nicht mit einem eigenen Code: Die 3.1.1 verbietet app-eigene Freischaltmechanismen wie Lizenzschlüssel. Nutze Apples Angebotscodes, die du in App Store Connect erstellst. Sie funktionieren für Abos und für die anderen Arten von In-App-Käufen.

Brauche ich den In-App-Kauf, um ein physisches Produkt oder eine Dienstleistung zu verkaufen?

Nein. Ein physisches Produkt oder eine Dienstleistung außerhalb der App, etwa ein geliefertes Essen oder eine Fahrt, muss über ein anderes Zahlungsmittel laufen, Apple Pay oder Bankkarte. Auch ein Live-Kurs zwischen zwei Personen kommt ohne aus, ein Live-Kurs in der Gruppe aber nicht.

Kann sich ein Kunde mit Abo auf meiner Website in der App anmelden?

Ja, bei einem plattformübergreifenden Dienst, sofern derselbe Zugang auch per In-App-Kauf in der App erhältlich ist. Das ist die Regel 3.1.3(b). Ohne dieses Angebot in der App landest du bei der typischen 3.1.1-Ablehnung: woanders gekaufte Inhalte, die man nicht über Apple kaufen kann.

Reicht RevenueCat, um die 3.1.1 einzuhalten?

RevenueCat baut auf Apples In-App-Kauf auf, verursacht also kein 3.1.1-Problem. Einen externen Bezahl-Button oder einen eigenen Code in deiner App entfernt es aber nicht. Die Konformität musst du weiterhin Bildschirm für Bildschirm prüfen, und in deinem Eintrag.