App monetarisieren 2026: Abos, Einmalkäufe, Werbung oder kostenpflichtige Downloads

Wer eine App erfolgreich monetarisieren will, beginnt mit einer Frage: Welchen Nutzen hat eine Person davon, und wie oft? Ein Cloud-Service, ein Offline-Tool und ein Casual Game haben unterschiedliche Kosten und Nutzungsmuster, also brauchen sie nicht dieselbe Paywall. Wählen Sie zuerst das Modell. Prüfen Sie dann die Zahlungsregeln der Stores und die Gebühren für 2026, denn beides zusammen entscheidet, wie Sie abrechnen dürfen und was Ihnen bleibt.

Welches Monetarisierungsmodell passt zu Ihrer App?

Wählen Sie das Modell, das dazu passt, wie oft Nutzer einen Nutzen haben und wie viel es Sie kostet, jeden einzelnen Nutzer zu bedienen. Jedes der folgenden Modelle passt zu einer anderen Art von Produkt.

Ein Hybridmodell kann funktionieren, aber jedes zusätzliche Modell ist eine weitere Regel, die Sie erklären müssen, und weitere Kaufzustände, die Sie testen müssen. Beginnen Sie mit dem kleinsten Modell, das Sie klar erklären können. „Kostenlos testen, einmal zahlen zum Exportieren“ versteht man leichter als Credits, Abos und Werbung auf einmal.

Wann lohnt sich ein Abo, und was verlangt Apple?

Ein Abo lohnt sich, wenn die App fortlaufend Nutzen liefert. Apples Guideline 3.1.2(a) besagt, dass automatisch verlängerte Abos „dem Kunden fortlaufenden Nutzen bieten müssen“ und dass der Zeitraum „mindestens sieben Tage dauern und auf allen Geräten des Nutzers verfügbar sein muss“.

Den bestehenden Einstellungsbildschirm hinter einen Monatspreis zu stellen, erfüllt diese Anforderung nicht. Gut passen zuverlässige Synchronisierung, neue Inhalte, Cloud-Verarbeitung oder ein gepflegter Service. Wenn Sie eine bestehende Bezahl-App auf Abos umstellen, sollten Sie laut derselben Guideline „bestehenden Nutzern nicht die Kernfunktionen wegnehmen, für die sie bereits bezahlt haben“.

Vor dem Kauf verlangt Guideline 3.1.2(c), dass Sie „klar beschreiben, was der Nutzer für den Preis bekommt“. Apples Seite zu Abos listet auf, was der Anmeldebildschirm braucht: Name und Laufzeit des Abos, den Leistungsumfang, einen gut sichtbaren vollständigen Verlängerungspreis, eine Möglichkeit zum Anmelden oder Wiederherstellen von Käufen sowie Links zu Ihren Nutzungsbedingungen und Ihrer Datenschutzerklärung. Testen Sie Verlängerung, Kündigung, Ablauf und Wiederherstellung. Wer heute kündigt, sollte bis zum Ende des bezahlten Zeitraums Zugriff behalten.

Wann passt ein Einmalkauf oder ein kostenpflichtiger Download besser?

Ein Einmalkauf passt zu einem in sich geschlossenen Tool, dessen Kosten nicht mit der Nutzung wachsen, etwa einem Offline-Editor oder einem Utility, das auf dem Gerät läuft. Schlecht passt er, wenn Sie für eine einzige Zahlung auf unbestimmte Zeit teure KI-Verarbeitung, Speicherplatz oder manuellen Support versprechen.

Unter iOS können Sie auch ohne Abo eine Testphase anbieten. Guideline 3.1.1 erlaubt einen nicht verbrauchbaren In-App-Kauf in Preisstufe 0 mit dem Namen „XX-day Trial“. Vor Beginn der Testphase müssen Sie angeben, wie lange sie dauert, was danach gesperrt wird und was der volle Zugriff kostet. Wenn Sie abgerechnete Leistungen als verbrauchbare Credits neben einer einmaligen Freischaltung verkaufen, denken Sie daran, dass per In-App-Kauf erworbene Credits „nicht verfallen dürfen“. Werben Sie nicht mit „unbegrenzt“, um dann eine harte Obergrenze auf einer Support-Seite zu verstecken.

Ist Werbung ein guter Weg, eine kleine App zu monetarisieren?

Werbung kann eine kostenlose App nur finanzieren, wenn die Nutzung genug Impressionen erzeugt. Bei einem kleinen oder Nischenpublikum decken die Werbeeinnahmen womöglich nicht einmal den Datenschutzaufwand und den langsameren App-Start, die ein Werbe-SDK mit sich bringt.

Messen Sie, ob Werbeplatzierungen die Kernaufgabe beeinträchtigen. In einem schnellen Utility kann eine Interstitial-Anzeige vor dem Ergebnis mehr an verlorenen Nutzern kosten, als sie einbringt. Ein werbefreies Upgrade ist ein digitaler Kauf: Googles Zahlungsrichtlinie nennt „eine werbefreie Version einer App“ ausdrücklich als Premium-Funktion, die über Play Billing laufen muss. Werbe-SDKs erheben außerdem Daten, also aktualisieren Sie Ihre Datenschutzangaben. Unser SDK-Audit für Datenschutzlabels führt Sie durch diese Prüfung.

Wie viel behalten Apple und Google 2026 vom App-Umsatz ein?

Stand Oktober 2026 behält Apple bei Mitgliedern des Small Business Program sowie bei Abos nach einem Jahr bezahlter Laufzeit 15 % ein. In den USA, im Vereinigten Königreich und im EWR berechnet Google Play auf Abos, die über Play Billing bezahlt werden, 10 % Servicegebühr plus 5 % Abrechnungsgebühr.

Laut Googles Seite zu Servicegebühren gilt die neue Struktur seit dem 30. Juni 2026 in den USA, im EWR und im Vereinigten Königreich sowie seit dem 30. September 2026 in Australien und Japan. In diesen Regionen fällt die Abrechnungsgebühr von 5 % nur auf Käufe über Google Play Billing an. Andere Märkte behalten die bisherigen Sätze, bis die Änderung sie erreicht.

Apples Small Business Program gilt für Entwickler mit bis zu 1 Million $ Erlösen im vorangegangenen Kalenderjahr sowie für Entwickler, die neu im App Store sind. Kostenlose Testphasen zählen nicht zum Jahr bezahlter Laufzeit, das für Apples Abo-Satz von 85 % nötig ist. Die Gebühren hängen vom Programm und von der Transaktion ab. Erstellen Sie Prognosen deshalb auf Basis Ihrer tatsächlichen Kontokonditionen statt mit einem einzigen Prozentsatz.

Wann dürfen Sie einen eigenen Zahlungslink statt des In-App-Kaufs nutzen?

Im US-Storefront von Apple dürfen Apps inzwischen Buttons, externe Links oder andere Handlungsaufforderungen enthalten, die zu anderen Kaufmethoden führen. Anderswo müssen digitale Funktionen per In-App-Kauf verkauft werden, sofern kein regionsspezifisches Entitlement und keine der aufgeführten Ausnahmen greift.

• Apple außerhalb der USA: Guideline 3.1.1(a) verlangt ein StoreKit External Purchase Link Entitlement, das nur in bestimmten Storefronts und auf bestimmten Plattformen verfügbar ist.
• Apple, physische Waren: Laut Guideline 3.1.3(e) müssen physische Waren oder Dienstleistungen, die außerhalb der App genutzt werden, mit anderen Zahlungsmethoden als dem In-App-Kauf bezahlt werden.
• Apple, Live-Services im Eins-zu-eins-Format: Nach 3.1.3(d) dürfen persönliche Echtzeit-Services zwischen zwei Personen, etwa Nachhilfe, andere Zahlungsmethoden nutzen. Services für wenige oder viele Teilnehmer gleichzeitig müssen den In-App-Kauf verwenden.
• Google Play: Digitale Güter laufen über Play Billing, es sei denn, Sie nehmen in einem berechtigten Land an einem Programm für alternative Abrechnung oder externe Angebote teil. Physische Waren und physische Dienstleistungen dürfen nicht über Play Billing abgerechnet werden.

Welche Monetarisierungsfehler haben schon zu Ablehnungen geführt?

Die häufigste zahlungsbezogene Ablehnung: kostenpflichtige Funktionen werden über etwas anderes als das Kaufsystem des Stores freigeschaltet. Entwickler versuchen oft, den Store mit Codes oder Web-Käufen zu umgehen.

In einem Thread in den Apple Developer Forums von 2019 verkaufte ein Entwickler eines Outdoor-Escape-Games Spielcodes auf seiner Website und über Partner. Nutzer gaben die Codes anschließend in der App ein. Das Update wurde nach „Guideline 3.1.1 - Business - Payments - In-App Purchase“ abgelehnt, weil die App „Nutzern erlaubt, zusätzliche Inhalte durch den Kauf eines Codes freizuschalten“. Der Entwickler berief sich auf 3.1.3(b). In den Antworten wurde darauf hingewiesen, dass auch bei plattformübergreifendem Zugriff dieselben Artikel „als In-App-Käufe in der App verfügbar“ sein müssen.

In einem Thread vom Januar 2025 nutzte ein Entwickler eigene Partner-Promocodes, um das günstigere von zwei gültigen In-App-Kauf-Produkten anzuzeigen. Apple lehnte ab, weil „die App einen Promocode verwendet, um kostenpflichtige Funktionen freizuschalten oder zu aktivieren“. Der Einspruch wurde mit folgendem Hinweis abgewiesen: „Wenn Sie in der App vergünstigte Abos anbieten möchten, verwenden Sie einen von Apple unterstützten Angebotscode.“

Beide Fälle lehren dasselbe. Für Apple spielt es keine Rolle, ob Ihr Code Inhalte direkt freischaltet oder nur den Preis ändert. Wenn irgendetwas außerhalb von StoreKit darüber entscheidet, wer kostenpflichtige Funktionen erhält, müssen Sie mit einer Ablehnung nach 3.1.1 rechnen.

Woran erkennen Sie, ob Ihre Monetarisierung funktioniert?

Messen Sie jeweils nur eine Änderung, angefangen bei der Aktivierung bis hin zu gehaltenem, nicht erstattetem Umsatz. Eine höhere Conversion beim Erstkauf ist kein Erfolg, wenn mehr Menschen Erstattungen verlangen oder ihr Abo nicht verlängern.

Ein Beispiel: „Nachdem Nutzer ihren ersten erfolgreichen Export abgeschlossen haben, zeigen wir die kostenpflichtige Exportoption mit einer klaren Erklärung.“ Legen Sie die Kennzahl (Kauf-Conversion und Erstattungen innerhalb von 30 Tagen) und den Zeitraum fest, bevor Sie etwas ändern. Eine winzige Stichprobe rechtfertigt keine selbstsicheren Schlüsse zur Preisgestaltung. Gehen Sie vor dem Release der kostenpflichtigen Version diese Checkliste durch:

1. Stellen Sie sicher, dass neue Nutzer den nützlichen Teil der App erreichen, bevor sie die Paywall sehen.
2. Zeigen Sie Preis, Abrechnungszeitraum und Leistungsumfang in verständlicher Sprache.
3. Testen Sie erfolgreiche, ausstehende, fehlgeschlagene, erstattete und wiederhergestellte Käufe in einem Release-Build.
4. Prüfen Sie, dass Berechtigungen eine Neuinstallation überstehen und auf allen Geräten des Nutzers verfügbar sind.
5. Geben Sie dem App Review einen funktionierenden Weg zu jeder kostenpflichtigen Funktion, mit Demo-Konto, falls ein Login nötig ist.
6. Verfolgen Sie bei Abos Verlängerungen und Abwanderung nach Kohorten.

Wenn Käufe während des Reviews nicht funktionieren, hilft der Testplan für Release-Builds zu Guideline 2.1 bei der Behebung. Die Anleitung zum Demo-Konto für das Review zeigt, wie Sie Prüfern Zugang geben, und die Checkliste für die App-Store-Einreichung deckt den Rest des Releases ab. Wenn Sie den Monetarisierungsablauf planen möchten, bevor Sie ihn bauen, sehen Sie sich unsere Leistungen an.