Zum Inhalt springen
MARCODES
Abstraktes Relief aus dunklem Papier: zwei Formen mit gleichem Umriss, eine hohle Schale und ein massiver Block

PWA oder native App: Was passt zu Ihrem Vorhaben?

Ob PWA oder native App, entscheidet sich an den Gerätefunktionen: Eine Progressive Web App reicht, wenn Ihre Anwendung mit Formularen, Listen, Offline-Daten und Push-Nachrichten auskommt. Braucht sie Bluetooth, NFC, Hintergrundortung oder einen Platz im App Store, führt der Weg zur nativen oder hybriden App.

8 min Lesezeit Performance & DevOps

Die Frage stellt sich meist früher, als man denkt: beim ersten Gespräch über ein Kundenportal, eine Außendienst-Anwendung oder eine Buchungsstrecke fürs Smartphone. Eine falsche Wahl kostet doppelt. Wer zu früh in die Stores geht, bezahlt Konten, Prüfungen und zwei Auslieferungswege für Funktionen, die der Browser auch kann. Wer zu lange beim Web bleibt, baut später um, weil eine Gerätefunktion fehlt. Der Vergleich unten hilft, die Anforderungen Ihres Vorhabens vor dem ersten Angebot richtig einzuordnen.

Vergleich

PWA, hybride und native App im Vergleich

Drei Bauarten stehen zur Wahl. Eine PWA ist eine Website mit Web-App-Manifest und Service Worker, die Nutzer auf den Startbildschirm legen. Eine hybride App ist eine Web-Anwendung in einer nativen Hülle, etwa mit Capacitor. Eine native App wird getrennt für iOS (Swift) und Android (Kotlin) programmiert.

Für Portale, Formulare, Kataloge, Termin- und Auftragslisten reicht in vielen Fällen die PWA. Sobald eine Funktion aus dem Abschnitt zu nativen Funktionen auf Ihrer Pflichtliste steht, ist die hybride App meist der günstigere Weg als zwei native Apps, weil Oberfläche und Logik nur einmal entstehen und nur die Gerätefunktionen nativ programmiert werden.

Passt, wenn Aufwand und Grenzen
Progressive Web App Formulare, Listen, Kataloge, Termine, Offline-Daten und Push-Nachrichten genügen Ein Code, keine Stores, Updates sofort bei allen; auf iOS kein Bluetooth, kein NFC, kein Hintergrundbetrieb
Hybride App (Capacitor) Einzelne Gerätefunktionen oder ein Store-Eintrag nötig sind, die Oberfläche aber Web-Technik bleiben kann Ein Code für beide Stores, native Plugins nur für Gerätefunktionen; Konten, Signaturen und Store-Prüfungen
Native App Viele Funktionen tief ins System greifen, etwa Navigation, Kamera-Auswertung in Echtzeit oder Widgets Zwei Codebasen, voller Gerätezugriff, doppelter Aufwand für jede Änderung

Webfähigkeiten

Was eine PWA auf iOS und Android kann

Auf Android ist die PWA seit Jahren gut unterstützt. Chrome bietet die Installation an, Push-Nachrichten funktionieren, und über eine Trusted Web Activity lässt sich die PWA sogar im Play Store veröffentlichen. Die Grenzen setzt iOS.

Apple hat in den vergangenen Jahren deutlich aufgeholt:

  • Push-Nachrichten: Seit iOS und iPadOS 16.4 (2023) können Web-Apps Push-Benachrichtigungen senden, allerdings nur, wenn sie auf dem Startbildschirm liegen. Die Erlaubnis muss der Nutzer durch eine eigene Aktion anfordern, etwa durch Tippen auf „Benachrichtigungen aktivieren“. Mit derselben Version kam die Zahl am App-Symbol (Badging).

  • Startbildschirm: Seit iOS 26 (September 2025) öffnet sich jede Website, die ein Nutzer zum Startbildschirm hinzufügt, standardmäßig als Web-App. Vorher war dafür ein passend konfiguriertes Manifest nötig.

  • EU-Episode: Anfang 2024 kündigte Apple an, Web-Apps auf dem Startbildschirm mit iOS 17.4 in der EU zu entfernen, und begründete das mit dem Digital Markets Act. Anfang März 2024 nahm Apple das zurück. Die Funktion blieb, das Vertrauen mancher Auftraggeber in die Plattform hat gelitten.

Für Offline-Anwendungen zählt eine Regel von Safari: Der Browser löscht Daten, die eine Website per Skript speichert, also IndexedDB, LocalStorage und den Speicher des Service Workers, wenn der Nutzer die Seite sieben Tage lang im Browser nicht aufgerufen hat. Für Web-Apps auf dem Startbildschirm gilt diese Regel laut WebKit nicht, sie haben einen eigenen Zähler. Wer eine Außendienst-Anwendung im normalen Safari-Tab nutzt, kann also nach einem Urlaub ohne die offline gespeicherten Daten dastehen. Bitten Sie Nutzer deshalb ausdrücklich, die Anwendung zum Startbildschirm hinzuzufügen, und speichern Sie offline Erfasstes so früh wie möglich auf dem Server.

Gerätezugriff

Wo native Funktionen den Ausschlag geben

Einige Funktionen gibt es im Browser auf iOS nicht oder nur eingeschränkt. Steht eine davon auf Ihrer Liste, kommen Sie an einer App aus dem Store kaum vorbei:

  • Bluetooth und NFC: Die Web-Bluetooth- und Web-NFC-Schnittstellen unterstützt Safari nicht. Für Messgeräte, Scanner oder Zutrittskarten brauchen Sie native Plugins.

  • Hintergrundbetrieb: Ortung im Hintergrund, Geofencing oder lange Synchronisationen bei geschlossener App sind im Web nicht verlässlich möglich.

  • Adressbuch und Kalender: Über die Contact Picker API kann ein Nutzer in Chrome für Android einzelne Kontakte auswählen und an die Web-App übergeben. Das Adressbuch lesen oder abgleichen kann eine Web-App nicht, auf keiner Plattform.

  • Store-Präsenz: Manche Zielgruppen suchen Anwendungen nur im App Store, und manche Unternehmen verteilen Software ausschließlich über ihre Geräteverwaltung.

  • Wallet und tiefe Systemintegration: Pässe für Apple Wallet lassen sich auch aus dem Web anbieten, Widgets und Siri-Kurzbefehle nicht. Inhalte in andere Apps teilen kann eine Web-App über die Web Share API, Safari unterstützt sie seit iOS 12.2. Umgekehrt als Ziel im Teilen-Menü zu erscheinen, damit Nutzer zum Beispiel ein Foto aus der Galerie an die Web-App schicken, erlaubt die Web Share Target API nur in Chromium-Browsern, etwa Chrome für Android, nicht auf iOS.

Wie eindeutig eine einzige Gerätefunktion entscheiden kann, zeigt beeSmart, eine App zum Ablesen von Messgeräten für die imm INNOVATION GmbH & Co. KG. Servicetechniker scannen im Keller einen NFC-Tag am Zähler, tragen den Wert ein und synchronisieren später, weil dort oft kein Netz ist. NFC allein schloss die PWA aus. Gebaut wurde eine hybride App mit Ionic, Angular und Capacitor, die Projektlaufzeit lag bei drei Monaten. Weil die Techniker mit Android-Geräten arbeiten, liegt der Schwerpunkt auf Android.

Dass beides nebeneinander bestehen kann, zeigt ein zweites Projekt. Für Cardeleine, eine Plattform für digitale Visitenkarten, betreuen wir eine Browser-PWA mit Offline-Strategie über Service Worker und zusätzlich eine native iOS- und Android-App auf Basis von Capacitor. Die App bringt zwei eigenentwickelte Plugins für Barcode-Scanning und den Abgleich mit dem Adressbuch mit, dort, wo Standardlösungen nicht reichten.

Für Ihre eigene Entscheidung hilft eine kurze Übung: Schreiben Sie jede geplante Funktion in eine Zeile und markieren Sie, ob sie ein Gerät, den Hintergrundbetrieb oder den Store braucht. Bleibt die Spalte leer, starten Sie mit der PWA. Gibt es eine oder zwei Markierungen, prüfen Sie, ob es dafür fertige Capacitor-Plugins gibt. Erst wenn viele Funktionen tief ins System greifen, etwa bei Navigation, Kamera-Auswertung in Echtzeit oder umfangreichen Widgets, wird eine rein native App wirtschaftlich, denn dann entsteht ohnehin der größte Teil des Codes nativ, und die Web-Schicht bringt keinen Vorteil mehr.

Aus einem gemeinsamen Stapel Codeplatten führen orange gestrichelte Verbindungen zu zwei gleichen Smartphones.

Hybrid

Hybrid mit Capacitor: ein Code, zwei Stores

Capacitor ist eine quelloffene Laufzeit des Ionic-Teams. Sie packt eine Web-Anwendung in eine native Hülle für iOS und Android und macht Gerätefunktionen über Plugins zugänglich. Version 8 ist seit Dezember 2025 verfügbar.

Für eine hybride App spricht vor allem, dass die vorhandene Web-Anwendung weiterlebt. Oberfläche und Logik bleiben Web-Technik, ob mit Ionic, Angular, Vue oder ohne Framework. Native Teile kommen nur dort dazu, wo sie gebraucht werden. Gibt es für eine Gerätefunktion kein fertiges Plugin, entsteht ein eigenes in Swift und Kotlin, mit klar abgegrenzter Schnittstelle zur Web-Schicht.

Drei Dinge sollten Sie vorher wissen:

  • Native Kenntnisse bleiben nötig. Xcode, Android Studio, Signaturzertifikate und Plugin-Updates gehören zum Alltag, auch wenn der größte Teil des Codes Web-Technik ist.

  • Eine reine Website in der Hülle reicht Apple nicht. Richtlinie 4.2 der App-Store-Prüfung verlangt Funktionen und Inhalte, die über eine verpackte Website hinausgehen.

  • Größere Versionssprünge kosten Zeit. Wer von Cordova auf Capacitor wechselt oder eine Hauptversion von Capacitor überspringt, plant Plugin für Plugin. Bei Cardeleine wurden die Cordova-Plugins schrittweise migriert, ohne den laufenden Betrieb zu stören.

Betrieb

Kosten im Betrieb: Updates, Prüfungen, Konten

Der größte Unterschied zwischen den Bauarten zeigt sich nicht beim Bau, sondern in den Jahren danach.

  • Konten: Eine PWA braucht keine. Für die Stores brauchen Sie das Apple Developer Program für 99 US-Dollar im Jahr und ein Google-Play-Konto für einmalig 25 US-Dollar.

  • Updates: Eine PWA ist beim nächsten Aufruf aktuell. Eine App aus dem Store geht mit jeder Version durch die Prüfung von Apple und Google, und Nutzer müssen aktualisieren.

  • Fehlerbehebung: Einen Fehler in der PWA beheben Sie mit einer Auslieferung. In der Store-App bleibt die fehlerhafte Version installiert, bis die neue geprüft und beim Nutzer angekommen ist. Wer Inhalte und Logik vom Server lädt, verkürzt diesen Weg.

  • Jährliche Pflicht: Neue iOS- und Android-Versionen und die Mindestvorgaben der Stores verlangen jedes Jahr Anpassungen und neue Builds, auch wenn sich an der App fachlich nichts ändert.

Eine vorhandene, saubere PWA als hybride App in beide Stores zu bringen, dauert nach unserer Einschätzung eher Wochen als Tage, weil Konten, Signaturen, Store-Texte und die erste Prüfung Zeit brauchen, nicht der Code. Laufend kommen einige Personentage im Jahr für Betriebssystem- und Plugin-Updates dazu. Welche Pakete wir für mobile Vorhaben anbieten, steht auf der Seite Apps für iOS und Android. Ob es überhaupt eine Single-Page-App sein muss, beleuchtet der Beitrag Single-Page-App: nicht immer die Lösung.

Kurz beantwortet

Häufige Fragen

  • Auf Android seit Langem, auf iPhone und iPad seit iOS 16.4. Auf Apple-Geräten muss die Web-App dafür auf dem Startbildschirm liegen, und der Nutzer muss die Erlaubnis durch eine eigene Aktion erteilen. Im normalen Safari-Tab bleiben Push-Nachrichten auf iOS aus.

  • Für Oberfläche und Logik nicht, sie teilen sich eine Web-Codebasis. Eigener Code für iOS und Android entsteht nur in Plugins für Gerätefunktionen, für die es keine fertige Lösung gibt. Projektdateien, Signaturen und Store-Einstellungen pflegen Sie trotzdem je Plattform.

  • Das ist ein häufiger Weg. Mit Capacitor wird die vorhandene Web-Anwendung in eine native Hülle gepackt und um Plugins ergänzt. Voraussetzung ist eine saubere Trennung von Oberfläche und Schnittstelle, damit Web-App und Store-App dieselbe API nutzen.

Bauart klären, bevor gebaut wird

Wir gehen Ihre Funktionsliste durch und sagen Ihnen, ob eine PWA reicht oder welche Teile eine App brauchen.

Zu unseren Apps

Nachweise

Quellen und Stand

Stand: 09.06.2026. Versionen und Funktionen laut Dokumentation von Apple, WebKit, MDN, Google und Ionic.

Artikel teilen