PWA oder native App: was Ihr Vorhaben wirklich braucht
Eine Progressive Web App spart den zweiten Codestrang und den Weg durch den App Store. Auf dem iPhone hängt sie aber vom Wohlwollen eines Herstellers ab. Wann die PWA reicht und wann eine native App die bessere Wahl ist.
PWA oder App: die Frage hinter der Frage
Ob eine Progressive Web App oder eine native App die richtige Wahl ist, entscheidet sich an zwei Punkten: wie Nutzer die Anwendung finden und wie tief sie auf das Gerät zugreifen muss. Eine PWA ist eine Website, die sich installieren lässt, offline arbeiten kann und auf dem Startbildschirm wie eine App erscheint. Eine native App wird für iOS und Android eigens gebaut und über die Stores verteilt.
Wer seine Nutzer über die Suche, über Links in E-Mails oder über die eigene Website erreicht, hat mit einer PWA keinen Umweg: Ein Klick öffnet die Anwendung, ohne Store, ohne Download, ohne Freigabe durch einen Dritten. Wer dagegen darauf setzt, dass Menschen im App Store stöbern, oder wer Bluetooth-Geräte, NFC-Karten und Hintergrundaufgaben braucht, landet fast zwangsläufig bei einer nativen App.
Die meisten Vorhaben im Mittelstand liegen zwischen diesen Polen: ein Kundenportal, ein Bestellsystem für Bestandskunden, eine Anwendung für den Außendienst. Für genau diese Fälle lohnt der genaue Blick, weil die Mehrkosten einer nativen App dort selten einen Gegenwert haben – und die Grenzen einer PWA trotzdem real sind.
Was eine PWA heute kann – und was erst seit Kurzem
Eine PWA kann heute auf allen verbreiteten Plattformen installiert werden, offline arbeiten, Daten im Hintergrund zwischenspeichern und Push-Benachrichtigungen senden. Technische Grundlage sind ein Web-App-Manifest, das Name, Symbol und Darstellung festlegt, und ein Service Worker, der Anfragen abfängt und Inhalte für den Offline-Betrieb vorhält.
Auf Android und auf dem Desktop ist das seit Jahren gefestigt. Auf dem iPhone ist ein Teil davon jung: Push-Benachrichtigungen für Web-Apps gibt es dort erst seit iOS und iPadOS 16.4. Mit derselben Version kamen die Badging API, die eine Zahl auf das App-Symbol setzt, und die Möglichkeit, dass auch andere Browser als Safari eine Website zum Home-Bildschirm hinzufügen. Das WebKit-Team hat diese Neuerungen am 16. Februar 2023 angekündigt.
Für die Praxis heißt das: Was 2022 noch ein K.-o.-Kriterium gegen eine PWA war, ist heute lösbar. Die Abwägung hat sich verschoben – weg von „geht nicht“ hin zu „geht, aber mit Bedingungen“.
PWA auf dem iPhone: Push erst nach Installation
Push-Benachrichtigungen einer PWA funktionieren auf dem iPhone nur, wenn die Web-App zum Home-Bildschirm hinzugefügt wurde. Eine im Browser geöffnete Website kann auf iOS keine Push-Nachricht anfordern. Zusätzlich darf die Erlaubnis nur als Reaktion auf eine direkte Nutzeraktion abgefragt werden, etwa auf einen Tipp auf „Benachrichtigungen aktivieren“, nicht automatisch beim Laden der Seite.
Daraus folgt eine Hürde, die in vielen Vergleichen fehlt: Der Nutzer muss den Weg über „Teilen“ und „Zum Home-Bildschirm“ selbst gehen. Eine Schaltfläche, die diesen Schritt auslöst, gibt es auf iOS nicht. Wer Push-Nachrichten für den Kern seines Angebots braucht – Terminerinnerungen, Statusmeldungen, Alarme –, muss diesen Installationsschritt erklären und einplanen, dass ein Teil der Nutzer ihn nicht geht.
Auch die Darstellung der Benachrichtigungen ist auf iOS schlichter als auf Android: Erweiterte Formen wie Aktionsschaltflächen oder eingebettete Medien sind dort eingeschränkt. Für eine einfache Mitteilung genügt das; für eine Anwendung, die über Benachrichtigungen bedient wird, nicht.
Die EU-Episode 2024: wie abhängig Web-Apps von Apple sind
Wie verletzlich eine PWA auf dem iPhone ist, hat der Februar 2024 gezeigt. Am 15. Februar 2024 bestätigte Apple, dass Web-Apps auf dem Home-Bildschirm in der EU mit iOS 17.4 nur noch als einfache Verknüpfungen funktionieren sollten, die sich in Safari öffnen – ohne eigenes Fenster, ohne Push-Benachrichtigungen. Als Begründung nannte Apple die neuen Vorgaben aus dem Digital Markets Act, die andere Browser-Engines zulassen.
Am 1. März 2024 nahm Apple die Ankündigung zurück, nachdem es unter anderem aus der EU-Kommission Widerspruch gegeben hatte. Web-Apps auf dem Home-Bildschirm blieben erhalten, mit der Bedingung, dass sie weiterhin auf WebKit beruhen. Mit dem Erscheinen von iOS 17.4 funktionierten bestehende Installationen wie zuvor.
Die Episode ging gut aus, aber sie belegt die eigentliche Grenze der Sache: Eine PWA auf iOS läuft so lange, wie Apple sie lässt. Auch eine native App unterliegt Apples Regeln; der Unterschied ist, dass Web-Apps auf dem Home-Bildschirm eine Funktion des Betriebssystems sind, die Apple ohne Prüfverfahren für einzelne Apps ändern kann. Wer ein Geschäftsmodell vollständig auf Push-Benachrichtigungen an iPhone-Nutzer stützt, sollte diese Abhängigkeit bewusst eingehen und nicht übersehen.
Wann eine native App die bessere Wahl ist
Eine native App ist die bessere Wahl, wenn die Anwendung Hardware anspricht, im Hintergrund zuverlässig arbeiten muss oder ihre Nutzer im App Store findet. Bluetooth und NFC sind das deutlichste Beispiel: Die Web-Schnittstellen dafür führt die Entwicklerdokumentation MDN als experimentell und nicht in allen verbreiteten Browsern verfügbar; Safari setzt beide nicht um. Wer Messgeräte, Zutrittskarten oder Wearables anbindet, braucht deshalb in aller Regel eine native App.
Ähnlich ist es bei Aufgaben, die ohne geöffnete Anwendung weiterlaufen sollen – Standortverfolgung für eine Tour, regelmäßiger Datenabgleich, Aufnahmen über längere Zeit. Ein Service Worker wird vom Betriebssystem nur kurz geweckt; eine native App kann Hintergrundaufgaben gezielter anmelden.
Der dritte Grund ist der Vertrieb. Lebt das Angebot davon, dass Fremde es in einem Store entdecken, Bewertungen sammeln und über Suchbegriffe im Store gefunden werden, führt am Store kein Weg vorbei. Für eine Anwendung, die bestehende Kunden nutzen, ist dieser Grund dagegen meist keiner.
Kosten und Pflege: eine Codebasis gegen zwei Stores
Eine PWA ist in Entwicklung und Pflege meist günstiger, weil eine Codebasis alle Plattformen bedient. Eine 2026 veröffentlichte Marktübersicht nennt für eine PWA rund 10.000 bis 30.000 Euro, für native Apps auf beiden Plattformen 40.000 bis 100.000 Euro und für plattformübergreifende Frameworks wie Flutter oder React Native 20.000 bis 50.000 Euro. Das ist die Spanne einer einzelnen Quelle; sie zeigt das Verhältnis, nicht den Preis eines bestimmten Projekts.
Im laufenden Betrieb verschiebt sich der Abstand weiter. Eine PWA wird wie eine Website aktualisiert: Die neue Version ist beim nächsten Aufruf da. Eine native App braucht für jede Änderung eine Prüfung durch Apple und Google, und ältere Versionen bleiben auf Geräten, deren Nutzer nicht aktualisieren. Wer zwei Stores bedient, pflegt zwei Veröffentlichungsprozesse mit eigenen Richtlinien.
Dazu kommen die Gebühren der Stores beim Verkauf digitaler Inhalte: Der Standardsatz liegt bei 30 Prozent. Apple senkt ihn im Small Business Program seit 2021 auf 15 Prozent für Entwickler mit weniger als einer Million US-Dollar Erlös im Vorjahr, Google erhebt seit Juli 2021 auf die erste Million im Jahr 15 Prozent. Eine PWA, die ein Abo über die eigene Zahlungsabwicklung verkauft, zahlt diese Provision nicht. Für den Verkauf physischer Waren gilt sie ohnehin nicht.
App Store oder Suchmaschine: wie Nutzer die Anwendung finden
Eine PWA wird gefunden wie eine Website: über Suchmaschinen, Links und die eigene Domain. Ihre Inhalte sind indexierbar, sofern sie serverseitig ausgeliefert werden, und jeder Bereich hat eine eigene Adresse, die sich teilen lässt. Eine native App ist für Suchmaschinen weitgehend unsichtbar; gefunden wird sie über den Store.
In die Stores kommt eine PWA nur mit Einschränkungen. Bei Google Play lässt sich eine PWA über eine sogenannte Trusted Web Activity als App einreichen. Apples Prüfrichtlinien verlangen dagegen unter Punkt 4.2, dass eine App mehr bietet als eine umverpackte Website; eine reine Hülle um die eigene Seite wird regelmäßig abgelehnt.
Für die Entscheidung ist das eine nützliche Frage: Wo stehen die Menschen, die die Anwendung nutzen sollen, in dem Moment, in dem sie sie brauchen? Kommen sie von der eigenen Website, aus einem Newsletter oder aus der Google-Suche, ist die PWA im Vorteil. Suchen sie im Store nach einer Lösung für ihr Problem, ist es die native App.
Der Mittelweg: PWA zuerst, native Hülle später
Für viele Vorhaben ist eine PWA der sinnvolle erste Schritt, weil sie mit einer Codebasis schnell im Einsatz ist und zeigt, welche Funktionen tatsächlich genutzt werden. Stellt sich dann heraus, dass Push-Benachrichtigungen auf dem iPhone, Bluetooth oder die Präsenz im Store entscheidend sind, lässt sich gezielt nachrüsten – mit einer nativen App für genau diese Fälle oder mit einer Hülle, die die Web-Oberfläche einbettet und native Funktionen ergänzt.
Damit dieser Weg offen bleibt, gehört die Geschäftslogik von Beginn an hinter eine saubere Schnittstelle. Dann kann eine spätere native App dieselben Daten und Regeln nutzen, statt sie neu zu bauen. Wer die Logik dagegen in der Oberfläche verteilt, baut beim Wechsel ein zweites Mal.
Was eine PWA nicht leistet, sollte vorher feststehen: Sie ersetzt keine native App, wenn Hardware, Hintergrundbetrieb oder Store-Vertrieb den Kern des Angebots ausmachen. Und auf dem iPhone bleibt sie von Apples Entscheidungen abhängig, wie der Februar 2024 gezeigt hat. Wer beides einkalkuliert, trifft die Wahl auf belastbarer Grundlage.