So fügst du deiner App Benachrichtigungen hinzu: In-App, E-Mail und Push

Um einer Web-App Benachrichtigungen hinzuzufügen, fang mit In-App-Benachrichtigungen an: einer Benachrichtigungstabelle in deiner Datenbank und einem Glockensymbol, das ungelesene Einträge anzeigt. E-Mail fügst du für Dinge hinzu, die Menschen wissen müssen, wenn sie unterwegs sind, über einen E-Mail-Anbieter. Web-Push nimmst du nur dazu, wenn zeitnahe Hinweise wirklich wichtig sind, denn er braucht einen Service Worker, die Zustimmung des Nutzers und auf dem iPhone die auf dem Home-Bildschirm gespeicherte App. Welche Kanäle du auch nutzt: Erzeuge jede Benachrichtigung an einer zentralen Stelle auf dem Server und lass Nutzer wählen, was sie erhalten.

Dieser Leitfaden vergleicht die Kanäle, zeigt eine einfache Architektur und enthält Prompts für einen KI-App-Baukasten.

Die wichtigsten Kanäle im Vergleich

Die meisten Apps brauchen In-App plus E-Mail. Push und SMS lohnen sich, wenn das Timing wirklich zählt, etwa bei einer Buchungserinnerung oder einer Bestellung, die abholbereit ist.

So fügt sich ein Benachrichtigungssystem zusammen

Halte es einfach und zentral:

1. Etwas passiert. Ein Kommentar wird gepostet, eine Zahlung schlägt fehl, ein Termin steht morgen an.
2. Dein Server ruft eine Funktion auf, zum Beispiel notify(user, type, data).
3. Diese Funktion prüft die Einstellungen des Nutzers und schreibt eine Zeile in die Tabelle notifications (für die Glocke).
4. Danach sendet sie an weitere Kanäle, die der Nutzer für diese Art eingeschaltet hat: E-Mail über deinen Anbieter, Push über die Push-API.
5. Das Frontend zeigt ungelesene Benachrichtigungen und markiert sie als gelesen, sobald man sie öffnet.

Ein einziger Einstiegspunkt bedeutet, dass du einen Kanal ergänzen, Formulierungen ändern oder Einstellungen respektieren kannst, ohne den Code zu durchsuchen.

Was du speichern solltest

Eine Benachrichtigungstabelle braucht meist: Nutzer-ID, Art (zum Beispiel comment_reply), einen kurzen Titel und Text, einen Link zur passenden Seite, Erstellungszeit und Lesezeit. Eine separate Einstellungstabelle speichert, welche Kanäle jeder Nutzer für jede Art möchte.

Neue Benachrichtigungen anzeigen

• Beim Laden der Seite abrufen und alle 30 bis 60 Sekunden abfragen. Einfach und zuverlässig.
• Echtzeit-Updates mit WebSockets oder Server-Sent Events wirken sofort, bringen aber bewegliche Teile mit. Starte mit Abfragen, außer sofortige Aktualisierung ist wirklich wichtig.

E-Mail-Benachrichtigungen

E-Mail braucht einen Versanddienst und eine verifizierte Domain; die Details stehen in wie du E-Mails aus deiner App verschickst. Speziell für Benachrichtigungen gilt:

• Vom Server aus senden, niemals mit einem Anbieter-Schlüssel im Browser.
• Häufige Ereignisse bündeln. „3 neue Kommentare“ in einer E-Mail ist besser als drei E-Mails.
• Eine tägliche oder wöchentliche Übersicht für Aktivitäten mit geringer Priorität anbieten.
• Einen Abmelde- oder Einstellungslink in nicht wesentlichen E-Mails einfügen. Die Regeln für Werbe-E-Mails unterscheiden sich je nach Land; prüfe, was für dich gilt.

Web-Push-Benachrichtigungen

Web-Push erlaubt deiner Website, Hinweise zu senden, die wie App-Benachrichtigungen erscheinen. Laut der Dokumentation der Push-API bei MDN funktioniert das so:

1. Deine Website registriert einen Service Worker, ein Skript, das der Browser im Hintergrund ausführen kann.
2. Nach Zustimmung des Nutzers abonniert der Service Worker über PushManager.subscribe(). Der Browser liefert ein Abonnement mit einem Endpunkt und Verschlüsselungsschlüsseln.
3. Dein Server speichert dieses Abonnement und sendet bei Ereignissen eine Nachricht an den Endpunkt, meist signiert mit VAPID-Schlüsseln (einem Schlüsselpaar, das deinen Server identifiziert).
4. Der Browser startet deinen Service Worker, der die Benachrichtigung anzeigt, auch wenn deine Seite nicht geöffnet ist.

MDN weist außerdem darauf hin, dass der Endpunkt geheim bleiben sollte, denn wer ihn kennt, kann Nachrichten an diesen Nutzer senden.

iPhone und iPad

WebKit hat Web-Push für Web-Apps in iOS und iPadOS 16.4 eingeführt, mit zwei Bedingungen aus der Ankündigung: Die Website muss zum Home-Bildschirm hinzugefügt sein, und die Berechtigung muss als Reaktion auf eine Nutzeraktion angefragt werden, etwa das Tippen auf einen Abonnieren-Button. Auf dem iPhone erreichst du Nutzer also nur, wenn sie deine Web-App installiert haben. Was Installieren einer Web-App bedeutet, erklärt native Apps vs. Progressive Web Apps.

Berechtigung richtig erfragen

Frag nicht beim ersten Besuch. Erkläre zuerst den Nutzen („Erhalte eine Erinnerung eine Stunde vor deinem Kurs“) und zeige den Browser-Dialog dann, wenn der Nutzer auf einen Button tippt. Wenn jemand ablehnt, lässt der Browser dich womöglich nicht erneut fragen. Eine vorzeitige Anfrage kann dich also dauerhaft um diese Person bringen.

Geplante Benachrichtigungen brauchen einen Auslöser

„Erinnerung 24 Stunden vorher“ oder „wöchentliche Zusammenfassung jeden Montag“ braucht etwas, das nach Zeitplan läuft. Das ist ein Problem für Hintergrundaufgaben, behandelt in wie du Hintergrundaufgaben ausführst. Ein gängiges Muster: Ein externer Planer ruft alle paar Minuten einen geschützten Endpunkt auf, der alles sendet, was fällig ist.

Prompts für deinen KI-App-Baukasten

Zuerst die In-App-Benachrichtigungen:

Füge In-App-Benachrichtigungen hinzu. Lege eine Tabelle notifications an (user, type, title, body, link, created_at, read_at). Füge eine serverseitige Funktion notify(userId, type, data) hinzu, die jedes Feature aufruft. Zeige im Header ein Glockensymbol mit Anzahl der ungelesenen Einträge, ein Dropdown mit den neuesten 20 und einen Button „Alle als gelesen markieren“. Alle 60 Sekunden auf neue Einträge prüfen.

Dann Einstellungen und E-Mail:

Füge Benachrichtigungseinstellungen hinzu: Für jede Art (Antworten auf Kommentare, Erwähnungen, Abrechnung) wählt der Nutzer In-App, E-Mail, beides oder keines. notify() muss diese Einstellungen respektieren. Sende E-Mails über [ANBIETER] mit dem Geheimnis [ENV_NAME], nur auf dem Server. Bündle Kommentar-E-Mails, sodass ein Nutzer höchstens eine E-Mail pro 15 Minuten bekommt.

Dann Push, falls du ihn brauchst:

Füge optionale Web-Push-Benachrichtigungen hinzu. Registriere einen Service Worker, erzeuge VAPID-Schlüssel und speichere den privaten Schlüssel als Geheimnis. Füge in den Einstellungen einen Button „Benachrichtigungen aktivieren“ hinzu, der die Berechtigung erst beim Klick anfragt. Speichere jedes Abonnement pro Nutzer und Gerät, sende Push aus notify() nur an Nutzer, die zugestimmt haben, und lösche Abonnements, die der Push-Dienst als abgelaufen meldet.

Häufige Fehler

• Benachrichtigungen im ganzen Code verstreut. Jedes Feature verschickt seine E-Mail anders, und die Einstellungen werden ignoriert. Verwende eine einzige Funktion notify().
• Push-Berechtigung beim Laden der Seite anfragen. Die meisten lehnen ab, und eine zweite Chance gibt es womöglich nicht.
• Keine Einstellungen. Nutzer, die störende Hinweise nicht abstellen können, schalten alle ab oder gehen.
• Vom Browser aus senden. Schlüssel für E-Mail und Push gehören auf den Server.
• Tote Push-Abonnements nicht aufräumen. Abgelaufene Abonnements sammeln sich an und verschwenden Versand.
• Vertrauliche Details im Benachrichtigungstext. Sperrbildschirme zeigen ihn. „Du hast eine neue Nachricht“ ist sicherer als die Nachricht selbst.
• Kein Protokoll, was gesendet wurde. Wenn ein Nutzer sagt „Ich habe die E-Mail nie bekommen“, helfen Protokolle mit den Nachrichten-IDs des Anbieters, den Grund zu finden.

Checkliste

• Eine serverseitige Funktion notify(), die überall verwendet wird
• Benachrichtigungstabelle mit Lesestatus und eine Glocke mit Anzahl ungelesener Einträge
• Kanaleinstellungen pro Art, von notify() respektiert
• E-Mail vom Server mit verifizierter Domain; Übersicht oder Bündelung für häufige Ereignisse
• Push-Berechtigung nur nach einer Nutzeraktion und mit Erklärung
• Push getestet am Desktop und auf einem iPhone mit der zum Home-Bildschirm hinzugefügten App
• Abgelaufene Push-Abonnements entfernt
• Keine vertraulichen Inhalte in Push- oder E-Mail-Vorschauen
• Geplante Erinnerungen haben einen verlässlichen Auslöser

Benachrichtigungen mit Mythex

Mythex enthält keinen eingebauten E-Mail- oder Push-Dienst für die Apps, die du baust. Du bringst deshalb deinen eigenen E-Mail-Anbieter mit und erzeugst deine eigenen Push-Schlüssel, gespeichert als Projektgeheimnisse. Der In-App-Teil braucht nur die Datenbank des Projekts, die Mythex hinzufügt, wenn du sie anforderst. Baue mit Prompts wie den oben, teste Glocke und E-Mails in der Vorschau und teste Push auf deiner veröffentlichten URL, denn Service Worker und Push brauchen eine echte HTTPS-Adresse. Das Rezept E-Mails aus deiner App senden in der Dokumentation enthält einen Start-Prompt. Mythex dokumentiert keine geplanten Aufgaben; plane zeitgesteuerte Erinnerungen deshalb mit einem externen Auslöser, wie in wie du Hintergrundaufgaben ausführst beschrieben.

Fragen