Table of Contents
Apple nimmt in der Regel 30 % Provision für kostenpflichtige Apps und In-App-Käufe, was die Einnahmen von Indie-Entwicklern erheblich schmälern kann. (Kostenlose Apps zahlen keine Provision.) Dieser Standardsatz gilt für die meisten digitalen Transaktionen in iOS-Apps, was es für kleine Entwickler schwierig macht, einen Mehrwert zu erzielen. Glücklicherweise haben Apple und die Regulierungsbehörden Möglichkeiten eingeführt, um diese Kürzung zu verringern. In diesem Beitrag erläutern wir das Provisionsmodell von Apple, beschreiben von Apple genehmigte Erleichterungen (wie das Small Business Program) und erkunden praktische Umgehungsmöglichkeiten – von Stripe-basierten Web-Checkouts bis zu Progressive Web Apps (PWAs) und reinen Web-Abonnementmodellen. Wir untersuchen die Vor- und Nachteile jedes Ansatzes (in der folgenden Tabelle zusammengefasst), die rechtlichen Auswirkungen und die Einhaltung von Vorschriften und geben Tipps, wie man in Apples Gunst bleibt und gleichzeitig die Einnahmen maximiert.
Übersetzt mit DeepL.com (kostenlose Version)
Apples 30% Kommission und ihre Auswirkungen
Der App Store erhebt standardmäßig eine Gebühr von 30 % auf alle bezahlten Apps und digitalen Güter, die über In-App-Käufe (IAP) verkauft werden. Bei einem App-Verkauf im Wert von 10 Dollar erhält der Entwickler beispielsweise nur 7 Dollar. Diese 30-prozentige „Apple-Steuer“ gilt auch für Abonnements, obwohl Apple sie für wiederkehrende Abonnements nach dem ersten Jahr auf 15 Prozent reduziert hat. Die Provision gilt weltweit, unabhängig davon, ob Ihre App als einmaliger Kauf oder als Abonnement verkauft wird. Für kleine Apps kann der Verlust von 30 % verheerend sein.
Die Apple-Provision ist für die Branche hoch (Branchenstandards liegen eher bei 10-20 % für die Zahlungsabwicklung). Tech-Berichterstatter verweisen auf Apples „suprakompetitive“ Gewinnspannen, und Entwickler haben sich lange über die Gebühr aufgeregt. Die Klage von Epic Games und der Druck der Regulierungsbehörden auf der ganzen Welt (EU, Japan, Südkorea) spiegeln diese Spannungen wider. Für viele Indie-Entwickler kann die Suche nach einem Weg, diese 15-30 % an den Verkäufen zu behalten, über Erfolg oder Misserfolg eines Projekts entscheiden.
Apples Programm für kleine Unternehmen (15%)
Um kleineren Entwicklern zu helfen, führte Apple im Januar 2021 das App Store Small Business Program (SBP) ein. Dieses Programm erlaubt es qualifizierten Entwicklern, nur eine 15%ige Provision auf Verkäufe zu zahlen. Die wichtigsten Bedingungen sind:
- Umsatzschwelle: Sie (und alle verknüpften Entwicklerkonten) müssen in den vorangegangenen 12 Monaten ≤ 1 Million US-Dollar an App-Store-Einnahmen (abzüglich Apples Provisionen und Steuern) erzielt haben und auch im laufenden Jahr unter 1 Million US-Dollar bleiben. Wenn Sie in einem Jahr 1 Million Dollar überschreiten, wird Ihr Satz für den Rest des Jahres auf 30 % zurückgesetzt, und Sie können sich erst dann wieder für 15 % qualifizieren, wenn Sie in einem späteren Jahr unter den Schwellenwert fallen.
- Anspruchsberechtigung: Fast alle App-Entwickler, die digitale Güter verkaufen, sind qualifiziert, wenn sie unter der Umsatzgrenze liegen. Das gilt auch für neue Entwickler, die noch keine Verkäufe getätigt haben (Neulinge erhalten sofort den 15 %igen Vorteil).
- Einschreibung: Um am SBP teilzunehmen, muss der Kontoinhaber Apples „Paid Apps“-Vereinbarung zustimmen und alle zugehörigen Entwicklerkonten in App Store Connect auflisten. Es fallen keine Gebühren an und es ist auch kein komplizierter Antrag erforderlich – Sie melden sich einfach über App Store Connect an, sobald Sie sich qualifiziert haben. Apple wendet dann 15 Tage nach der Anmeldung automatisch den 15 %igen Satz auf Ihre Verkäufe an.
Der SBP-Satz ist eine große Hilfe für Einzelentwickler und kleine Studios. Im Vergleich zu den üblichen 30 % verdoppelt die Zahlung von 15 % auf die ersten 1 Mio. US-Dollar Umsatz effektiv Ihre Einnahmen. (In der Apple-Pressemitteilung heißt es, dies gelte für „die große Mehrheit der Entwickler, die digitale Produkte verkaufen“). Der einzige Nachteil ist die Umsatzgrenze. Wenn Ihre App schnell über 1 Million Dollar hinauswächst, werden Sie wieder bei 30 % landen, es sei denn, Sie können den Umsatz aufteilen oder mehrere Konten verwenden.
Tabelle: Vergleich von Strategien zur Provisionseinsparung
| Strategy | Vorteile | Nachteile |
|---|---|---|
|
Apple In-App-Kauf – Small Biz Programm (15%)
|
Geringere Provision (15 % gegenüber 30 %) auf qualifizierte Umsätze- Nahtloser Kauffluss im Store, der von Apple abgewickelt wird (Zahlung, Betrug, Steuern)- Zugang zu Reichweite und Vertrauen im App Store |
Sie zahlen weiterhin eine Gebühr von 15 % auf alle In-App-Verkäufe – Sie müssen einen Umsatz von weniger als 1 Mio. USD/Jahr erzielen – Sie unterliegen den Prüfungs- und Rückerstattungsrichtlinien von Apple |
|
Apple In-App-Käufe – Standard (30%) |
Voller Zugang zum App Store, keine Einschränkungen für In-App-Inhalte/Modelle- Apple übernimmt die gesamte Zahlungsabwicklung, Sicherheit und Steuern |
Die hohe Provision von 30 % schmälert den Gewinn – Begrenzte Kontrolle über die UX der Kasse – Die Abonnementrate sinkt erst nach dem ersten Jahr eines Abonnenten auf 15 % (bei Abonnements) |
|
Externe Web-Zahlungen (Stripe, etc.) |
Entwickler erhalten bis zu 97 % des Umsatzes (Stripe nimmt 2,9 % + 0,30 $ im Vergleich zu 30 % bei Apple) – Volle Kontrolle über Kassenablauf, Preise und Werbeaktionen – Einheitliche Zahlungslösung für Web und Mobile (plattformübergreifende UX) |
Sie müssen Ihre eigene Zahlungsinfrastruktur aufbauen und pflegen (Handhabung von Rückbuchungen, Rückerstattungen, Betrug, Umsatzsteuer usw.) – Erforderliche PCI-Konformität und zusätzlicher Aufwand für den Kundensupport – Abhängig von Apples sich ändernden Richtlinien für externe Links (noch in der Entwicklung) |
|
Progressive Web-Anwendung (PWA) |
Kein App Store involviert – keine Apple-Gebühren für Transaktionen- Sofortige Updates (keine Überprüfungsverzögerung), funktioniert plattformübergreifend- Direkte Benutzerbeziehung und -analyse (E-Mail, Push usw.) |
Eingeschränkte iOS-Unterstützung (nur Safari-Browser; einige native Funktionen fehlen)- Nicht im App Store gelistet (die Entdeckung ist schwieriger; kein Suchverkehr im App Store)- Historisch begrenzte APIs (kürzlich fügte iOS PWA-Push-Benachrichtigungen in 16.4 hinzu, aber immer noch begrenzter als native)
|
Verwendung externer Web-Zahlungen (z. B. Stripe)
Das jüngste Gerichtsurteil im Fall Epic gegen Apple hat die Situation verändert. Im Mai 2025 wies ein US-Gericht Apple an, Entwickler nicht länger daran zu hindern, auf externe Kaufoptionen zu verlinken und keine Provisionen mehr für Verkäufe außerhalb der App zu verlangen. In der Praxis bedeutet dies:
Keine Apple-Gebühr für externe Verkäufe: Für jeden Kauf, der über eine Website oder eine Web-Kasse außerhalb der App getätigt wird, kann die Apple-Gebühr von 30 % (oder 15 %) nicht erhoben werden. Die Entwickler behalten 100 % dieser Einnahmen (abzüglich der Gebühren des Zahlungsdienstleisters).
Freiheit zur Verlinkung: Apple muss nun erlauben, dass Apps im amerikanischen App Store Schaltflächen oder Handlungsaufforderungen enthalten, die den Nutzer zu einer externen Zahlungsseite leiten. (Apple hat seine Richtlinien aktualisiert, um dies ausdrücklich zu berücksichtigen.) Wichtig ist, dass es Apple untersagt ist, ganzseitige Warnungen oder „Schreckensbildschirme“ aufzuerlegen, wenn ein Benutzer einem solchen Link folgt.
Technische Umsetzung: Daher können Sie einen Dienst wie Stripe integrieren, um Zahlungen im Internet abzuwickeln. In der Dokumentation von Stripe (und in der TechCrunch-Berichterstattung) wird der Ansatz erklärt: Ihre App enthält einen Link oder eine Schaltfläche, die Stripe Checkout in einer sicheren Webansicht oder einem Browser öffnet, der Nutzer schließt dort die Zahlung ab und kehrt dann zu Ihrer App zurück. In der Praxis generieren Sie eine einmalige Stripe Checkout-URL auf Ihrem Server (oder mithilfe des SDK von Stripe) und öffnen diese URL in der App. Nach der Zahlung verifizieren Sie sie in Ihrem Backend und schalten den Inhalt der App für den Benutzer frei.
Stripe hat sogar einen Leitfaden für iOS-Entwickler veröffentlicht, um dies einzurichten. TechCrunch berichtet, dass Stripe-CEO Michael Luo es als „große Neuigkeit“ bezeichnete, dass Entwickler nun „Zahlungen mit @stripe außerhalb ihrer App akzeptieren können, ohne iOS-App-Store-Provisionen.“ Die neuen Dokumente von Stripe zeigen, wie man Stripe Checkout innerhalb einer iOS-App verwenden kann, indem man die Kunden einfach auf eine sichere, von Stripe gehostete Zahlungsseite umleitet. Dadurch wird das In-App-System von Apple vollständig umgangen. Der Nachteil ist die Arbeit des Entwicklers: Sie müssen die gehostete Zahlungsseite und die Weblogik selbst erstellen und pflegen. Aber die Pauschalgebühr von Stripe (2,9 % + 0,30 $ pro Transaktion) ist viel niedriger als 30 %.
Beispiel: Wenn Sie ein digitales Produkt im Wert von 10 $ verkaufen, würde Apple normalerweise 3 $ (30 %) einnehmen und Ihnen 7 $ geben. Wenn Sie stattdessen Stripe verwenden, nimmt Apple 0 $ ein, Stripe nimmt etwa 0,59 $ ein, so dass Sie netto ~ 9,41 $ erhalten – mehr als 30 % mehr als bei IAP. Selbst im Vergleich zum 15%igen SBP-Satz kostet Stripe nur ~$0,59 im Vergleich zu Apples $1,50 – eine erhebliche Ersparnis.
Vorteile: Drastische Gebührensenkung (Sie behalten den Großteil der Einnahmen), volle Kontrolle über den Checkout-Flow (Branding, Angebote, A/B-Tests) und keine Notwendigkeit, auf App Review zu warten, um Preise oder Pläne zu ändern. Sie können Web- und Mobilverkäufe integrieren (so dass ein Nutzer sich auf Ihrer Website anmelden und Ihre iOS-App nahtlos freischalten kann).
Nachteile: Sie übernehmen alles, was früher Apple gemacht hat. Das bedeutet, dass Sie ein sicheres Zahlungssystem implementieren müssen: Kreditkartenverarbeitung, PCI-Compliance, Rückbuchungen, Erstattungen, Betrugsprävention und Erhebung von Umsatz- oder Mehrwertsteuern. Dies kann nicht trivial sein. RevenueCat warnt: „Abonnement-Teams sind es nicht gewohnt, die Zahlungsbeziehung mit dem Kunden direkt zu verwalten… Apple erledigt einen Großteil der schweren Arbeit hinter den Kulissen. Aber wenn man externe Zahlungen implementiert, kommen plötzlich neue Verantwortlichkeiten auf die Entwickler zu – Rückbuchungen, Rückerstattungen, Zahlungsbetrug, Zahlungsrückstände, Umsatzsteuer-Compliance – die Liste geht weiter“. Die Kosten für den Aufbau (oder das Outsourcing) der gesamten Infrastruktur können einen Teil der 15-30 % Gewinn ausgleichen, insbesondere bei sehr kleinen Anwendungen.
Eine weitere Überlegung: Benutzererfahrung und Vertrauen. Die Umleitung von Nutzern auf eine Web-Kasse kann sich weniger nahtlos anfühlen als das Apple-eigene Kaufformular. Ihre App muss klar angeben, wohin das Geld fließt (z. B. „Kauf auf OurSite.com“). Die Benutzer müssen sich möglicherweise zweimal anmelden oder haben mit kleineren Problemen zu kämpfen. Und natürlich müssen Sie sicherstellen, dass die Weiterleitung von der App zum Web nicht gegen die Apple-Regeln verstößt: Für US-Apps können Sie jetzt externe Links frei verwenden, sollten sich aber an den Geist der Richtlinien halten (keine ganzseitigen Pop-ups, Verwendung neutraler Hinweise). Nach den überarbeiteten App-Store-Regeln können Sie einen externen Link einfügen, ohne eine Sondergenehmigung von Apple zu benötigen, aber Sie sollten ihn deutlich kennzeichnen. Kurz gesagt, diese Methode ist jetzt unter iOS in den USA legal (und in der EU unter den alternativen Zahlungsbedingungen von Apple bereits erlaubt), aber sie erfordert eine sorgfältige Umsetzung.
Progressive Web Apps (PWAs)
Eine Progressive Web App (PWA) ist im Wesentlichen eine Website, die sich wie eine App verhält. Benutzer öffnen sie in ihrem Browser (oder fügen sie zu ihrem Startbildschirm hinzu), aber sie geht nicht durch den App Store. PWAs können offline arbeiten, Push-Benachrichtigungen senden (Safari auf iOS unterstützt dies jetzt ab iOS 16.4) und sich wie eine App verhalten. Der große Vorteil liegt auf der Hand: Kein App Store bedeutet keine Apple-Provision oder Verzögerungen bei der Überprüfung. Sie können die App sofort aktualisieren, indem Sie Ihre Website ändern.
PWAs haben bei Unternehmen, die die Beschränkungen des App Stores umgehen wollen, an Attraktivität gewonnen. Untersuchungen von Movement, einer auf PWAs spezialisierten Plattform, zeigen beispielsweise, dass nur ein kleiner Prozentsatz der Top-Entwickler auf App Stores angewiesen ist – viele erfolgreiche Apps leben ausschließlich im Web. Durch den Verzicht auf App-Store-Gebühren behalten diese Unternehmen 100 % der Einnahmen aus den Verkäufen (abgesehen von den Kosten für die Zahlungsabwicklung).
Vorteile: Eine PWA umgeht das Apple-Ökosystem vollständig, so dass alle Verkäufe frei von Apples Anteil sind. Sie haben die Kontrolle über das gesamte Nutzererlebnis und können jederzeit Aktualisierungen vornehmen. PWAs funktionieren außerdem auf allen Plattformen (iOS, Android, Desktop) über eine einzige Codebasis.
Nachteile: Auf iOS gibt es immer noch Einschränkungen. PWAs können nur in der Safari-Engine ausgeführt werden (keine Chrome- oder andere Browser-Engine auf iOS). Bis vor kurzem konnten sie keine Push-Benachrichtigungen senden oder sich im Hintergrund aktualisieren, aber Apple hat die Unterstützung schrittweise verbessert (z. B. wurden mit iOS 16.4 PWA-Push-Benachrichtigungen hinzugefügt). Dennoch funktionieren einige Geräteintegrationen (wie Bluetooth, Apple Pay im Web, Home Screen Badges oder bestimmte APIs) möglicherweise nicht so gut in einer PWA. Außerdem werden PWAs nicht im App Store aufgeführt, so dass Sie nicht über die App-Suche gefunden werden. Sie müssen die Nutzer auf Ihre Website leiten (über Marketing, QR-Codes usw.). Und unter iOS gibt es keine „Installationsaufforderung“ – Nutzer müssen die PWA manuell über Safari zu ihrem Startbildschirm hinzufügen. Aus diesen Gründen eignen sich PWAs oft besser für inhaltsorientierte Anwendungen (Nachrichten, Publikationen, Dienste) als für hochgradig interaktive Spiele oder Dienstprogramme, die auf eine tiefe Hardwareintegration angewiesen sind.
Kurz gesagt, eine PWA ist eine Möglichkeit, den App Store ganz zu umgehen. Dies ist ein gangbarer Weg, wenn die Funktionalität Ihrer App vollständig im Web genutzt werden kann und Sie Nutzer außerhalb des Apple-Marktplatzes ansprechen können. Es erfordert zwar Investitionen in die Entwicklung von Web-Apps, aber es kann sich auszahlen, da Sie die 15-30 % Kürzung einsparen und die Entwicklung beschleunigen können. (Bemerkenswert ist, dass Apple PWAs nicht blockieren kann, und sogar die Bedenken in der EU wurden zurückgenommen).
Webbasierte Abonnements und „Reader“ Apps
Eine weitere gängige Strategie, insbesondere für Inhalts-Apps (Zeitschriften, Nachrichten, Musik, Video usw.), ist der Verkauf von Abonnements direkt auf einer Website und nicht über die App. Der Nutzer meldet sich dann bei Ihrer iOS-App an, um auf die gekauften Inhalte zuzugreifen. Sie bauen also ein Mitgliedschaftssystem auf Ihrer Webdomäne auf, und die App wird lediglich zu einem Client. So funktionieren Dienste wie Netflix, Spotify und Kindle (sie zwingen die Nutzer nicht zum Kauf über Apples IAP).
Realview Digital, eine Verlagsplattform, erklärt, dass durch den Verkauf von Abonnements auf Ihrer Website „alle Einnahmen bei Ihnen verbleiben“ und „der Abonnent sich überall und mit jedem Gerät anmelden kann“. Dieser Ansatz hat große Vorteile: 100 % der Abonnementeinnahmen gehen an Sie, und Sie erhalten vollständige Nutzerdaten und plattformübergreifende Flexibilität. Sie können sogar Web- und Printangebote oder zusätzliche Vergünstigungen anbieten, um die Nutzer zu einem Abonnement außerhalb der App zu bewegen.
Der Haken an der Sache sind die Regeln von Apple: Direkte Links zu externen Kaufseiten waren in der Vergangenheit verboten. Sie können in Ihrer App keine Schaltfläche mit der Aufschrift „Abonnieren Sie auf unserer Website“ einfügen – das würde gegen die alten Richtlinien verstoßen. Stattdessen hat Apple eine begrenzte Ausnahme zugelassen: „Leser“-Apps (die sich auf Bücher, Zeitschriften, Video, Audio usw. konzentrieren) können nun die Berechtigung für externe Links beantragen. Wird diese gewährt, kann die App einen Link zur Kontoverwaltung auf Ihrer Website enthalten (z. B. „Konto verwalten“ oder „Auf Website abonnieren“). In der Apple-Dokumentation heißt es, dass Reader-Apps in erster Linie Inhalte wie Zeitschriften oder Audiodateien bereitstellen, eine Anmeldung ermöglichen und keine IAP in iOS anbieten müssen, wenn sie diesen Link verwenden. Im Wesentlichen können Reader-Apps die Nutzer freier nach draußen leiten.
Wenn Ihre App nicht in die Kategorie „Reader“ fällt (z. B. ein Produktivitäts-Tool oder ein Spiel), verbietet Apple weiterhin offene Links. Sie können jedoch im Klartext erwähnen, dass die Nutzer sich auf Ihrer Website anmelden können, sofern Sie auch einen In-App-Kauf anbieten. Realview rät, dass Sie keinen „großen Button“ haben dürfen, der die Nutzer direkt zu einer Abonnement-Website führt, aber Sie können in Ihrer App erwähnen, dass eine externe Option existiert. Apple toleriert diese Art der passiven Weiterleitung an versierte Nutzer, die von sich aus ins Internet gehen.
In der Praxis verzichten viele Entwickler ganz auf den In-App-Verkauf und verlassen sich auf den Trichter ihrer Website. Nutzer, die die App heruntergeladen haben, wissen (aus dem Marketing), dass sie sich auf der Website anmelden müssen. Die App enthält dann nur einen „Login“-Bildschirm. Dies entspricht technisch gesehen den Apple-Regeln (es gibt keinen In-App-Kauf-Link) und ist inzwischen üblich. Es ist eine 100%ig legale Strategie: Apple kann die Nutzer nicht daran hindern, Ihre Website außerhalb der App zu besuchen, um sich anzumelden. Aber es bedeutet, dass die Bequemlichkeit von IAP mit einem Klick verloren geht.
Vorteile: Vollständige Einnahmen und Besitz der Nutzer beim Verkauf auf Ihrer eigenen Website. Sie sind nicht durch die Preisstaffelung von Apple eingeschränkt und bauen eine E-Mail-Kundenliste auf (die Sie mit Apple IAP nicht erhalten). Für Unternehmen, die Inhalte anbieten, bietet dies auch einen geräteübergreifenden Zugang (Lesen im Web, in der iOS-App usw.). Wenn Sie sich als „Leser“-App qualifizieren, erhalten Sie eine offizielle Berechtigung zum Verlinken.
Nachteile: Sie tragen die gesamte Abrechnungskomplexität (Verwaltung der Abonnements, Einhaltung der Zahlungsbedingungen, Steuern usw.). Sie müssen Nutzer außerhalb des App Store akquirieren (über Webmarketing, soziale Medien usw.). Und bis vor kurzem konnte man nicht direkt in der App verlinken, was zusätzlichen Aufwand für die Nutzer bedeutete. Selbst mit der Berechtigung zur Verknüpfung von Lesern verlieren Sie den Impulskaufcharakter von IAP. Darüber hinaus haben einige Entwickler berichtet, dass Apple diese Abläufe immer noch kritisieren kann – zum Beispiel, indem es Sie zwingt, eine IAP-Option beizubehalten, oder indem es Apps ablehnt, die zu aggressiv umleiten. Diese Methode erfordert also eine sorgfältige Einhaltung und Klarheit.
Rechtliche und Compliance-Implikationen
Jede Strategie zur Einsparung von Provisionen ist mit rechtlichen und politischen Überlegungen verbunden:
Apple-Richtlinien: Sie müssen stets die App Store Review Guidelines von Apple beachten. Die Regeln für externe Zahlungen haben sich weiterentwickelt. Seit Mai 2025 (USA) erlauben die Richtlinien von Apple ausdrücklich „Schaltflächen, externe Links oder andere Handlungsaufforderungen“ für Kaufoptionen in US-amerikanischen Apps. Mit anderen Worten: US-Apps können jetzt frei auf externe Webkäufe verweisen. In der EU wurden ähnliche Erlaubnisse bereits früher im Rahmen des EU-Gesetzes über digitale Märkte eingeführt. Apple stellt sogar spezielle Berechtigungen und APIs (wie die StoreKit External Purchase Entitlement) für Apps bereit, die externe Zahlungsanbieter nutzen möchten. Stellen Sie sicher, dass Sie diese offiziellen Mechanismen übernehmen – in der EU müssen Sie beispielsweise Apples Alternative Terms Addendum akzeptieren und die StoreKit-APIs verwenden, wenn Sie Zahlungen außerhalb von IAP abwickeln.
Offenlegung und User Flow: Seien Sie auch bei rechtlicher Erlaubnis transparent. Vermeiden Sie trügerische UX. Die neue einstweilige Verfügung verbietet es Apple beispielsweise, ganzseitige Warnungen anzuzeigen, die Nutzer fälschlicherweise von externen Kauflinks abschrecken. Apple kann Ihnen auch nicht mehr verbieten, alternative Zahlungsmethoden zu erwähnen. Sie sollten jedoch weiterhin alle externen Zahlungsströme deutlich kennzeichnen (z. B. „Sie werden zum Abschluss des Kaufs zu example.com weitergeleitet“) und sicherstellen, dass die Absicht des Nutzers respektiert wird. Führen Sie keine automatische Weiterleitung ohne Benutzeraktion durch.
Transaktionskonformität: Wenn Sie Web-Zahlungen akzeptieren, müssen Sie die Finanzvorschriften einhalten. Dazu gehören die Implementierung von PCI-DSS, wenn Sie Kreditkartendaten speichern oder übertragen, die Einhaltung von GDPR oder CCPA für personenbezogene Daten und die korrekte Handhabung von Steuern (Apple und Stripe haben früher die Steuern für IAP übernommen, aber jetzt sind Sie selbst dafür verantwortlich). Das EU-Recht kann zum Beispiel verlangen, dass Sie die Mehrwertsteuer auf digitale Dienstleistungen abführen. Sie brauchen auf Ihrer Website Nutzungsbedingungen und Datenschutzrichtlinien, um Transaktionen abzudecken. In den EU-Richtlinien von Apple heißt es sogar ausdrücklich, dass Sie externe Käufe über die neue API melden und Vorlagen zur Vermeidung von Betrug befolgen müssen. In der Praxis kann die Zusammenarbeit mit einem vertrauenswürdigen Zahlungsdienstleister wie Stripe oder Paddle vieles davon vereinfachen, aber Sie sollten sich dennoch über die Pflichten im Klaren sein.
Überprüfungsrisiko: Denken Sie daran, dass Apple Ihre App immer noch überprüft. Wenn Sie Zahlungen falsch abwickeln oder das System zu betrügen scheinen, könnte Apple Ihre App ablehnen. Wenn Sie z. B. dasselbe Produkt sowohl über IAP als auch billiger auf Ihrer Website verkaufen, könnte dies als Anreiz für Käufe außerhalb des Ladens angesehen werden (obwohl die neuen Regeln dies für US-Apps lockern). Um auf der sicheren Seite zu sein, behalten viele Entwickler beide Optionen bei, stellen aber sicher, dass sie bei der Verwendung von externen Zahlungen nicht gegen eine kategoriespezifische Regel verstoßen. So können beispielsweise Nicht-Leser-Apps in den USA jetzt ganz auf IAP verzichten, aber einige Entwickler berichten, dass der App-Überprüfungsprozess noch nicht abgeschlossen ist, so dass eine gewisse Unsicherheit besteht. Am besten ist es, gründlich zu testen und zu dokumentieren, dass Sie die aktualisierten Regeln einhalten (z. B. die Verwendung von StoreKit-APIs für externe Käufe in der EU oder die Aktivierung der neuen Verknüpfung für iOS als zulässig).
Laufende Beobachtung: Apple geht gegen das Epic-Urteil in Berufung, so dass sich die Richtlinien erneut ändern können. Es ist ratsam, sich über die Apple Developer News auf dem Laufenden zu halten und auf Anpassungen vorbereitet zu sein. Behalten Sie auch andere Änderungen im Auge (z. B. die 3 %ige „Zahlungsbearbeitungsgebühr“ von Apple in der EU für die Nutzung des Apple-Zahlungssystems). Generell sollten Sie bei jeder Umgehungslösung die Erklärungen von Apple und die Community-Foren im Auge behalten, um eventuelle Probleme zu erkennen.
Schlussfolgerung
Für unabhängige iOS-Entwickler neigt sich die Zeit der unumstrittenen 30 % App-Store-Provision dem Ende zu. Apples Small Business Program hat die Gebühren für berechtigte Entwickler bereits auf 15 % gesenkt, und durch Gerichtsbeschlüsse ist nun das Verlinken zu externen Zahlungsseiten erlaubt – ohne Apples Anteil zahlen zu müssen. Wer Stripe (oder ähnliche Anbieter) nutzt, um Käufe auf das Web umzuleiten, kann bis zu 27 % Gebühren sparen, muss dafür aber auch den Mehraufwand stemmen. Der Aufbau einer Progressive Web App oder das Lenken der Nutzer auf die eigene Website für Abos kann den App Store komplett umgehen (Realview empfiehlt im Bereich digitales Publishing den Direktvertrieb über das Web, um „den gesamten Umsatz zu behalten“). In der EU erlauben neue Regelungen bereits die Nutzung alternativer Zahlungsanbieter – mit nur geringer Apple-Gebühr (3–17 %).
Jede Option bringt Vor- und Nachteile mit sich. Das Small Business Program ist am einfachsten, wenn man die Voraussetzungen erfüllt; externe Zahlungen bringen den höchsten Gewinn, erfordern aber technischen Aufwand; PWAs und webbasierte Modelle umgehen den App Store, verlieren dafür aber an Sichtbarkeit. Entscheidend ist, den Ansatz zu wählen, der zu eurem Produkt und den Kapazitäten eures Teams passt. Wichtig ist die korrekte Umsetzung: Nutzt Apples offizielle Entitlements, haltet die aktualisierten App-Store-Richtlinien ein und beachtet rechtliche Vorgaben wie Steuern und Datenschutz.
Viele Entwickler kombinieren diese Ansätze – etwa indem sie für einen Teil der Nutzer In-App-Käufe über das SBP (15 %) anbieten und für andere einen Login-Flow über das Web bereitstellen oder gleichzeitig eine App und eine ergänzende PWA pflegen. Die Rahmenbedingungen ändern sich derzeit rasant – bleibt also informiert und testet sorgfältig. So könnt ihr eure Einnahmen maximieren, dabei Apples Regeln einhalten und gleichzeitig eure Nutzer zufriedenstellen.
Quellen: Für diesen Leitfaden wurden offizielle Apple-Dokumente, Nachrichtenartikel, Stripe-Informationen, Entwickleranalysen und Branchenblogs konsultiert.
DE 
EN 
FR 
ES