PWA oder native App 2026: welche Variante passt zu Ihrem Produkt?

Wovon hängt die Wahl zwischen PWA und nativer App ab?

Von drei Größen: wie tief die Anwendung auf Gerätefunktionen zugreift, ob Ihre Kunden Präsenz im App Store erwarten und wie viel Budget nach der ersten Version noch für Pflege übrig bleibt. Für inhaltsgetriebene Geschäftsanwendungen trägt eine PWA 2026 weiter, als die meisten Lastenhefte annehmen. Bei Hardwarezugriff bleibt nativ gesetzt.

Eine Progressive Web App ist eine Webanwendung, die sich installieren lässt, offline funktioniert und Benachrichtigungen zustellen darf. Die Frage ist also nicht mehr, ob das technisch geht. Die Frage ist, welche der verbliebenen Lücken Ihr konkretes Produkt trifft und was die zweite Codebasis über fünf Jahre kostet.

Was kann eine PWA nach heutigem Stand?

Eine PWA kann installiert werden, ohne Netz starten, auf Kamera und Standort zugreifen und Push-Nachrichten empfangen. Unter Chromium kommen Dateisystemzugriff, Bluetooth sowie NFC dazu. Getragen wird das von zwei Bausteinen: einem Service Worker für Netzwerk und Cache und einem Manifest, das dem Betriebssystem sagt, wie die installierte App aussehen soll.

• Der Service Worker läuft als eigenes Skript zwischen Anwendung und Netz und beantwortet Anfragen auch dann, wenn keine Verbindung besteht
• Das Web App Manifest legt Symbol, Name, Startadresse und Anzeigemodus fest; ohne den Modus standalone oder fullscreen bleibt die Installation ein Lesezeichen
• HTTPS ist Voraussetzung, weil ein Service Worker sonst gar nicht registriert wird

Die erweiterten Gerätefunktionen stammen aus Project Fugu, der gemeinsamen Arbeit von Google, Microsoft und Intel an neuen Web-Schnittstellen. Dort finden Sie den Zugriff auf das Dateisystem, Web Bluetooth, WebUSB, die Symbol-Badges und die Fensterverwaltung. Der Haken steht im Kleingedruckten: Diese Schnittstellen sind Chromium-Funktionen. Auf dem iPhone rendert jeder Browser mit WebKit, und dort fehlen sie.

Wie weit trägt eine PWA unter iOS?

Weiter als ihr Ruf. Seit iOS und iPadOS 16.4 empfangen installierte Web-Apps Push-Nachrichten, wie Apple im WebKit-Blog beschreibt. Die Bedingungen sind klar benannt: Installation auf dem Home-Bildschirm, Anzeigemodus standalone oder fullscreen im Manifest, und die Erlaubnisabfrage nur nach einer direkten Nutzeraktion wie dem Tippen auf eine Schaltfläche.

Genau diese Bedingung wird in Projekten regelmäßig übersehen. Wer die Berechtigung beim ersten Seitenaufruf abfragt, bekommt unter iOS gar keinen Dialog zu sehen und hält die Funktion für kaputt. Apple erlaubt außerdem Drittbrowsern mit der entsprechenden Berechtigung, Web-Apps zum Home-Bildschirm hinzuzufügen, und für Web Push ist keine Mitgliedschaft im Apple Developer Program nötig. Beides steht in derselben offiziellen Ankündigung.

Was bleibt, ist der Abstand bei den hardwarenahen Schnittstellen. Für ein Kundenportal, einen Shop oder ein internes Werkzeug spielt er keine Rolle. Für eine App, die ein Bluetooth-Gerät steuert, entscheidet er die Frage bereits.

Wo liegt der Leistungsunterschied wirklich?

Beim ersten Start und bei grafikintensiven Aufgaben. Danach nivelliert der Cache den Unterschied. In Listen, Formularen und Detailansichten nehmen Anwender keinen Abstand wahr, sofern die PWA sauber gebaut ist. Wo es um Bildraten in Spielen oder um Kameraverarbeitung in Echtzeit geht, gewinnt nativ deutlich.

Die Auslieferungsgröße ist der unterschätzte Teil dieser Rechnung. Die Starbucks-PWA wiegt nach Angaben des ausführenden Entwicklungspartners 233 KB gegenüber 148 MB der nativen iOS-App. Bei Twitter Lite waren es 600 KB gegenüber 23,5 MB der Android-App. In Gebieten mit schwachem Netz und auf älteren Geräten ist das kein Randthema, sondern der Unterschied zwischen Nutzung und Abbruch.

Was kostet der Unterschied in Euro?

Der sichtbare Teil sind Store-Gebühren und Provisionen, der teure Teil ist die zweite Codebasis. Apple verlangt 99 USD im Jahr für das Entwicklerprogramm, Google 25 USD einmalig für das Play-Konto. Beides fällt kaum ins Gewicht. Die Provision auf Käufe und der doppelte Pflegeaufwand tun es sehr wohl.

Unsere veröffentlichten Spannen für die beiden Wege sehen so aus. Die App-Pakete setzen eine geteilte Codebasis für iOS und Android voraus; zwei strikt native Projekte liegen darüber, weil Sie Fachlogik und Tests doppelt bezahlen.

Warum der Posten in Deutschland schwerer wiegt als anderswo, zeigt der Stundensatz. Der Freelancer-Kompass 2026 nennt für Softwareentwicklung im DACH-Raum einen Median von 90 EUR pro Stunde, über alle IT-Bereiche 95 EUR. Das ist kein Agenturpreis, taugt aber als Größenordnung: Jede zusätzliche Codebasis kostet Stunden, und Stunden sind hier teuer. Die vollständige Kostenaufschlüsselung steht im Beitrag Was kostet eine App 2026.

App Store oder Web: welcher Vertriebsweg passt?

Der Store liefert Auffindbarkeit im Suchverhalten mobiler Nutzer, ein eingebautes Bezahlsystem und ein Vertrauenssignal. Das Web liefert Zugang ohne Installation, sofortige Updates und Indexierbarkeit. Wer eine kurze Kette vom Klick zur ersten Nutzung braucht, gewinnt im Web. Wer Wiederkehr und Abo-Erlöse braucht, oft im Store.

Die Freigabezeit ist der Punkt, an dem sich die Wege im Alltag am stärksten unterscheiden. Ein kritischer Fehler in einer Web-Anwendung ist behoben, sobald das Deployment durch ist. Derselbe Fehler in einer nativen App braucht einen Build, eine Einreichung und die Geduld, bis die Prüfung durch ist. Für Produkte, die sich wöchentlich verändern, ist das ein handfester operativer Vorteil.

Welche Zahlen liefern dokumentierte Umstellungen?

Drei Umstellungen sind öffentlich mit Zahlen belegt. Sie stammen aus den Jahren 2017 und 2018, sind also keine Momentaufnahme von heute, aber sie zeigen die Richtung des Effekts: Reichweite und Nutzung steigen dort, wo die Installationshürde wegfällt.

Bei Twitter Lite lag der erste Aufruf im 3G-Netz unter fünf Sekunden, die Zahl der gesendeten Tweets stieg um 75 Prozent, die Absprungrate fiel um 20 Prozent, und 250.000 Anwender starteten die App täglich vom Home-Bildschirm. Pinterest berichtet für dasselbe Modell eine um 296 Prozent längere Sitzungsdauer und eine Reduktion des JavaScript-Pakets von rund 490 KB auf 190 KB.

Gegenbeispiele gehören dazu. Spotify und Instagram sind aus guten Gründen nativ geblieben: Musikwiedergabe im Hintergrund und tiefer Kamerazugriff für Stories sind genau die Bereiche, in denen eine PWA bis heute nicht verlässlich liefert. Wer diese Anforderungen im Lastenheft stehen hat, muss die Kostenrechnung gar nicht erst aufmachen.

Welche rechtlichen Punkte gelten in Deutschland?

Drei Themen tauchen in deutschen Beschaffungsprozessen verlässlich auf: die Einwilligung für Speicherzugriffe auf dem Endgerät, die Barrierefreiheit im elektronischen Geschäftsverkehr und der Auftragsverarbeitungsvertrag. Die Technologiewahl entscheidet keinen dieser Punkte, verschiebt aber den Prüfaufwand.

Einwilligung nach § 25 TDDDG

§ 25 TDDDG verlangt eine Einwilligung, bevor Informationen auf dem Endgerät gespeichert oder ausgelesen werden. Absatz 2 nimmt davon aus, was zur Bereitstellung eines vom Nutzer ausdrücklich gewünschten Dienstes unbedingt erforderlich ist. Ein Service-Worker-Cache, der die Anwendung offline lauffähig hält, fällt nach unserer Einschätzung unter diese Ausnahme; ein Cache für Analysezwecke nicht. Wir dokumentieren deshalb je Cache-Eintrag den Zweck, damit Ihre Datenschutzabteilung nicht schätzen muss. Eine Rechtsberatung ersetzt das nicht.

Barrierefreiheit seit dem 28. Juni 2025

Das Barrierefreiheitsstärkungsgesetz erfasst nach § 1 unter anderem Dienstleistungen im elektronischen Geschäftsverkehr, die nach dem 28. Juni 2025 erbracht werden. Für die Entscheidung heißt das: Der Aufwand fällt in jedem Fall an, aber bei einer PWA prüfen Sie eine Oberfläche mit dem üblichen Web-Werkzeugkasten, bei zwei nativen Apps prüfen Sie zwei Oberflächen mit plattformeigenen Werkzeugen. Der Unterschied wiederholt sich bei jeder größeren Änderung.

Auftragsverarbeitung und Quellcode

Der Vertrag nach Art. 28 DSGVO gehört bei uns zum Standardpaket. Bei nativen Apps kommt ein Punkt dazu, der in Angeboten oft fehlt: die Liste der Drittanbieter-SDKs für Absturzberichte, Analytics und Push. Jedes dieser SDKs ist ein möglicher Datenempfänger und gehört ins Verzeichnis von Verarbeitungstätigkeiten. Eine PWA hat diese Kette kürzer, weil sie ohne Store-Infrastruktur auskommt. Der Quellcode liegt in beiden Fällen nach Projektende in einem Repository unter Ihrer Kontrolle, bei nativen Apps zusammen mit den Signaturschlüsseln.

Wann PWA, wann nativ, wann hybrid?

Die Zuordnung lässt sich in einer Tabelle erledigen, weil die Trennlinie technisch und nicht geschmacklich verläuft. Prüfen Sie zuerst den Hardwarezugriff und die Hintergrundverarbeitung. Fällt beides unauffällig aus, gewinnt die geteilte Codebasis über die Betriebskosten.

Der hybride Weg ist häufiger die richtige Antwort, als das Duell im Titel vermuten lässt. Sie bauen den Funktionskern als Webanwendung und verpacken ihn dort nativ, wo eine Schnittstelle fehlt. Welche Frameworks dafür infrage kommen, haben wir im Vergleich native oder Cross-Platform-Apps und in der Gegenüberstellung React Native oder Flutter aufgeschrieben. Wenn Sie den PWA-Weg gehen, entscheidet die Ladezeit über den Erfolg; die Messgrößen dazu stehen im Beitrag zur Ladezeitoptimierung.

Was bleibt als Entscheidungsgrundlage?

Zwei Fragen tragen die Entscheidung. Greift Ihre Anwendung tief in die Hardware, und erwarten Ihre Kunden die Installation aus dem Store? Fällt die Antwort auf beides verneinend aus, ist die PWA der wirtschaftlichere Weg. Bleibt eine der Antworten bejahend, rechnet sich der native Aufwand trotz höherer Erstkosten.

Wenn Sie unsicher sind, welcher Weg zu Ihrem Vorhaben passt: Schildern Sie uns die Anforderungen über das Angebotsformular. Wir antworten innerhalb von 24 Stunden mit einer Empfehlung samt Begründung. Was wir sonst im Mobilbereich bauen, steht auf der Seite mobile App-Entwicklung.