Was ist eine PWA? Die Kernidee
Eine Progressive Web App (PWA) ist eine Webanwendung, die mit Standardtechnologien wie HTML, CSS und JavaScript gebaut wird und sich wie eine native App verhält: Sie lässt sich auf dem Startbildschirm eines Smartphones, Tablets oder Desktops installieren, funktioniert offline und unterstützt Push-Benachrichtigungen. Im Gegensatz zu einer klassischen Website lädt eine PWA auch in unzuverlässigen Netzen schnell und aktualisiert sich sofort, ohne durch einen App Store zu laufen. Für B2B-Unternehmen ist sie der Mittelweg zwischen einer langsamen Website und einer teuren nativen Entwicklung für zwei Plattformen.
Wie eine PWA funktioniert: drei technische Säulen
Jede PWA ruht auf drei offenen Webstandards. Erstens muss sie über HTTPS ausgeliefert werden - das verlangt der Browser, bevor er irgendeine fortgeschrittene API wie Geolokalisierung, Kamera, Push oder Hintergrundsynchronisation freigibt. Zweitens enthält sie ein Web App Manifest, eine kleine JSON-Datei, die Name, Icons, Theme-Farbe, Anzeigemodus und Start-URL deklariert, damit sich die Seite zum Startbildschirm „hinzufügen“ und im Vollbild ohne Browserleiste öffnen lässt. Drittens nutzt sie einen Service Worker: ein Script, das der Browser unabhängig von der Seite im Hintergrund ausführt, Netzwerkanfragen abfängt und entscheidet, ob sie aus dem Cache oder aus dem Netz bedient werden. Der Service Worker macht die Offline-Nutzung überhaupt erst möglich. Nach dem ersten Besuch legt das Script die „App-Hülle“ - also HTML, CSS und JavaScript, die die Oberfläche rahmen - zusammen mit wichtigen Ressourcen und, je nach Strategie, kürzlich gesehenen Geschäftsdaten im Cache ab. Beim nächsten Besuch rendert die Oberfläche auch ohne jede Verbindung sofort aus dem lokalen Cache, während eine Hintergrund-Sync-Schleife still darauf wartet, dass das Netz zurückkehrt. Bibliotheken wie Workbox liefern fertige Strategien: Cache-first für Logos und Schriften, Network-first für frische Preise und Bestände sowie stale-while-revalidate für nicht zeitkritisches Material. Die dritte Säule ist Responsive Design kombiniert mit Progressive Enhancement. Eine einzige Codebasis passt sich jedem Viewport an - vom 5-Zoll-Verkäuferhandy über einen 27-Zoll-Dashboard-Monitor bis zur Wand-Touch-Kiosk in einem Lagerhaus. Entscheidend ist: Der Kernworkflow muss in einem einfachen Browser funktionieren, bevor er auf fähigen Geräten mit App-Verhalten angereichert wird. Das bedeutet: Ein Kunde mit einem alten Android oder einem festgezurrten Unternehmensbrowser behält eine lauffähige Website, während Power-User auf modernem Chrome, Edge oder Safari eine installierbare, app-artige Erfahrung mit eigenem Icon und eigenem Startbildschirm erhalten. PWAs sind nicht brandneu - der Begriff wurde 2015 von Google geprägt - aber die Browserunterstützung ist deutlich reifer geworden. Chrome, Edge, Samsung Internet und Android Firefox behandeln installierbare PWAs als gleichwertige Apps; Safari auf iOS und iPadOS unterstützt sie seit 2020, Web Push seit 2023. Rund 90 % der mobilen Nutzer weltweit surfen mit Browsern, die die PWA-Grundlagen beherrschen, womit der klassische Einwand „funktioniert nicht auf dem iPhone“ weitgehend überholt ist. Was noch Lücken hat, sind einzelne fortgeschrittene Hardware-APIs - nicht die Installation oder der Offline-Modus.
PWA vs. native App: was wirklich unterscheidet
Der praktische Unterschied zwischen einer PWA und einer nativen iOS-/Android-App lässt sich auf wenige Dimensionen bringen. Verteilung: Eine PWA erreicht Nutzer über eine URL (E-Mail, QR-Code, Verkaufsdeck) ohne Store-Review; eine native App wartet auf die Freigabe durch App Store und Google Play. Installation: Eine PWA bittet um „Zum Home-Bildschirm“ und wiegt wenige Megabyte; eine native App lädt 50 bis 150 MB. Updates: Eine PWA erreicht 100 % der Nutzer beim nächsten Besuch; eine native App ist auf das gestaffelte Rollout des Stores und die Zustimmung des Nutzers angewiesen. Offline funktioniert in beiden Fällen, Push ist auf Android ausgereift und auf iOS nur teilweise. Hardware-Zugriff ist bei nativen Apps tief und im Web wachsend, und der Entwicklungsaufwand ist eine Codebasis gegen zwei parallele native Teams.
Warum B2B-Unternehmen auf PWAs setzen
Verteilung ohne Reibung
B2B-Software hat selten das Consumer-Marketing-Budget, um Store-Installationen voranzutreiben, und doch kaufen Einkäufer ein App-Gefühl. Mit einer PWA kann ein Interessent auf einen Link in einer E-Mail, einem PDF-Angebot oder einem CRM-Nachfassen klicken und landet direkt im lauffähigen Produkt - kein Store-Konto, kein Fortschrittsbalken, keine 80-MB-Wartezeit. Updates erreichen jeden Nutzer in der nächsten Sitzung, sodass eine Preisänderung, ein Compliance-Patch oder ein Release nicht mehr von gestaffelten Rollouts oder von Käufern abhängt, die ein rotes Badge ignorieren. Interne Tools für Vertrieb, Service und Operations umgehen zudem MDM-Reibung, weil die IT die App als Web-Ursprung verwaltet und nicht als signierte Binärdatei.
Offline und schwache Netze: echte Zuverlässigkeit
Produktion, Logistik, Außendienst, Bergbau und Landwirtschaft sind die klassischen B2B-Edge-Fälle, in denen LTE schwach oder gar nicht vorhanden ist. Eine PWA lagert Auftragsbuch, Inspektionsformulare, Produktkatalog und Preise lokal aus, sodass ein Techniker im Kellergeschoss einer Fabrik, ein Fahrer in einem ländlichen Depot oder ein Auditor auf einer Offshore-Plattform ununterbrochen weiterarbeiten kann. Wenn das Gerät endlich wieder Verbindung aufbaut, schiebt Background Sync die abgeschlossenen Formulare, Fotos und neuen Aufträge in einem einzigen Batch auf den Server. Öffentliche Fallstudien von Pizza Hut, Starbucks und Alibaba zeigten nach PWA-Starts zweistellige Conversion-Gewinne; in der B2B-Logistik verbuchten interne Außendienst-Tools als PWAs Produktivitätssteigerungen im Bereich von 15-30 % bei Teams, die Daten nach Schichtende vorher per Hand neu erfassten.
Niedrigere Kosten, schnellere Auslieferung, bessere Conversion
Eine einzige Web-Codebasis mit einem einzigen Team kostet über drei Jahre gerechnet typischerweise 30-50 % weniger als parallele iOS- und Android-Builds, die bei jedem OS-Release und auf Dutzenden Gerätemodellen erneut getestet werden müssen. Performance ist selbst ein Conversion-Hebel: Googles Daten zeigen, dass 53 % der mobilen Besuche abgebrochen werden, sobald die Ladezeit drei Sekunden überschreitet, und Service-Worker-Caching kann die Ladezeit wiederholter Besuche von mehreren Sekunden auf unter eine Sekunde drücken. Im B2B, wo ein einzelner Auftrag auch mal sechs- bis siebenstellig sein kann, hebt das Einsparen von zwei Sekunden auf einem Distributor-Portal, einem Partner-Onboarding oder einem Produktkonfigurator die Trial-to-Paid- und Renewal-Raten messbar an.
Sicherheit, Compliance und zentrale Updates
B2B-Einkäufer verlangen zunehmend konsistente Versionierung, Audit-Trails und Zero-Trust-Updates. Weil eine PWA von einem einzigen Web-Ursprung ausgeliefert wird, muss die IT-Nie Nutzern hinterherlaufen, die einen zwei Jahre alten Build fahren: Jeder Client erhält den gepatchten Code beim nächsten Start. Das vereinfacht SOC-2-, DSGVO-, ISO-27001- und branchenspezifische Audits erheblich, denn die Angriffsfläche ist ein einziges Deployable und nicht Hunderte heruntergeladene Binärdateien auf den Endgeräten. Feature-Flags, Regionalpreise und A/B-Experimente lassen sich innerhalb von Stunden auf die gesamte Nutzerbasis ausspielen, und Admins können Zugriffe entziehen oder Schlüssel zentral rotieren, ohne jemanden zu bitten, eine App zu deinstallieren.
PWA oder nativ? Ein praktischer Entscheidungsleitfaden
Echte Grenzen, die Sie einplanen sollten
PWAs sind keine Universallösung. Unter iOS kam Web Push erst 2023 an und bleibt weniger flexibel als unter Android: strengere Limits für Hintergrund-Sync, keine beliebigen stillen Pushes, und iPhone-PWAs sind auf etwa 50 MB Speicher gedeckelt, bevor das Betriebssystem sie nach Wochen der Inaktivität purgen kann. Hardware-APIs wie Bluetooth-Low-Energy-Beacons, USB-Peripherie, erweiterte AR, systemweite Sprachcall-Integration und echtes kontinuierliches Background-Geo-Tracking sind auf iOS noch lückenhaft oder unstet. Wenn Ihr Produkt auf durchgehend aktives GPS, tiefe Sensorfusion, Offline-Gesichtserkennung oder eine vom App Store gemanagte Abrechnung angewiesen ist, bleibt ein nativer Build - oder eine dünne hybride Hülle um eine bestehende PWA - die sicherere Wahl.
Rollout-Checklist für B2B-Teams
Erfolgreiche B2B-PWA-Launches folgen einem kleinen Satz an Disziplinen. Beginnen Sie mit Progressive Enhancement: Liefern Sie den Kernworkflow zunächst als schnelle, barrierefreie Website und lagern Sie erst danach Offline-Caching, Install-Prompts und Push-Benachrichtigungen darüber. Setzen Sie ein Performance-Budget - zum Beispiel unter zwei Sekunden bis Interaktiv auf einem Mittelklasse-4G-Smartphone, Lighthouse-Score über 90, erste Eingabeverzögerung unter 100 ms - und fixieren Sie es im CI, damit Regressionen den Build abbrechen. Bauen Sie eine Testmatrix auf, die iOS Safari, Android Chrome, ein Einsteiger-Android, Chrome und Edge am Desktop sowie mindestens ein Slow-Network-Profil abdeckt. Instrumentieren Sie schließlich explizit das Offline-Verhalten: Cache-Trefferquote, fehlgeschlagene Hintergrundsynchronisationen und Install-Prompts, damit das Produktteam sieht, wo die App-Erfahrung tatsächlich gewinnt. Wenn Sie prüfen, ob eine PWA das richtige Auslieferungsmodell für Ihr B2B-Portal, Ihr Händlertool oder Ihr Kunden-Dashboard ist, hilft Ihnen Quam Studio, die Trade-offs zwischen einer responsiven Website, einer PWA und einem nativen Build auszuloten, und gestaltet die Erfahrung um die Workflows herum, die Ihre Einkäufer wirklich nutzen. Erzählen Sie uns von Ihrem Projekt - Kostenloses Angebot anfordern.