PWA oder native App? Unterschiede und Entscheidungshilfe

Ob eine PWA oder native App besser zu Ihrem Vorhaben passt, entscheiden vor allem drei Punkte: welche Gerätefunktionen die App braucht, ob Nutzer sie im App Store und bei Google Play finden müssen und welche Folgekosten Sie tragen wollen. Eine PWA (Progressive Web App) läuft im Browser, lässt sich auf den Startbildschirm legen und geht ohne Store-Prüfung online. Eine Store-App kommt an mehr Gerätefunktionen heran, bringt aber Gebühren, Prüfungen und Pflicht-Updates mit.

Grundlage sind die Vorgaben von Apple und Google, die Entwicklerdokumentation MDN und Angaben von WebKit, der Browser-Engine von Safari. Dazu kommen unsere eigene Praxis mit einer mobil genutzten Web-App und die Erfahrung unseres Gründers mit einer Store-App aus einem eigenen, inzwischen eingestellten Projekt außerhalb von Amperbyte AI.

Stand der Store-Vorgaben: 8. Oktober 2026

Apple und Google passen ihre Vorgaben laufend an. Prüfen Sie vor dem Start die verlinkten Seiten.

Web-App, PWA, Cross-Platform, nativ: die Begriffe

Im Alltag heißt fast alles „App“, und „native App“ steht oft für jede App aus dem Store. Für die Entscheidung lohnt es sich, vier Bauarten zu unterscheiden:

• Web-App: eine Anwendung im Browser, die sich auf Smartphone, Tablet und PC wie eine App bedienen lässt. Sie wird über eine Adresse aufgerufen, nicht installiert.
• PWA (Progressive Web App): eine Web-App, die laut MDN wie eine plattformspezifische App funktioniert: installierbar, offline nutzbar und mit dem Gerät verbunden (MDN, Progressive web apps, Stand 8. Oktober 2026). Für Offline-Betrieb braucht sie einen Service Worker, ein Skript, das im Hintergrund zwischen App und Netz vermittelt; auch Push-Nachrichten laufen meist darüber.
• Cross-Platform-App: eine Store-App für iOS und Android aus einer gemeinsamen Codebasis, etwa mit Flutter. Auf Gerätefunktionen greift sie über Erweiterungen (Plugins) zu.
• Native App: eine App, die für jede Plattform getrennt in deren eigener Sprache entsteht, für iOS meist in Swift, für Android meist in Kotlin. Sie hat den direktesten Zugang zur Plattform, braucht aber zwei Codebasen.

Eine hybride App ist meist eine Store-App, deren Weboberfläche in einem eingebauten Browserfenster (WebView) läuft; manche Anbieter nennen auch Cross-Platform-Apps so.

PWA vs. native App im Vergleich

Quellen: MDN, Push API, WebKit, Web Push unter iOS, WebKit, Declarative Web Push, WebKit, nicht umgesetzte Schnittstellen, App Review Guidelines, 2.5.6; Store-Vorgaben im übernächsten Abschnitt (alle Stand 8. Oktober 2026).

Zwischen Cross-Platform und nativ liegt der größte Unterschied im Aufwand: eine Codebasis statt zwei. Nativ lohnt sich vor allem, wenn eine App sehr tief in das Betriebssystem eingreift.

PWA unter iOS: Installation, Push und Grenzen

Installation. Bis iOS 16.3 ließ sich eine PWA nur mit Safari auf den Startbildschirm legen. Seit iOS 16.4 geht das über das Teilen-Menü in Safari, Chrome, Edge, Firefox und Orion (MDN, PWAs installierbar machen, Stand 8. Oktober 2026).

Push-Nachrichten. Seit iOS und iPadOS 16.4 kann eine Web-App, die auf den Startbildschirm gelegt wurde, um Erlaubnis für Push-Nachrichten bitten. Die Anfrage muss auf eine direkte Nutzeraktion folgen, etwa das Antippen einer Schaltfläche „Abonnieren“ (WebKit, Web Push für Web-Apps, Stand 8. Oktober 2026).

Gerätefunktionen. WebKit führt Schnittstellen auf, die es wegen Fingerprinting, Sicherheit und anderer Bedenken vorerst nicht umsetzt, darunter Web Bluetooth, Web NFC, Web USB und Ortung im Hintergrund (WebKit, Tracking Prevention, Stand 8. Oktober 2026). Fingerprinting heißt: Geräte anhand vieler Merkmale wiedererkennen. In Safari fehlen diese Funktionen also. Weil Browser auf dem iPhone nach Apples Richtlinie 2.5.6 WebKit nutzen müssen (Ausnahmen nur auf Antrag in der EU und in Japan), fehlen sie in der Regel auch in Chrome, Edge oder Firefox auf dem iPhone (App Review Guidelines, Stand 8. Oktober 2026). Wer auf dem iPhone Etiketten per NFC liest oder Messgeräte per Bluetooth anbindet, plant deshalb eine Store-App.

Was App Store und Google Play verlangen

Alle Punkte haben wir am 8. Oktober 2026 in den Primärquellen geprüft.

Apple App Store

• Gebühr: 99 US-Dollar pro Mitgliedsjahr im Apple Developer Program; der Preis kann je Region abweichen und erscheint bei der Anmeldung in Landeswährung (Apple, Anmeldung, Stand 8. Oktober 2026).
• Unternehmenskonto: Organisationen brauchen eine D-U-N-S-Nummer, ihr Name erscheint im App Store als Verkäufer (gleiche Quelle, Stand 8. Oktober 2026).
• Händlerangaben in der EU: Nach dem Digital Services Act gibt jedes Konto einen Händlerstatus an. Bei Händlern zeigt der App Store in der EU Adresse, Telefonnummer und E-Mail-Adresse auf der Produktseite (Apple, DSA-Anforderungen, Stand 8. Oktober 2026).
• Werkzeuge: Seit 28. April 2026 müssen hochgeladene Apps mit Xcode 26 oder neuer und einem SDK für iOS 26 gebaut sein (Apple, Upcoming Requirements, Stand 8. Oktober 2026).
• Datenschutz: Für jede neue App und jedes Update verlangt Apple Datenschutzangaben, auch zu Code von Drittanbietern, und eine Datenschutzerklärung (Apple, App Privacy Details, Stand 8. Oktober 2026). Gängige SDKs auf Apples Liste brauchen zusätzlich ein Privacy Manifest, eine Datei zu deren Umgang mit Daten (Apple, Drittanbieter-SDKs, Stand 8. Oktober 2026).
• Kontolöschung: Wer in der App Konten anlegen lässt, muss auch die Löschung in der App anbieten (Richtlinie 5.1.1(v) der App Review Guidelines, Stand 8. Oktober 2026).
• Prüfung: Apple prüft alle Apps und Updates, nach eigenen Angaben in der Regel 90 Prozent der Einreichungen in weniger als 48 Stunden (Apple, App Review, Stand 8. Oktober 2026).

Google Play

• Gebühr: einmalig 25 US-Dollar für die Registrierung (Play Console-Hilfe, Registrierung, Stand 8. Oktober 2026).
• Testpflicht für private Konten: Private Konten, die nach dem 13. November 2023 erstellt wurden, brauchen vor dem Produktionszugriff einen geschlossenen Test mit mindestens 12 Testpersonen über mindestens 14 Tage (Play Console-Hilfe, Testanforderungen, Stand 8. Oktober 2026). Ein Organisationskonto verlangt dagegen eine D-U-N-S-Nummer (Play Console-Hilfe, Kontoangaben, Stand 8. Oktober 2026).
• Ziel-API: Das Ziel-API-Level ist die Android-Version, auf die eine App ausgelegt ist. Seit 31. August 2026 müssen neue Apps und Updates Android 16 (API-Level 36) als Ziel haben. Bestehende Apps brauchen mindestens Android 15 (API-Level 35), um für neue Nutzer auf Geräten mit neuerem Android verfügbar zu bleiben. Auf Antrag gibt es eine Verlängerung bis 1. November 2026 (Android Developers, Ziel-API, Stand 8. Oktober 2026).
• Datensicherheit: Jede veröffentlichte App braucht ein ausgefülltes Formular zur Datensicherheit und eine Datenschutzerklärung, auch ohne Datenerhebung (Play Console-Hilfe, Datensicherheit, Stand 8. Oktober 2026).
• Kontolöschung: Apps mit Kontoerstellung müssen die Löschung in der App und zusätzlich über einen Weblink ermöglichen (Play Console-Hilfe, Kontolöschung, Stand 8. Oktober 2026).
• Prüfung: laut Google bei manchen Apps bis zu sieben Tage, in Ausnahmefällen länger (Play Console-Hilfe, Veröffentlichen, Stand 8. Oktober 2026).

Für die Planung heißt das: Legen Sie die Store-Konten auf Ihr Unternehmen an, nicht auf die Agentur, und nehmen Sie Fristen wie die Ziel-API in den Wartungsplan auf.

Eine PWA in den Store bringen?

Das geht, mit Einschränkungen. MDN nennt unter anderem Google Play und den iOS App Store als mögliche Ziele, etwa mit dem Werkzeug PWABuilder (MDN, PWAs installierbar machen, Stand 8. Oktober 2026).

Google Play. Google beschreibt dafür die Trusted Web Activity: eine Android-App, die Ihre PWA über den Browser des Nutzers im Vollbild anzeigt. App und Website müssen per Digital Asset Links nachweislich vom selben Anbieter stammen, und laut Google ist damit zu rechnen, dass die Inhalte dieselben Anforderungen erfüllen müssen wie für das Ablegen auf dem Startbildschirm (Android Developers, Trusted Web Activities, Stand 8. Oktober 2026). Die App-Hülle unterliegt dann den Store-Pflichten oben, etwa der Ziel-API.

App Store. Apples Richtlinie 4.2 verlangt Funktionen, Inhalte und Bedienung, die eine App über eine neu verpackte Website hinausheben. Nach 4.2.2 sollen Apps nicht überwiegend aus Web-Ausschnitten, Linksammlungen oder Werbematerial bestehen (App Review Guidelines, Stand 8. Oktober 2026). Eine PWA in einer bloßen App-Hülle riskiert hier die Ablehnung. Wer in den App Store will, plant echte App-Funktionen ein oder gleich eine Cross-Platform-App.

Aus der Praxis: eine mobile Web-App und eine Store-App

Unsere eigene Web-App: mobil zuerst

Unsere eigene Videochat-Conversational-AI ist eine Web-App für Endkunden, die wir selbst entwickeln und betreiben. Den Produktnamen nennen wir hier nicht, weil es sich an Endkunden richtet. Rund 75 Prozent der Erstbesuche kommen laut unserer Web-Analyse vom Smartphone (8. September bis 5. Oktober 2026). Die Anwendung läuft im Browser und ist keine PWA: Sie hat keinen Service Worker, funktioniert also nicht offline, und sie verschickt keine Push-Nachrichten. Zwei Lehren daraus gelten für jede Web-App:

Ältere iPhones mitdenken. Ein regulärer Ausdruck mit Lookbehind, einem Suchmuster für den Text vor einer Stelle, ließ die App unter iOS 15 bis 16.3 nie interaktiv werden: Safari vor Version 16.4 verwirft dann das ganze JavaScript-Modul. Seitdem verbietet eine Prüfung im Build solche Ausdrücke. Eine Web-App erbt die Grenzen des Browsers auf dem Gerät.

Auf langsamen Verbindungen messen. Bei 1,6 Mbit/s dauerte es rund 21 Sekunden bis zum ersten Videobild, weil im Hintergrund noch andere Videodateien luden. Seit diese Downloads beim Start des Gesprächs abgebrochen werden, sind es rund 7,5 Sekunden.

Deshalb entwickeln und testen wir zuerst im Smartphone-Format, Android vor dem iPhone. Mehr dazu steht im Artikel Chatbot mit Avatar und im Praxisbeispiel Videochat-Conversational-AI.

Eine Store-App aus dem Projekt unseres Gründers

Den Store-Weg kennt unser Gründer aus einem eigenen App-Projekt, das vor der Gründung von Amperbyte AI begann und nicht in ihrem Auftrag lief: eine Cross-Platform-App mit Flutter und Firebase für iOS und Android. Er hat sie auf Basis eines lizenzierten Quellcodes verantwortet, mitentwickelt und mit freien Entwicklern umgesetzt. Sie war im App Store und bei Google Play verfügbar, wurde über mehr als ein Jahr mit Pflicht-Updates gepflegt und ist inzwischen eingestellt. Zwei Punkte lassen sich direkt übertragen:

• Pflicht-Updates kommen von außen. Dazu gehörten neue Ziel-API-Vorgaben von Google Play und die Umstellung auf eine neue Schnittstelle von Firebase Cloud Messaging, dem Push-Dienst von Firebase. Solche Arbeiten stehen in keinem Funktionswunsch, aber in jedem Wartungsplan.
• Der Store-Weg hat Vorlauf. Konten, Store-Einträge, Datenschutzangaben, Tests mit Beta-Testern und die Prüfung durch Apple und Google gehören in den Zeitplan vor der ersten Version.

Unser Schluss daraus: Eine Store-App ist ein Produkt mit laufendem Pflegeaufwand, kein einmaliges Projekt.

Entscheidungshilfe in fünf Fragen

1. Braucht die App Gerätefunktionen, die der Browser nicht bietet? Bluetooth, NFC oder USB auf dem iPhone, Ortung im Hintergrund oder eine enge Einbindung ins Betriebssystem sprechen für eine Store-App. Prüfen Sie jede Funktion bei MDN und WebKit für die Browser Ihrer Zielgruppe.
2. Müssen Nutzer die App im Store finden? Kommen sie über Website, Link, QR-Code oder Einladung, braucht es keinen Store. Das gilt oft für interne Anwendungen im Außendienst oder Lager, etwa eine Web-App für die mobile Erfassung, die an Ihre bestehenden Systeme angebunden ist.
3. Brauchen Sie Push-Nachrichten auf dem iPhone? Eine PWA erreicht dort nur Nutzer, die sie auf den Startbildschirm gelegt haben. Ist Push zentral, etwa für Terminerinnerungen, ist die Store-App der direktere Weg.
4. Wie oft ändern sich Inhalte und Abläufe? Wer häufig ausliefert, spart mit einer Web-App oder PWA die Store-Prüfung bei jeder Version.
5. Wer trägt die Folgekosten? Store-Gebühren, Pflicht-Updates, Datenschutzangaben und Kontolöschung kommen zu Hosting und Wartung hinzu. Planen Sie dafür ein laufendes Budget ein.

Führt Frage 1 oder 2 zur Store-App, ist eine Cross-Platform-App aus einer Codebasis meist der wirtschaftliche Weg. Sonst beginnen Sie mit einer Web-App oder PWA, die wir etwa mit Vue.js und Nuxt bauen; eine Store-App lässt sich später ergänzen. Halten Sie Ihre Antworten in einem Lastenheft fest, dann vergleichen Sie Angebote auf derselben Grundlage.

Pflichten gegenüber Verbrauchern hängen nicht an der Bauart. Das Barrierefreiheitsstärkungsgesetz gilt nach § 1 Abs. 3 Nr. 5 BFSG für Dienstleistungen im elektronischen Geschäftsverkehr. § 2 Nr. 26 BFSG beschreibt sie als Dienste „über Webseiten und über Anwendungen auf Mobilgeräten“, die im Hinblick auf einen Verbrauchervertrag erbracht werden. Kleinstunternehmen sind bei Dienstleistungen ausgenommen (§ 3 Abs. 3 BFSG; Rechtsstand 7. Oktober 2026, keine Rechtsberatung). Wen das betrifft, beschreibt der Artikel Barrierefreie Website: Wen das BFSG trifft.

Fazit

PWA oder native App ist weniger eine Technikfrage als eine Frage nach Gerätefunktionen, Auffindbarkeit und Betrieb. Eine Web-App oder PWA ist sofort aktualisiert, kommt ohne Store-Gebühren aus und reicht für viele Anwendungen im Unternehmen. Auf dem iPhone hat sie Grenzen: Push nur vom Startbildschirm, kein Bluetooth, NFC oder USB. Eine Store-App öffnet diese Funktionen und die Stores, verlangt aber Konten, Prüfungen und Pflicht-Updates nach dem Takt von Apple und Google.

Wenn Sie vor dieser Entscheidung stehen, sagen wir Ihnen offen, welche Bauart Ihr Vorhaben braucht, und setzen es als Web-App, PWA oder Store-App mit Flutter um. Wie wir vorgehen, beschreibt unsere Seite App-Entwicklung in München. Schildern Sie uns Ihr Vorhaben gern über die Kontaktseite.