Progressive Web App vs. native App

Wer heute eine mobile Anwendung plant, steht früh vor derselben Frage: native App oder Progressive Web App (PWA)? Beide Wege führen zu funktionalen, mobilen Lösungen — aber sie unterscheiden sich erheblich in Aufwand, Reichweite und Betrieb. Eine Entscheidung, die zu Beginn unbedacht getroffen wird, lässt sich später nur aufwendig korrigieren.

Dieser Artikel ordnet die beiden Ansätze pragmatisch ein — aus Sicht eines Entwicklers, der beide Welten regelmäßig sieht.

PWAs haben sich in den letzten Jahren technisch stark weiterentwickelt. Was früher klare Domäne nativer Apps war, ist heute oft auch im Browser möglich. Die Vorteile im Überblick:

• Eine Codebasis für alle Plattformen. Die gleiche PWA läuft auf iOS, Android, Windows, macOS und Linux — ohne separate Builds, ohne doppelten Pflegeaufwand.
• Keine App-Store-Hürden. Keine Reviews, keine Gebühren an Apple oder Google, keine Wartezeiten auf Freigaben für Updates. Eine Änderung kann innerhalb von Minuten live sein.
• Niedrigere Einstiegshürde für Nutzer. Kein Download, keine Installation aus dem Store — ein Link reicht. Für interne Tools oder B2B-Portale, bei denen jeder Klick weniger zählt, ist das Gold wert.
• Geringere Entwicklungs- und Pflegekosten. Eine einzelne Codebasis statt zwei parallele Apps für iOS und Android — der Aufwand für Entwicklung, Updates und Bugfixes fällt entsprechend deutlich kleiner aus.
• SEO-Vorteil. Inhalte einer PWA sind über Google auffindbar — bei nativen Apps funktioniert das nur über App-Store-Optimierung, nicht über klassisches SEO.

Konkret: Wenn Sie ein Kundenportal, ein internes Auftragsmanagement oder einen Konfigurator als mobile Lösung brauchen, ist eine PWA in fast allen Fällen die wirtschaftlichere und schnellere Wahl.

PWAs sind nicht in jeder Hinsicht ebenbürtig. Es gibt Szenarien, in denen native Apps weiterhin klar überlegen sind:

• Tiefe Hardware-Integration. Wenn die App Bluetooth-Geräte koppelt, NFC-Tags ausliest, eine spezielle Kamera-Steuerung braucht oder im Hintergrund konstant arbeiten muss — hier hat native die Nase vorn.
• Maximale Performance bei Grafik und Animation. 3D-Anwendungen, anspruchsvolle Spiele oder komplexe Echtzeit-Visualisierungen profitieren von der direkten Nähe zur Plattform.
• App-Store-Präsenz als Marketing-Kanal. Wenn die Auffindbarkeit im Apple- oder Google-Store ein zentraler Vertriebsweg ist, kommt man an einer nativen App nicht vorbei.
• Strenge regulatorische Vorgaben. In manchen Branchen (z. B. Medizin, Banking) ist die App-Store-Verteilung Teil des Compliance-Konzepts.
• iOS-Einschränkungen. Apple hält PWA-Funktionen auf iOS bewusst zurück. Push-Benachrichtigungen funktionieren erst seit kurzem, viele Hardware-APIs sind weiterhin gesperrt. Wer iPhone-Nutzer als Hauptzielgruppe hat, sollte das einkalkulieren.

Aus meiner Praxis ergibt sich folgende Daumenregel — keine starre Vorschrift, aber ein guter Ausgangspunkt:

PWA passt vermutlich, wenn...

• die App primär ein Zugang zu einem Online-Service ist (Portal, Tool, Verwaltung).
• die Zielgruppe sowohl auf Smartphone als auch auf Desktop arbeitet.
• Updates häufig ausgerollt werden sollen, ohne dass Nutzer aktiv aktualisieren.
• das Budget eher in einer einzelnen Codebasis gut investiert ist — separate native Apps für iOS und Android verdoppeln Entwicklungs- und Pflegeaufwand.
• Auffindbarkeit über Google wichtiger ist als Sichtbarkeit im App-Store.

Nativ passt vermutlich, wenn...

• die App selbst ein Produkt ist, das im App-Store gefunden werden soll.
• spezielle Hardware-Funktionen (Bluetooth, NFC, Hintergrund-Tracking) zwingend gebraucht werden.
• iOS-Nutzer die klar dominante Zielgruppe sind und Push, Offline-Sync und Hardware-APIs eine zentrale Rolle spielen.
• Compliance- oder Marketingvorgaben den App-Store-Weg verlangen.

In vielen Fällen ist auch ein dritter Weg sinnvoll: Mit einer PWA starten, Marktreaktion und Nutzungsverhalten messen, und nur bei klarem Bedarf später eine native App nachschieben. So entstehen Kosten erst dann, wenn der Bedarf belegt ist — statt auf Verdacht teurer zu bauen.

In den meisten Anfragen, die mich erreichen, geht es nicht um „eine App im App-Store", sondern um „ein digitales Werkzeug, das auf jedem Gerät der Mitarbeiter und Kunden zuverlässig funktioniert". Genau dafür sind PWAs gebaut — und in genau diesen Fällen sind sie der wirtschaftlichere und schnellere Weg.

Mein Vorgehen: Im ersten Gespräch klären wir ehrlich, welche Funktionen tatsächlich gebraucht werden — nicht, welche theoretisch denkbar wären. Aus dieser Liste ergibt sich die Architektur fast von selbst. Falls eine Anforderung auftaucht, die zwingend nativ umgesetzt werden muss, sage ich das offen — und wir denken über eine Mischlösung nach, statt blind teurer zu bauen.