Progressive Web Apps: Wann Eine PWA Native Schlägt

Progressive Web App Entwicklung ist die Option, die britische Auftraggeber in den ersten zehn Minuten eines Projekts verwerfen und achtzehn Monate später wiederentdecken, sobald die zweite native Codebasis das Budget still aufgefressen hat. Verworfen wird sie, weil fast alles Geschriebene in eines von zwei Lagern fällt: Werbung, die die Teile überspringt, die iOS verweigert, oder Skepsis aus dem Jahr 2019, als die Plattform sie tatsächlich nicht leisten konnte.

Beides ist heute falsch, und zwar so, dass sich die Rechnung ändert. Safari unterstützt Push Benachrichtigungen in Web Apps auf dem Home Bildschirm seit iOS 16.4. Chrome hat die Anforderung eines Service Workers für die Installation fallen gelassen. Die britische Regulierungsbehörde stufte Apple und Google im Oktober 2025 als Unternehmen mit strategischem Marktstatus über ihre mobilen Browser und Browser Engines ein. Gleichzeitig verweigert iOS weiterhin Hintergrundausführung, räumt gespeicherte Daten nach Regeln ab, die Sie nicht kontrollieren, und wird eine Web App nie im App Store listen.

Was folgt, ist die Fassung, die ich einem Kunden geben würde, der zwischen einer Codebasis und dreien wählt. Jede Aussage zu Funktionen unten wurde im September 2026 gegen die Dokumentation des Herstellers geprüft, weil hier das gängige Wissen verlässlich zwei Jahre veraltet ist.

Wann schlägt eine PWA eine native App? Wenn Ihre Nutzer ebenso auf Android und Desktop unterwegs sind wie auf dem iPhone, wenn die App ein Frontend zu einem Server ist und nicht zum Gerät, und wenn Menschen Sie über die Suche finden statt über einen Store. Eine PWA verliert, wenn Sie Standortverfolgung im Hintergrund, Widgets auf dem Home Bildschirm, Bluetooth auf dem iPhone oder Store Abrechnung brauchen. Die Ersparnis ist eine Codebasis statt dreier, im britischen Rahmen grob £40.000 bis £120.000 an Aufbau und danach jedes Jahr eine deutlich kleinere Rechnung.

Was eine Progressive Web App tatsächlich ist

Der Begriff wird locker genug verwendet, dass zwei Menschen in derselben Besprechung Unterschiedliches meinen können. Die technische Definition ist eng, und es lohnt sich, an ihr festzuhalten.

MDN beschreibt eine progressive Web App als eine App, die mit Technologien der Webplattform gebaut ist und ein Nutzungserlebnis wie eine plattformspezifische App bietet. Sie läuft aus einer Codebasis auf mehreren Plattformen, und sie lässt sich installieren, offline betreiben und in das Betriebssystem einbinden.

In der Praxis bedeutet das drei Artefakte, und eine Website, der eines davon fehlt, ist eine Website mit Ambitionen und keine PWA.

Das Web App Manifest

Das Manifest ist eine JSON Datei, die dem Betriebssystem sagt, wie die App heißt, welche Symbole zu verwenden sind, welche URL beim Start geöffnet wird und ob sie in einem Browserrahmen oder eigenständig läuft. Ohne das Manifest hat der Browser nichts zu installieren. Es ist klein, es ist statisch, und es ist der billigste Teil der ganzen Übung.

Der Service Worker

Ein Service Worker ist ein Skript, das getrennt von der Seite läuft, zwischen App und Netzwerk sitzt und Anfragen aus einem Cache beantworten kann. Er macht Offline Verhalten möglich, und er empfängt Push Nachrichten. Er ist auch der Teil, der schiefgeht, denn ein schlecht abgegrenzter Cache liefert Nutzern wochenlang veralteten Code aus.

HTTPS

Service Worker, Push, Standortbestimmung und Kamerazugriff sind sämtlich auf sichere Kontexte beschränkt. Bei modernem Hosting ist das kostenlos und automatisch, es ist also eine Randbedingung und kein Kostenpunkt.

Was installiert bedeutet, Plattform für Plattform

Auftraggeber nehmen an, Installation sei ein einziges Verhalten. Es sind drei, und die Unterschiede sind kaufmännisch relevant.

Android

Chrome auf Android kommt der Gleichwertigkeit am nächsten. Die App bekommt ein Symbol auf dem Home Bildschirm, einen eigenen Eintrag im App Umschalter, eigenen Speicher, und sie lässt sich über einen Wrapper im Play Store listen. Installationsaufforderungen lassen sich aus Ihrer eigenen Oberfläche auslösen, sobald der Browser das entsprechende Ereignis ausgelöst hat, Sie bestimmen also den Moment der Frage.

iOS und iPadOS

Safari installiert über das Teilen Menü und den Eintrag zum Hinzufügen auf den Home Bildschirm. Es gibt keine Installationsaufforderung in der Seite, die Sie auslösen könnten, kein Banner, das Apple für Sie anzeigt, und keine verlässliche Möglichkeit zu erkennen, dass ein Nutzer es getan hat. Diese eine Interaktionslücke ist der größte praktische Unterschied zwischen den Plattformen, und sie ist ein Gestaltungsproblem und kein technisches: Sie müssen dem Nutzer eine Geste beibringen.

Desktop

Chrome, Edge und Safari auf macOS installieren Web Apps allesamt mit eigenem Fenster ins Dock oder in die Taskleiste. Der Desktop ist der Ort, an dem PWAs am wenigsten umstritten und am stärksten unterschätzt sind, besonders für interne Werkzeuge, wo die Alternative ein Electron Build ist, den niemand pflegen will.

Chrome hat die Regeln für Installierbarkeit geändert, und die meisten Anleitungen haben es nicht bemerkt

Jahrelang wiederholte jeder Artikel dieselbe Prüfliste: Manifest, Symbole, HTTPS und ein Service Worker mit einem Fetch Handler. Der letzte Punkt gilt für den Installationsweg über das Menü nicht mehr.

Google hat die Anforderung eines Service Workers mit Fetch Handler entfernt, für die Installation aus dem Menü, in Version 108 auf Mobilgeräten und 112 auf dem Desktop, und liefert nun eine voreingestellte Offline Seite für Websites, die keine eigene bereitstellen. Der Algorithmus hinter der Installationsaufforderung möchte weiterhin einen Fetch Handler, die Installierbarkeit selbst hängt jedoch nicht mehr davon ab.

Die Auswirkung reichte bis in die Werkzeuge. Lighthouse hat seine PWA Kategorie in Version 12.0.0 vollständig entfernt, veröffentlicht im April 2024, weil jene Prüfungen existierten, um Kriterien zu testen, die nicht mehr galten. Wenn Ihre Build Pipeline noch an einem fehlenden PWA Wert scheitert, prüft sie etwas, das Google eingestellt hat.

Praktisch gelesen heißt das, dass Installation und Offline Fähigkeit entkoppelt sind. Sie können eine installierbare App ohne jede Offline Geschichte ausliefern, was oft die richtige erste Version ist, und Caching ergänzen, sobald Sie wissen, welche Bildschirme Menschen ohne Empfang tatsächlich nutzen.

Offline ist eine Entwurfsentscheidung mit Kosten

Das Wort offline verbirgt eine enorme Spannweite an Umfang. Eine gecachte Hülle, die den letzten bekannten Stand zeigt, ist eine Woche Arbeit. Eine wirklich offline first gebaute App, die Schreibvorgänge einreiht, Konflikte auflöst und bei Wiederverbindung abgleicht, ist ein anderes Produkt.

Caching Strategien

Service Worker Caching läuft auf vier Muster hinaus und auf eine Entscheidung je Ressourcentyp. Cache first liefert die gespeicherte Kopie und prüft nie nach, was für Schriften und gehashte Build Artefakte richtig ist. Network first versucht den Server und weicht zurück, was zu Daten passt, die aktuell sein müssen. Stale while revalidate liefert den Cache sofort und aktualisiert im Hintergrund, was die übliche Wahl für Inhalte ist. Network only nehmen Sie für alles, was nicht aus einer veralteten Kopie beantwortet werden darf, etwa Zahlungen.

Das falsch zu machen ist das häufigste PWA Versagen, das ich sehe. Eine Cache first Regel auf Ihrer Anwendungshülle liefert wiederkehrenden Nutzern das JavaScript des letzten Monats, bis irgendetwas ein Update erzwingt, und die Fehlermeldungen beschreiben Symptome, die es in Ihrem aktuellen Code nicht gibt.

Hintergrundsynchronisation

Schreibvorgänge offline einzureihen und bei zurückkehrender Verbindung abzuarbeiten ist der Zweck der Background Synchronization API. MDN führt sie als eingeschränkt verfügbar und ausdrücklich nicht als Baseline, was heißt, dass sie in einigen der meistgenutzten Browser nicht funktioniert.

Auf iOS schreiben Sie den Ersatz also selbst: die Warteschlange in IndexedDB ablegen und beim nächsten Öffnen der App abarbeiten. Das funktioniert, Nutzer nehmen es hin, und es sind vielleicht drei bis fünf Tage Entwicklung statt des Nachmittags, den die API gekostet hätte.

Push Benachrichtigungen entscheiden mehr Projekte als alles andere

Wenn eine einzelne Funktion einen PWA Vorschlag versenkt, dann diese, meist auf Grundlage von Tatsachen, die 2022 zutrafen.

Android und Desktop

Web Push auf Android Chrome, Desktop Chrome, Edge und Firefox funktioniert seit Jahren über das Zusammenspiel von Push API, Notifications API und einem Service Worker. Die Zustellung übernimmt der Push Dienst des Browserherstellers, die Erlaubnis ist eine übliche Abfrage, und es gibt keine nennenswerte Lücke gegenüber einer nativen App für den häufigen Fall, dass ein Server eine Nachricht an einen angemeldeten Nutzer schickt.

iOS und iPadOS

Apple hat Web Push in iOS und iPadOS 16.4 hinzugefügt. Die daran geknüpfte Bedingung ist der Teil, der übersehen wird: WebKit hält fest, dass die Web App zum Home Bildschirm hinzugefügt sein muss, und die Erlaubnis muss als Antwort auf eine direkte Nutzerinteraktion angefordert werden, etwa auf das Antippen einer Schaltfläche zum Abonnieren. Web Push funktioniert nicht für eine Website, die in einem Safari Tab liegt.

Das Manifest muss display auf standalone oder fullscreen setzen, und Benachrichtigungen verhalten sich dann wie die jeder anderen App: Sperrbildschirm, Mitteilungszentrale, gekoppelte Apple Watch und Steuerung je App in den Einstellungen. Badges funktionieren ebenfalls.

Apple hat später einen einfacheren Weg ergänzt. Declarative Web Push kam in Safari 18.4, verfügbar auf iOS und iPadOS 18.4 für Web Apps, die zum Home Bildschirm hinzugefügt wurden, und zeigt eine Benachrichtigung aus einer standardisierten JSON Nutzlast an, ohne dass ein Service Worker laufen muss. Es nimmt Arbeit ab. Es nimmt die Anforderung des Home Bildschirms nicht weg.

Die iOS Lücke, genau benannt

Die Lücke ist real, und sie ist kleiner als ihr Ruf. Sie genau zu benennen ist nützlicher, als sich über sie zu beklagen oder so zu tun, als hätte sie sich geschlossen.

Verdrängung gespeicherter Daten

WebKit räumt Website Daten nach dem Prinzip der am längsten nicht genutzten Einträge ab, wobei die letzte Nutzung an der letzten Nutzerinteraktion oder Speicheroperation gemessen wird. Die Dokumentation zur Speicherrichtlinie setzt eine Quote je Ursprung von bis zu 60 % des Datenträgers für Browser Apps und bis zu 15 % für andere Apps, mit Gesamtquoten von 80 % beziehungsweise 20 %, und bestätigt, dass eine eigenständige Web App auf dem Home Bildschirm dieselben Quoten wie der Browser erhält.

Daraus folgt zweierlei. Speicher ist nicht die Beschränkung, die man sich vorstellt, und Verdrängung ist ein Terminrisiko und kein Kapazitätsrisiko. Behandeln Sie das Gerät als Cache und den Server als Aufzeichnung, dann hört Verdrängung auf, ein Produktmangel zu sein.

Ausführung im Hintergrund

Es gibt kein Gegenstück zu einer nativen Hintergrundaufgabe auf iOS. Kein periodisches Abrufen, keine Standortbestimmung im Hintergrund, keine stille Verarbeitung bei geschlossener App. Alles, was nach Zeitplan geschehen muss, geschieht auf Ihrem Server und erreicht das Gerät über eine Push Nachricht, die der Nutzer sieht.

Keine Präsenz im App Store

Eine PWA kann nicht im App Store gelistet werden. Wenn ein nennenswerter Teil Ihrer Kunden erwartet, im Store nach Ihrer Marke zu suchen und Sie dort zu finden, ist das kein technisches Problem, das Sie im Web überhaupt lösen können.

Browser Engines, der DMA und die CMA

Das ist der Teil, in dem die Berichterstattung den Primärquellen davonläuft, es lohnt sich also, eng bei dem zu bleiben, was tatsächlich dokumentiert ist.

Apple erlaubt inzwischen alternative Browser Engines, und es ist ausdrücklich festgehalten, dass dies allein in der Europäischen Union gilt, auf iOS 17.4 oder später und iPadOS 18 oder später, über zwei Berechtigungen, die Entwicklern erteilt werden, welche veröffentlichte Kriterien zu Sicherheit, Datenschutz und Testsuiten erfüllen. Apple verlangt, dass 90 % der Web Platform Tests und 80 % von Test262 bestanden werden, Betrieb ohne JIT, und dass die meisten Schwachstellen binnen 30 Tagen behoben werden.

Für ein britisches Unternehmen ändert davon heute nichts etwas. Die Berechtigungen sind an die Rechtsordnung gebunden, und eine britische Nutzerin bei einem britischen Netzbetreiber führt WebKit aus, welches Browsersymbol sie auch angetippt hat.

Die britische Lage bewegt sich getrennt davon. Am 22. Oktober 2025 hat die CMA Apple und Google einen strategischen Marktstatus bei ihren mobilen Plattformen zuerkannt, umfassend Betriebssysteme, App Vertrieb, Browser und Browser Engines, für einen Zeitraum von fünf Jahren. Die Einstufung ist die Befugnis, Verhaltensauflagen zu erlassen, nicht die Auflagen selbst. Planen Sie mit der Plattform, wie sie sich heute verhält, und behandeln Sie jede Lockerung als Zugewinn.

Hardware und Geräte APIs, geprüft statt angenommen

Das Web könne nicht auf Hardware zugreifen ist der Einwand, den ich am häufigsten höre, und derjenige, der im konkreten Fall am häufigsten falsch ist.

Was praktisch überall funktioniert

Kamera und Mikrofonzugriff über getUserMedia ist bei MDN Baseline und funktioniert seit 2017 über Browser hinweg. Standortbestimmung, Geräteausrichtung, Datei Uploads einschließlich Kameraaufnahme auf Mobilgeräten, Zugriff auf die Zwischenablage, die Web Share API auf Mobilgeräten und Passkeys über WebAuthn mit Face ID oder einem Fingerabdruck als Authentifikator funktionieren allesamt in aktuellen mobilen Browsern. Barcode und QR Erfassung über den Kamerastrom ist Routine.

Für die große Mehrheit betrieblicher Anwendungen ist diese Liste der gesamte Hardwarebedarf.

Was nur Chromium ist, und auf Mobilgeräten faktisch nur Android

Web Bluetooth ist von Google dokumentiert als verfügbar auf ChromeOS, Chrome für Android 6.0, macOS ab Chrome 56 und Windows 10 ab Chrome 70, ohne aufgeführte iOS Unterstützung, und MDN markiert es als eingeschränkt verfügbar statt als Baseline. Web NFC ist noch enger: Google dokumentiert es als verfügbar auf Android in Chrome 89.

Die File System Access API zum Lesen und Schreiben nutzergewählter Dateien ist ebenfalls Chromium Gebiet, wobei das origin private file system die meisten app internen Speicherbedürfnisse über Browser hinweg abdeckt.

Vertrieb über den App Store ist eine kaufmännische Frage, keine technische

Teams streiten über den Vertrieb im Store, als ginge es um Leistungsfähigkeit. Es geht um vier kaufmännische Größen, und nur eine davon spricht eindeutig für den Store.

Auffindbarkeit ist der ehrliche Vorteil. Verbraucher suchen tatsächlich im App Store und bei Play nach Marke und nach Kategorie, und ein Unternehmen ohne Präsenz im Store verzichtet auf diesen Kanal. Für ein Verbraucherprodukt mit bekanntem Namen zählt das enorm und für ein Werkzeug, das 200 Beschäftigte eines einzigen Unternehmens nutzen, sehr wenig.

Vertrauen ist real und je nach Publikum ungleich verteilt. Ältere und weniger technikaffine Nutzer lesen einen Eintrag im Store als Sicherheitssignal. Jüngere zunehmend nicht, und dieselbe Person nutzt auf demselben Telefon bereitwillig die Website einer Bank.

Dem steht gegenüber, dass ein Store eine Prüfschlange zwischen Sie und Ihre Nutzer schiebt, ein Ablehnungsrisiko nach Regeln, die sich ändern, und eine Provision auf alles, was Sie in der App verkaufen. Eine PWA hat nichts davon. Sie veröffentlichen, wenn Sie es entscheiden, und eine kritische Korrektur erreicht jeden Nutzer beim nächsten Laden statt nach einer Prüfung.

Was die Stores tatsächlich verlangen

Die Provisionszahlen bewegen sich oft genug, dass es unklug ist, sie aus dem Gedächtnis zu zitieren. Dies sind die veröffentlichten Bedingungen der Anbieter selbst, geprüft im September 2026.

Apple verlangt 30 % als Standardprovision auf digitale Waren und Dienste. Das App Store Small Business Program senkt das auf 15 % für Entwickler mit bis zu 1.000.000 USD Erlösen im vorangegangenen Kalenderjahr, wobei neue Entwickler teilnahmeberechtigt sind und der Standardsatz für künftige Verkäufe wieder greift, sobald Sie die Schwelle in einem Jahr überschreiten.

Google veröffentlicht eine gestaffelte Servicegebühr für Google Play: 15 % auf die ersten 1 Mio. USD Entwicklerumsatz je Jahr, 30 % darüber und 15 % auf sich automatisch verlängernde Abonnements unabhängig vom Umsatz. Dieselbe Seite legt eine abweichende Struktur dar, die am 30. Juni 2026 für den EWR, das Vereinigte Königreich und die USA in Kraft tritt, auf Basis von 10 % oder 20 % zuzüglich einer Abrechnungsgebühr von 5 %, je nachdem ob die Installation neu oder bestehend ist.

Beide Anbieter veröffentlichen in USD. Ein monatliches Abonnement von £9,99 über einen Store zu verkaufen kostet bei 15 % etwa £18 im Jahr je Abonnent und bei 30 % etwa £36. Multiplizieren Sie mit Ihrer Abonnentenzahl, bevor Sie den Store für kostenlos halten.

Sie können eine PWA weiterhin über Google Play ausliefern

Android gibt Ihnen beide Möglichkeiten zugleich, was eine echte Asymmetrie im Plattformvergleich ist und selten erwähnt wird.

Eine Trusted Web Activity ist eine Android App, die Ihre eigene PWA bildschirmfüllend und ohne Browserrahmen öffnet, über Digital Asset Links als Ihre verifiziert. Sie setzt Chrome auf Android 72 oder höher voraus, und die Host App hat keinen Zugriff auf Cookies oder Speicher der Webinhalte. In der Praxis ist es eine dünne Hülle, aus Ihrem Manifest erzeugt und wie jede andere App bei Play eingereicht.

Auf Android lautet die Wahl also nicht Store oder Web. Sie veröffentlichen die PWA, hüllen sie ein und bekommen den Eintrag im Store obendrein, aus derselben Codebasis, für ein paar Tage Verpackungsarbeit und die jährliche Gebühr für das Entwicklerkonto.

Auf iOS gibt es kein Gegenstück. Apples Prüfrichtlinien behandeln eine Hülle um eine Website seit Langem als für sich genommen unzureichend, der Weg in den iOS Store bedeutet also, etwas wirklich Natives zu bauen. Diese Asymmetrie prägt die Kostentabelle unten stärker als jede Lücke bei den APIs.

Kosten der Progressive Web App Entwicklung gegenüber zwei nativen Codebasen

Der Vergleich, den Menschen anstellen, sind die Baukosten, und das ist die kleinere Hälfte. Der Vergleich, der das Ergebnis entscheidet, sind die Gesamtkosten über drei Jahre, denn der Aufwand für Natives wiederholt sich.

Lesen Sie diese als Bänder britischer Agenturen für eine betriebliche Anwendung mittlerer Komplexität, nicht als Angebot. Eine PWA dieser Form ist typischerweise ein Team aus zwei oder drei Entwicklern über drei bis fünf Monate. Zwei native Codebasen plus Webpräsenz sind drei Teams, drei Veröffentlichungsprozesse und jedes Jahr drei Sätze von Plattform Upgrades.

Der Abstand zwischen der ersten und der dritten Zeile, grob £75.000 bis £175.000 beim Aufbau und danach £27.000 bis £60.000 im Jahr, ist das, was Sie kaufen, wenn Sie nativ kaufen. Manchmal ist das gut angelegtes Geld. Es sollte eine Entscheidung sein und keine Voreinstellung. Unsere Seiten zu Website Entwicklung und Softwareentwicklung legen dar, wie wir beide Wege abstecken.

Wohin das Geld für Wartung tatsächlich fließt

Baukosten werden verhandelt. Wartungskosten werden entdeckt, und dort scheitern Projekte mit mehreren Codebasen leise statt laut.

Native Plattformen zwingen Ihnen jedes Jahr Arbeit auf. Neue Hauptversionen des Betriebssystems verwerfen APIs, Signierung und Provisionierung ändern sich, Mindeststufen des SDK steigen, und Richtlinien der Stores fügen Anforderungen wie Datenschutzmanifeste und Erklärungen zur Datensicherheit hinzu. Nichts davon liefert eine Funktion aus. Auf zwei Plattformen zahlen Sie es zweimal, nach einem Zeitplan, den jemand anderes setzt.

Dann gibt es die Abweichung. Zwei Codebasen, die dieselbe Funktion umsetzen, laufen auseinander, und das Auseinanderlaufen zeigt sich als Supportmeldungen, die sich nur auf einer Plattform reproduzieren lassen. Jede Produktentscheidung muss zweimal getroffen und abgeglichen werden, und die Abstimmungskosten stehen auf keiner Rechnung.

Eine PWA ersetzt all das durch die Entwicklung der Browser, die kontinuierlich und abwärtskompatibel ist und funktionierenden Code fast nie bricht. Die wiederkehrende Arbeit sind Ihre eigenen Abhängigkeitsaktualisierungen, Sicherheitspatches und Hosting, also dieselbe Wartung, die jede maßgeschneiderte Webanwendung ohnehin braucht.

Der Vergleich, auf den es ankommt, sind nicht zwei Zahlen in einem Angebot. Es ist ein Team gegen drei, jedes Jahr, so lange das Produkt lebt.

Performance und Core Web Vitals für eine PWA

Eine installierte App wird an Nativem gemessen, die Messlatte für Performance liegt also höher als bei einer Website und nicht niedriger. Die gute Nachricht ist, dass die Metriken öffentlich und die Schwellen fest sind.

Core Web Vitals besteht derzeit aus drei Metriken, jede bewertet am 75. Perzentil der Seitenaufrufe und getrennt nach Mobil und Desktop. Largest Contentful Paint ist gut bei 2,5 Sekunden oder weniger und schlecht oberhalb von 4,0. Interaction to Next Paint, das First Input Delay ablöste, als es 2024 stabil wurde, ist gut bei 200 Millisekunden oder weniger und schlecht oberhalb von 500. Cumulative Layout Shift ist gut bei 0,1 oder weniger und schlecht oberhalb von 0,25.

Eine PWA hat hier einen strukturellen Vorteil. Ein Service Worker, der die Hülle aus dem Cache liefert, macht wiederholte Besuche nahezu unmittelbar, was genau das Muster ist, das eine installierte App erzeugt, sodass echte Nutzerdaten einer installierten PWA meist besser aussehen als derselbe Code kalt im Browser aufgerufen.

Sie hat auch ein strukturelles Risiko. Single Page Frameworks verlagern Arbeit auf den Client, und INP ist die Metrik, die das bestraft. Wenn Sie bereits mit diesen Zahlen kämpfen, behandelt unser Leitfaden zum Bestehen der Core Web Vitals die Diagnose ausführlicher, als dieser Beitrag es kann.

SEO ist der Vorteil, den niemand einpreist

Das ist das Argument, das ich in den meisten kaufmännischen Fällen an den Anfang stellen würde, und es fehlt im Vergleich fast immer vollständig.

Eine PWA ist eine Website. Jeder Bildschirm hat eine URL, jede URL lässt sich crawlen, indexieren, verlinken und teilen, und jede kann ranken. Eine native App hat nichts davon. Einträge im Store werden nur oberflächlich indexiert und ranken innerhalb eines geschlossenen Gartens nach völlig anderen Signalen, und die Inhalte in der App sind für die Suche unsichtbar.

Die Folge verstärkt sich mit der Zeit. Marketingausgaben für eine native App kaufen Installationen und enden an dem Tag, an dem die Ausgaben enden. Dieselben Ausgaben für Inhalte und technische Qualität einer PWA kaufen eine Seite, die weiter rankt. Über drei Jahre übersteigt dieser Unterschied häufig die gesamten Baukosten beider Wege.

Es zahlt sich nur aus, wenn die Umsetzung crawlbar ist, und genau daran scheitern clientseitig gerenderte Anwendungen: alles in JavaScript zu rendern, mit einer URL und ohne serverseitig erzeugtes HTML, verspielt den Vorteil vollständig. Serverseitiges Rendern oder Prerendern der indexierbaren Routen ist die Lösung, und ein technisches SEO Audit vor dem Start ist weit billiger, als nach sechs Monaten festzustellen, dass nichts indexiert wurde.

Die ausschließenden Anforderungen

Die Entscheidung fällt leichter als Liste von Vetos denn als Liste von Vorteilen, weil die Vetos objektiv sind.

Sie brauchen Natives, wenn eines der folgenden Dinge eine echte Anforderung und kein Wunsch ist. Standortverfolgung im Hintergrund bei geschlossener App. Widgets auf dem Home Bildschirm, Apps für die Uhr oder die Einbindung von CarPlay und Android Auto. Bluetooth oder NFC auf dem iPhone. HealthKit, Apple Pay in der App, oder jede tiefe Einbindung ins Betriebssystem, die Apple dem Web nicht geöffnet hat. Abrechnung über den Store für digitale Waren, wo die Richtlinie es verlangt. Anhaltend schwere Berechnung, etwa Videoverarbeitung in Echtzeit oder 3D Rendering mit nativen Bildraten. Präsenz im App Store als Marketinganforderung, von der Ihr Geschäft wirklich abhängt.

Trifft nichts davon zu, ist eine PWA sehr wahrscheinlich die richtige Antwort, und die Beweislast liegt bei dem, der drei Codebasen will.

Zwei weitere Überlegungen verschieben es noch weiter. Sind Ihre Nutzer überwiegend auf Desktop oder Android, betreffen die iOS Lücken eine Minderheit Ihres Publikums. Und ist die App ein Frontend zu Ihrem eigenen Server statt zum Gerät, was auf die meiste Unternehmenssoftware zutrifft, spielen die Fähigkeiten des Geräts kaum eine Rolle.

Szenario eins: Außendienst für einen Gebäudedienstleister

Zweihundert Techniker, Auftragsscheine, Fotos abgeschlossener Arbeiten, Unterschriftenerfassung, lückenhafter Empfang in Technikräumen und Kellern. Das ist der Fall, von dem man annimmt, er brauche Natives, und es ist der, in dem eine PWA am deutlichsten gewinnt.

Jede Anforderung ist abgedeckt. Die Kamera funktioniert über getUserMedia. Unterschriften sind ein Canvas Element. Auftragsdaten liegen im Cache in IndexedDB und die Schreibwarteschlange wird bei Wiederverbindung abgearbeitet, selbst gebaut, weil Background Sync über Browser hinweg nicht verlässlich ist. Einsatzmeldungen gehen als Web Push hinaus, was auf Android funktioniert und auf iOS für Techniker, die die App zum Home Bildschirm hinzugefügt haben, und die Installation ist ein Punkt von fünf Minuten in der Einweisung statt ein Problem der Nutzergewinnung.

Es gibt keine Anforderung an Auffindbarkeit im Store, weil die Nutzer Beschäftigte sind. Es gibt keine Abrechnung, Provision ist also unerheblich. Die Geräte sind gemischt Android und iOS, was genau der Fall ist, der zwei native Codebasen am härtesten bestraft.

Bauen Sie eine PWA für vielleicht £45.000 bis £70.000 statt zweier nativer Apps für £120.000 bis £200.000, liefern Sie Korrekturen noch am selben Nachmittag statt über eine Prüfung, und stecken Sie den Unterschied in das Dispositionsbackend, das tatsächlich darüber entscheidet, ob die Sache funktioniert.

Szenario zwei: Eine Salonkette, die Buchungen und Erinnerungen will

Vierzehn Filialen, verbrauchernah, Terminbuchung, Erinnerungen, ein Treueprogramm, Zahlungen an der Kasse statt in der App. Der Reflex ist eine native App, weil Wettbewerber eine haben.

Die Anforderungsliste ist unauffällig: Buchungsformulare, ein Kalender, Erinnerungen, ein Kontobereich. Erinnerungen sind der einzige interessante Punkt, und sie werden in diesem Markt von SMS und E-Mail besser bedient als von Push, weil eine Kundin, die zweimal im Jahr bucht, nichts installiert haben wird.

Auffindbarkeit ist der entscheidende Faktor, und sie spricht klar für das Web. Menschen finden Salons über Suche und Karten, nicht durch Stöbern in einem App Store, die Seiten, die Leistungen beschreiben und Buchungen entgegennehmen, müssen also ranken. Eine native App ist dafür vollkommen unsichtbar. Die Kosten der Website selbst sind der eigentliche Budgetposten, mit der App Schicht als Installierbarkeit obendrauf.

Bauen Sie die Buchungswebsite ordentlich, machen Sie sie installierbar, damit Stammkundinnen sie auf dem Home Bildschirm behalten können, und ergänzen Sie Web Push für die Minderheit, die zustimmt. Ein natives Vorhaben gibt hier £80.000 oder mehr aus, um weniger Kunden zu erreichen, als die Website bereits erreicht.

Szenario drei: Ein Fitnessprodukt im Abonnement

Angeleitete Workouts, Videoinhalte, eine Einbindung von Wearables, £12,99 im Monat, direkt an Verbraucher, Wachstum finanziert durch bezahlte Akquise. Dieses Szenario geht in die andere Richtung, und es lohnt sich zu zeigen, warum.

Auffindbarkeit im Store zählt hier, weil Fitness eine Kategorie zum Stöbern ist und ein Eintrag ein echter Kanal der Akquise. Die Einbindung von Wearables bedeutet HealthKit, das das Web nicht erreichen kann. Hintergrundaudio und das Verhalten des Bildschirms während eines Workouts sind nativ besser. Videodownload zur Offline Nutzung im großen Maßstab ist im Web machbar, aber nicht bequem.

Die Abrechnung ist der interessante Teil. Provision im Store auf £12,99 im Monat sind bei 15 % grob £23 im Jahr je Abonnent und bei 30 % £47, was bei 20.000 Abonnenten £460.000 bis £940.000 im Jahr ergibt. Das ist ein starkes Argument dafür, die Zahlung im Web entgegenzunehmen und die App als Client zu behandeln, was mehrere große Abonnementprodukte inzwischen tun.

Die Antwort sind native Apps für das Produkt und eine PWA oder normale Web App für Anmeldung, Abrechnung und Content Marketing. Beides existiert, und die Aufteilung ist gewollt und nicht zufällig.

Wie Sie an einem Nachmittag entscheiden

Die Entscheidung braucht keine Phase der Discovery. Sie braucht vier Antworten, aufgeschrieben.

Erstens, listen Sie die Fähigkeiten des Geräts auf, die Sie wirklich brauchen, und prüfen Sie dann jede einzelne gegen die Dokumentation des Herstellers statt gegen eine Zusammenfassung. Die meisten Listen werden an dieser Stelle drastisch kürzer. Zweitens, stellen Sie fest, woher Ihre Nutzer kommen: lautet die Antwort Suche, hat das Web bereits den Vorteil, lautet sie Stöbern im Store, hat es ihn nicht.

Drittens, kalkulieren Sie alle drei Wege über drei Jahre statt über eines, einschließlich der Wartungszahlen oben, und rechnen Sie die Provision des Stores auf alles ein, was Sie verkaufen wollen. Viertens, seien Sie ehrlich zu Ihrem Team. Eine Codebasis, gepflegt von drei Entwicklern, liefert mehr aus als drei Codebasen, gepflegt von drei Entwicklern, jedes Mal.

Ist die Antwort danach noch uneindeutig, bauen Sie zuerst die PWA. Sie ist die günstigere Option, um sie umzukehren. Von einer PWA später zu Nativem zu gehen heißt, die nativen Clients gegen eine API zu schreiben, die bereits existiert und sich bewährt hat, und der umgekehrte Weg heißt, von vorn zu beginnen. Diese Asymmetrie ist mehr wert als die meisten Funktionsvergleiche oben.

Was das für Sie bedeutet

Progressive Web App Entwicklung ist kein Kompromiss für Leute, die sich Natives nicht leisten können, und sie ist auch keine allgemeingültige Antwort. Sie ist die richtige Architektur für eine klar umrissene und große Kategorie von Produkten: Unternehmenssoftware, interne Werkzeuge, Systeme für Buchung und Konten, Contentprodukte und alles, dessen Kunden über die Suche kommen.

Die iOS Lücken sind real, konkret und meist umgehbar statt tödlich. Push funktioniert, wenn der Nutzer installiert. Speicher ist großzügig, aber verdrängbar. Ausführung im Hintergrund existiert nicht und gehört ohnehin auf Ihren Server. Bluetooth und NFC funktionieren auf dem iPhone nicht, und daran ändert kein Aufwand etwas.

Mecanik baut beide Wege und sagt Ihnen, wann die Antwort nativ lautet. Wenn Sie den Vergleich gegen Ihre tatsächlichen Anforderungen gerechnet haben wollen statt gegen eine allgemeine Liste, beschreiben die Seiten zu Website Entwicklung und Softwareentwicklung, wie wir das abstecken, und unser Leitfaden zum Bau einer Web App im Jahr 2026 behandelt die Entscheidungen zum Stack, die daraus folgen.

Häufig gestellte Fragen

Was ist eine progressive Web App? Eine progressive Web App ist eine App, die mit Webtechnologien gebaut ist und sich wie eine plattformspezifische App verhält. Technisch ist es eine über HTTPS ausgelieferte Webanwendung mit einem Web App Manifest, das Name, Symbole und Startverhalten beschreibt, dazu ein Service Worker, der Anfragen aus einem Cache beantworten und Push Nachrichten empfangen kann. MDN definiert sie als Software, die aus einer Codebasis auf mehreren Plattformen läuft und dabei installierbar und offline lauffähig bleibt.

Kann eine PWA Push Benachrichtigungen auf dem iPhone senden? Ja, mit einer Bedingung. Apple hat Web Push in iOS und iPadOS 16.4 hinzugefügt, aber WebKit verlangt, dass die Web App zuvor zum Home Bildschirm hinzugefügt wurde und dass die Erlaubnis als Antwort auf eine direkte Nutzerinteraktion angefordert wird, etwa das Antippen einer Schaltfläche zum Abonnieren. Push funktioniert nicht für eine Website, die in einem Safari Tab läuft. Declarative Web Push, hinzugefügt in iOS und iPadOS 18.4, vereinfacht die Umsetzung, behält aber dieselbe Anforderung des Home Bildschirms bei.

Was kostet Progressive Web App Entwicklung im Vereinigten Königreich? Für eine betriebliche Anwendung mittlerer Komplexität rechnen Sie mit £35.000 bis £75.000 für den Aufbau einer einzelnen PWA Codebasis und £8.000 bis £20.000 im Jahr für die Wartung. Der vergleichbare native Weg aus getrennten iOS und Android Apps plus Marketing Website liegt bei £110.000 bis £250.000 für den Aufbau und danach bei £35.000 bis £80.000 im Jahr. Das sind Bänder britischer Agenturen und keine Angebote, und der wiederkehrende Unterschied wiegt meist schwerer als der beim Aufbau.

Kann man eine PWA in den App Store oder zu Google Play bringen? Zu Google Play ja, in den App Store nein. Auf Android hüllt eine Trusted Web Activity Ihre PWA in eine dünne native Schicht, über Digital Asset Links verifiziert, sodass dieselbe Codebasis für ein paar Tage Verpackungsarbeit einen Play Eintrag bekommt. Apple hat kein Gegenstück, und seine Prüfrichtlinien behandeln eine Hülle um eine Website als unzureichend, eine Präsenz im App Store bedeutet also, etwas wirklich Natives zu bauen.

Wann sollte man eine native App statt einer PWA wählen? Wählen Sie nativ, wenn Sie Standortverfolgung im Hintergrund bei geschlossener App brauchen, Widgets auf dem Home Bildschirm, Einbindungen für Uhr oder Auto, Bluetooth oder NFC auf dem iPhone, HealthKit oder Apple Pay in der App, anhaltend schwere Berechnung wie Videoverarbeitung in Echtzeit, oder Präsenz im App Store als echten Kanal der Akquise. Trifft nichts davon zu, ist eine PWA sehr wahrscheinlich richtig, und die Beweislast liegt bei dem, der drei Codebasen pflegen will.