Wann Sie Push-Benachrichtigungen anfragen sollten – und wann nicht

Die meisten Apps fragen die Berechtigung für Push-Benachrichtigungen auf dem ersten Bildschirm ab, den der Nutzer sieht – noch bevor er irgendetwas getan hat, worüber es sich zu benachrichtigen lohnte. Unter iOS ist dieser eine Dialog eine einmalige Gelegenheit: Lehnt der Nutzer ab, führt der einzige Weg zurück über einen Umweg in die Einstellungen, den so gut wie niemand antritt. Wir haben beobachtet, wie die Opt-in-Raten in Client-Apps von unter 30 % auf über 70 % gestiegen sind – allein dadurch, dass der Zeitpunkt geändert wurde, zu dem der OS-Dialog erscheint. Texte, Icon und die App selbst blieben unverändert.

Wenn Sie den Onboarding-Flow einer mobilen App aufbauen oder überarbeiten, verdient das Timing der Berechtigungsanfrage genauso viel gestalterische Aufmerksamkeit wie das Anmeldeformular.

Warum der native Dialog eine einmalig einsetzbare Ressource ist

iOS zeigt den systemseitigen Berechtigungsdialog genau einmal pro App-Installation. Es gibt kein „Später fragen": Tippt der Nutzer auf Nicht erlauben, bleibt als einziger Weg Linking.openSettings() – vorausgesetzt, der Nutzer ist bereit, sich durch iOS-Einstellungen > Mitteilungen > Ihre App zu navigieren. Android war historisch gesehen großzügiger (vor Version 13 war die Berechtigung implizit; ab Version 13 ist eine explizite Laufzeitanfrage erforderlich, ein erneutes Abfragen ist unter bestimmten Bedingungen jedoch noch möglich). Teams, die Permission-Flows primär gegen Android-Verhalten entwickeln, erleben deshalb oft eine böse Überraschung beim iOS-Release.

Betrachten Sie den nativen Dialog als eine Ressource, die Sie genau einmal einsetzen. Alles davor sollte darauf ausgerichtet sein, diesen einen Versuch so gut wie möglich vorzubereiten.

Das Soft-Ask-Muster

Die Lösung ist ein Pre-Permission-Screen, den Sie vollständig kontrollieren – ein normales In-App-UI-Element, kein Systemdialog –, das den Mehrwert von Benachrichtigungen erklärt, bevor der OS-Dialog erscheint:

• „Erhalten Sie eine Benachrichtigung, wenn Ihre Bestellung versendet wird" – mit einem Glocken-Icon und zwei Buttons: Benachrichtigungen aktivieren und Jetzt nicht
• Nur ein Tipp auf Benachrichtigungen aktivieren löst die echte OS-Berechtigungsanfrage aus
• Jetzt nicht schließt den Screen, ohne den OS-seitigen Status zu berühren – der echte Dialog steht also weiterhin zur Verfügung

Das ist entscheidend: Eine Ablehnung beim Soft-Ask kostet nichts. Sie können ihn in der nächsten Session erneut zeigen, nach einer anderen Aktion oder mit anderem Text. Eine Ablehnung beim echten OS-Dialog unter iOS ist hingegen so gut wie endgültig.

```tsx import * as Notifications from 'expo-notifications';

async function requestPushPermission() { const { status: existing } = await Notifications.getPermissionsAsync(); if (existing === 'granted') return true;

const { status } = await Notifications.requestPermissionsAsync(); return status === 'granted'; }

// Only call requestPushPermission() after the user taps // "Enable Notifications" on your own in-app screen. ```

Timing: Kontextuell schlägt chronologisch

„Tag 3" oder „nach dem Onboarding" ist chronologisches Timing – einfach umzusetzen und genau deshalb fragen die meisten Apps bereits beim Start, in einem festen Schritt. Kontextuelles Timing knüpft die Anfrage an einen Moment, in dem der Mehrwert offensichtlich ist:

• E-Commerce: nach der ersten Bestellung, nicht davor („Verfolgen Sie Ihre Lieferung")
• SaaS/Dashboard-Apps: nachdem der Nutzer das erste Objekt erstellt hat, das es zu überwachen gilt – ein Projekt, einen Alert, einen Report
• Social/Messaging: nach der ersten gesendeten oder empfangenen Nachricht, nicht beim Anlegen des Accounts
• Buchung/Terminplanung: direkt nach einer bestätigten Buchung („Wir erinnern Sie kurz vorher")

Wenn Ihre App keinen offensichtlichen „Moment" bietet, erfinden Sie keinen. Eine generische Anfrage in Session 2 oder 3 schneidet trotzdem besser ab als in Session 1, weil der Nutzer zumindest einen ersten Eindruck vom Produkt gewonnen hat.

Plattformunterschiede, die naive Implementierungen brechen

• iOS: ein Versuch pro Installation (bis der Nutzer die App löscht und neu installiert, was den Berechtigungsstatus zurücksetzt). Die provisorische Autorisierung (provisional: true in den Request-Optionen) stellt Benachrichtigungen still ins Notification Center zu, ohne einen Dialog anzuzeigen – sinnvoll für risikoarme, volumenstarke Benachrichtigungstypen, bei denen Sie lieber Vertrauen aufbauen, bevor Sie aktiv anfragen.
• Android 13+: POST_NOTIFICATIONS ist eine Laufzeitberechtigung wie Kamera oder Standort und wird auf dieselbe Weise angefragt. Unterhalb von Android 13 sind Benachrichtigungen standardmäßig bei der Installation erteilt – wer ausschließlich auf neueren Android-Geräten testet, übersieht Bugs, die für einen erheblichen Teil der Android-Installationsbasis auftreten.
• Background-/Foreground-Status: Einige Permission-APIs verhalten sich unterschiedlich, je nachdem ob die Anfrage unmittelbar beim Mount oder nach einer useEffect-Verzögerung erfolgt. Testen Sie das tatsächliche Timing, das Sie ausliefern wollen – nicht nur den API-Aufruf isoliert.

Dies ist einer der Bereiche, in denen React Native vs. Flutter weniger relevant ist, als man erwarten würde. Beide kapseln dasselbe zugrunde liegende OS-Berechtigungsmodell – und beide bestrafen Sie gleichermaßen, wenn Sie zu früh anfragen.

Erst messen, dann optimieren

Ohne Daten lässt sich das Timing von Berechtigungsanfragen nicht sinnvoll anpassen. Erfassen Sie mindestens:

• Soft-Ask angezeigt → Soft-Ask akzeptiert (Ihr In-App-Funnel)
• Soft-Ask akzeptiert → OS-Berechtigung erteilt (was der OS-Dialog selbst kostet)
• Zeit bis zur ersten empfangenen Benachrichtigung (ein Proxy dafür, ob die Benachrichtigung nach der Erteilung tatsächlich nützlich ist)

Ohne diese separat erfassten Events verbirgt eine einzelne „Opt-in-Rate" als Zahl, wo der Abbruch stattfindet: im Text, im Timing oder im OS-Dialog selbst – drei grundlegend verschiedene Ansatzpunkte.

Eine kompakte Checkliste

• Den OS-Berechtigungsdialog niemals beim ersten App-Start oder aus einem generischen Onboarding-Schritt heraus auslösen
• Einen Soft-Ask-Screen vollständig selbst gestalten, mit einem Text, der an einen konkreten Mehrwert geknüpft ist
• Den Soft-Ask nach einer kontextuellen Aktion auslösen, nicht nach einem festen Tag oder Schritt-Zähler
• iOS' One-Shot-Verhalten explizit berücksichtigen: Ablehnung als (nahezu) endgültig behandeln, nach einer Ablehnung einen Deep Link zu den Einstellungen anbieten statt erneut zu fragen
• Speziell auf Android-13+-Geräten testen; das Verhalten älterer Versionen nicht als Standard annehmen
• Jeden Funnel-Schritt separat erfassen, bevor Änderungen vorgenommen werden

Solche Details werden leicht übersprungen, wenn der Launchtermin näher rückt – dabei ist es günstig, es von Anfang an richtig zu bauen, und teuer, es nachzurüsten, wenn die Installationsbasis den falschen Dialog bereits gesehen und abgelehnt hat. Wenn Sie einen neuen Mobile-Build planen oder einen bestehenden hinsichtlich Performance und Onboarding prüfen, sprechen Sie uns an.