Next.js-Entwickler in Hannover

Wer in Hannover Servicetechniker, Monteure oder Vertriebsleute im Außendienst hat, kennt das Muster: Auftrag, Checkliste und Rückmeldung laufen über Zettel, Mail und eine Tabelle. Eine Next.js-Web-App, die als Progressive Web App installiert wird, kann das ersetzen, ohne dass jemand einen App Store öffnet. Auf dieser Seite steht, was dafür nötig ist, was der Browser nicht kann, und wie ich ein solches Projekt als Einzelperson aus Gdynia schriftlich und remote umsetze.

Die Stadt Hannover nennt auf hannover.de Messen wie HANNOVER MESSE 2027, Agritechnica 2027 und Ligna 2027 als Top-Veranstaltungen (Stand November 2026). Wer dort Standpersonal, Techniker oder Besucher mit einer App versorgt, arbeitet in vollen Hallen und auf Parkplätzen, nicht im stabilen Büro-WLAN. Genau dort entscheidet sich, ob eine PWA taugt.

Foto: Carsten Steger, CC BY-SA 4.0, Wikimedia Commons.

#Wann eine PWA passt und wann nicht

Der Next.js-Leitfaden zu PWAs nennt als Vorteile: Updates ohne App-Store-Freigabe, eine Codebasis für alle Plattformen und Funktionen wie Installation auf dem Home-Bildschirm und Push-Nachrichten. Das sind die Gründe, aus denen ich eine PWA vorschlage. Ob sie zu Ihrem Fall passt, zeigt diese Tabelle.

#Das Manifest mit app/manifest.ts

Im App Router legen Sie das Web-App-Manifest als app/manifest.ts ab. Laut Next.js-Dokumentation ist manifest.js ein spezieller Route Handler, der standardmäßig gecacht wird, solange er keine Request-Time-API oder dynamische Konfiguration nutzt. Ein Beispiel mit erfundenen Beispielwerten:

import type { MetadataRoute } from 'next'

export default function manifest(): MetadataRoute.Manifest {
  return {
    name: 'Serviceberichte',
    short_name: 'Service',
    start_url: '/',
    display: 'standalone',
    background_color: '#ffffff',
    theme_color: '#000000',
    icons: [
      { src: '/icon-192x192.png', sizes: '192x192', type: 'image/png' },
      { src: '/icon-512x512.png', sizes: '512x512', type: 'image/png' },
    ],
  }
}

Die Icons liefern Sie oder Ihre Marketingabteilung als fertige Dateien. Gestaltung, Icon-Satz und Farben kommen von Ihnen, ich binde sie ein. Alle gültigen Felder stehen im Typ MetadataRoute.Manifest und bei MDN.

#Installation auf Android und iOS

Der Next.js-Leitfaden nennt zwei Mindestvoraussetzungen: ein gültiges Manifest und HTTPS. Danach unterscheiden sich die Plattformen, wie web.dev beschreibt.

Zwei Folgen für Ihr Projekt. Erstens: Auf iPhones brauchen Mitarbeiter eine kurze Anleitung in der App. Der Next.js-Leitfaden zeigt dafür eine InstallPrompt-Komponente, die den Hinweis nur zeigt, wenn die App nicht schon im Standalone-Modus läuft. Zweitens: Einen eigenen Installieren-Button über beforeinstallprompt empfiehlt derselbe Leitfaden nicht, weil er plattformübergreifend nicht funktioniert und auf iOS fehlt.

#Der Service Worker: Registrierung und Updates

Ein Service Worker läuft nach MDN nur über HTTPS, localhost zählt zur Entwicklung als sicher. Sein Standard-Geltungsbereich ist das Verzeichnis, in dem die Datei liegt. Der Next.js-Leitfaden registriert ihn mit scope: '/' und updateViaCache: 'none', damit der Browser die Worker-Datei nicht aus seinem HTTP-Cache lädt.

Das Update-Verhalten überrascht Teams oft. Eine neue Version wird laut MDN im Hintergrund installiert, aber erst aktiv, wenn keine Seite mehr die alte nutzt. skipWaiting() und clients.claim() verkürzen das, bringen aber das Risiko, dass eine offene Seite plötzlich mit neuem Worker und altem Code läuft. In einem Formular, das ein Techniker gerade ausfüllt, ist das keine Nebensache. Ich entscheide das pro Projekt und halte es in der Spezifikation fest.

Für die Worker-Datei empfiehlt der Leitfaden eigene Header in next.config.js: Cache-Control: no-cache, no-store, must-revalidate, den korrekten Content-Type und eine strikte Content-Security-Policy. Wie CSP in Next.js allgemein aufgebaut wird, steht auf der Seite für Frankfurt.

#Offline: was geht und wo die Grenzen liegen

Ein Service Worker fängt Anfragen im Geltungsbereich ab und beantwortet sie aus dem Cache oder dem Netz. Welche Strategie gilt, bestimmen Sie pro Ressource. web.dev nennt dafür unter anderem diese Muster:

• Cache, dann Netz als Rückfall: Standard für Offline-First-Dateien wie Skripte, Icons und die App-Hülle.
• Netz, dann Cache als Rückfall: Online sehen Nutzer frische Daten, offline eine ältere Kopie.
• Stale-while-revalidate: Der Cache antwortet sofort, im Hintergrund wird für das nächste Mal aktualisiert.
• Generischer Rückfall: Eine Standardseite, wenn weder Cache noch Netz antworten.

Daraus folgen die Grenzen, die ich vor Projektbeginn mit Ihnen schriftlich festhalte:

1. Neue Daten brauchen Netz. Was nie geladen wurde, liegt nicht im Cache. Ein Techniker sieht offline nur die Aufträge, die vorher synchronisiert wurden.
2. Schreibende Aktionen brauchen eine Warteschlange. Server Actions und API-Aufrufe schlagen ohne Netz fehl. Laut Next.js-Leitfaden gibt es dafür den experimentellen Hook useOffline, der Navigation und fehlgeschlagene Server-Action-Anfragen erneut versucht. Für vollständigen Service-Worker-Cache nennt der Leitfaden als eine Option Serwist. Wie Server Actions sonst aufgebaut sind, steht auf der Seite für Bonn.
3. Der Browser darf Speicher räumen. Laut web.dev kann er Daten verwerfen, wenn das Gerät unter Speicherdruck steht. Dauerhaften Speicher muss der Nutzer freigeben.
4. Background Sync ist unzuverlässig. web.dev beschreibt den Zeitpunkt als heuristisches Intervall und nennt eine Nutzerfreigabe. Ich plane Abgleich deshalb zusätzlich beim Öffnen der App.
5. Caching im Server ist eine andere Ebene. Datencache und Revalidierung in Next.js erkläre ich auf der Seite für Augsburg.

Wer ohne Serverlaufzeit auskommen will, kann statisch exportieren. Der Leitfaden warnt: Dann entfallen Server Actions, und Header müssen an den vorgeschalteten Server wandern. Die Folgen beschreibt die Seite für Genf.

#Web Push mit VAPID

Push braucht drei Teile: einen aktiven Service Worker, eine Subscription und einen Server, der Nachrichten sendet. Nach MDN enthält die Subscription einen Endpoint und einen Schlüssel für verschlüsselte Daten. Der Endpoint ist eine geheime Capability-URL: Wer sie kennt, kann Nachrichten an die App senden. Speichern Sie ihn deshalb nur serverseitig und geschützt, nicht in Logs oder URLs.

Der Ablauf in Next.js nach dem Leitfaden:

1. VAPID-Schlüsselpaar erzeugen: web-push generate-vapid-keys.
2. Öffentlichen Schlüssel als NEXT_PUBLIC_VAPID_PUBLIC_KEY in die App, den privaten als VAPID_PRIVATE_KEY nur auf den Server.
3. Im Browser nach Klick pushManager.subscribe({ userVisibleOnly: true, applicationServerKey }) aufrufen und die Subscription an den Server geben.
4. Im Service Worker auf das push-Ereignis mit showNotification reagieren und auf notificationclick ein Fenster öffnen.

Serverseitig sieht der Kern so aus. Die Speicherung in einer Datenbank ist hier nur angedeutet, der Leitfaden hält die Subscription im Beispiel nur im Speicher und verweist für Produktion auf eine Datenbank.

'use server'
import webpush from 'web-push'

webpush.setVapidDetails(
  'mailto:[email protected]',
  process.env.NEXT_PUBLIC_VAPID_PUBLIC_KEY!,
  process.env.VAPID_PRIVATE_KEY!
)

export async function sendToUser(sub: webpush.PushSubscription, text: string) {
  await webpush.sendNotification(sub, JSON.stringify({ title: 'Auftrag', body: text }))
}

Zwei Regeln, die in Projekten wichtiger sind als der Code:

• Anfrage nur per Nutzeraktion. MDN rät, die Berechtigung nur nach einer Geste wie einem Klick zu erfragen. Auf iOS ist das zwingend: WebKit beschreibt die Anfrage als Reaktion auf direkte Nutzerinteraktion.
• iOS nur für Home-Bildschirm-Apps. Web Push kommt mit iOS und iPadOS 16.4 und gilt für Web-Apps, die zum Home-Bildschirm hinzugefügt wurden. Wer die App nur im Safari-Tab öffnet, bekommt keine Push-Nachrichten. Dazu passt die Installationsanleitung von oben.

MDN weist außerdem darauf hin, beim Anlegen von Subscriptions gegen CSRF zu schützen. Wie Anmeldung und Sitzungen für Mitarbeiter-Apps aufgebaut werden, steht auf der Seite für Wiesbaden.

Für Nutzer auf dem iPhone ist ein Detail relevant: Benachrichtigungen von Home-Bildschirm-Apps folgen laut WebKit den Fokus-Einstellungen des Geräts. Eine Push-Nachricht ist also kein Ersatz für eine Meldung, die garantiert gelesen werden muss.

#Datenschutz und Aufsicht in Niedersachsen

Ein Service Worker und sein Cache speichern Informationen in der Endeinrichtung des Nutzers. Nach § 25 Absatz 1 TDDDG braucht das grundsätzlich eine Einwilligung. Absatz 2 Nr. 2 nimmt Speicherung aus, die unbedingt erforderlich ist, damit der Anbieter einen vom Nutzer ausdrücklich gewünschten digitalen Dienst bereitstellen kann. Ob das für Ihre App zutrifft, hängt vom Zweck ab: Ein Offline-Cache für eine vom Mitarbeiter gewählte Arbeits-App liegt anders als Push-Marketing an Kunden. Die rechtliche Einordnung gehört in Ihre Datenschutzberatung. Aufsichtsbehörde in Niedersachsen ist der Landesbeauftragte für den Datenschutz Niedersachsen.

Technisch halte ich mich an das Minimum: Keine personenbezogenen Daten im Cache, der Push-Endpoint nur serverseitig, Abmelden im Menü der App statt im Browser-Dschungel, und eine Datenschutzerklärung, die Service Worker und Push nennt, wenn sie eingesetzt werden.

#Testen vor der Abnahme

Der Leitfaden verlangt für lokale Tests HTTPS (next dev --experimental-https) und aktivierte Browser-Benachrichtigungen. Ich ergänze eine Checkliste, die Sie auch ohne mich nutzen können:

Automatisierte Tests für solche Abläufe sind auf der Seite für Bochum beschrieben. Selbst betriebene Auslieferung steht auf der Seite für Berlin.

#Ablauf: von der Anfrage bis zur Abnahme

1. Brief schriftlich: Sie beschreiben den Ablauf, die Nutzergruppen und die Geräte. Ich stelle Rückfragen schriftlich.
2. Scope und Annahmen: Welche Daten offline verfügbar sein müssen, ob Push gebraucht wird, welche iOS- und Android-Versionen zählen.
3. Layout von Ihnen: Wireframes, Gestaltung und Icons liefern Sie, ich setze sie responsiv um. Dafür gibt es eine Tabellenvorlage, in der Sie markieren, welches Element auf welche Ansicht gehört.
4. Staging und Abnahme: Sie testen auf Ihren Geräten, Änderungen kommen schriftlich.
5. Betrieb: Auf Wunsch Wartung nach Vereinbarung, ohne Übertrag nicht genutzter Stunden.

Ich bin eine Einzelperson, arbeite remote und schriftlich, es gibt keine Termine vor Ort und keine Telefonate.

#Häufige Fragen

#Brauche ich für eine PWA einen Eintrag im App Store?

Nein. Laut Next.js-Leitfaden lassen sich Updates ohne Freigabe durch einen App Store ausliefern, installiert wird über den Browser. Auf Android kann Chrome die App installieren, auf iOS legt der Nutzer sie im Teilen-Menü auf den Home-Bildschirm.

#Funktioniert die App offline vollständig?

Nur für das, was vorher im Cache lag oder lokal gespeichert wurde. Ein Service Worker kann Seiten und Dateien ausliefern, Server Actions, neue Daten und Push-Nachrichten brauchen Netz. Welche Daten offline sinnvoll sind, legen wir vorher schriftlich fest.

#Gibt es Push-Benachrichtigungen auf dem iPhone?

Ja, ab iOS und iPadOS 16.4, aber nur für Web-Apps auf dem Home-Bildschirm. Die Berechtigung muss durch eine Nutzeraktion angefragt werden, etwa durch einen Button. Im normalen Safari-Tab ist das nicht möglich.

#Was sind VAPID-Schlüssel?

Ein Schlüsselpaar, mit dem Ihr Server sich beim Push-Dienst des Browsers ausweist. Der öffentliche Schlüssel kommt in die App, der private bleibt auf dem Server. Erzeugt wird es mit dem web-push-CLI per “web-push generate-vapid-keys”.

#Brauche ich für Service Worker und Push eine Einwilligung nach TDDDG?

Das hängt vom Zweck ab. § 25 Absatz 2 Nr. 2 TDDDG nimmt Speicherung aus, die unbedingt erforderlich ist, damit ein vom Nutzer ausdrücklich gewünschter Dienst bereitgestellt werden kann. Die Push-Freigabe holt der Browser ohnehin ausdrücklich ein. Die rechtliche Bewertung Ihres Falls gehört zu Ihrer Datenschutzberatung.

#Lohnt sich eine PWA oder ist eine native App besser?

Eine PWA lohnt sich, wenn ein Formular-, Listen- und Statusprozess auf Telefon und Tablet gebraucht wird und eine Codebasis genügt. Brauchen Sie tiefen Gerätezugriff, den der Browser nicht bietet, ist eine native App ehrlicher. Das prüfe ich vorab an Ihrem Ablauf.

#Schreiben Sie mir

Wenn Sie in Hannover eine App für Außendienst oder Kunden planen und wissen wollen, ob eine PWA reicht, schreiben Sie mir über die Kontaktseite. Nennen Sie den Ablauf, die Geräte, Ihr Ziel und Ihren Termin. Meine Antwort kommt an Werktagen schriftlich, die erste Einschätzung ist kostenlos.