Was ist der Unterschied zwischen Web-App, PWA und nativer App?
Der Unterschied liegt darin, wo die Anwendung läuft und wie sie auf das Gerät kommt: Eine Web-App läuft im Browser, eine PWA ist eine Web-App, die sich zusätzlich auf dem Startbildschirm installieren lässt, und eine native App wird für iPhone und Android gebaut und über die App-Stores verteilt.
Web-App
Eine Web-App ist eine Anwendung, die Sie über eine Internetadresse im Browser öffnen – auf dem Computer, dem Tablet oder dem Handy. Es gibt nichts zu installieren, und jede Änderung ist sofort bei allen Nutzern. Kundenportale, Buchungs- und Bestellstrecken und die meisten Verwaltungsprogramme sind heute Web-Apps.
Progressive Web App (PWA)
Eine PWA ist eine Web-App mit Zusatzfunktionen: Sie lässt sich vom Browser aus auf dem Startbildschirm ablegen, öffnet sich dann ohne Adressleiste wie eine App, kann Inhalte für die Nutzung ohne Verbindung zwischenspeichern und Push-Nachrichten empfangen. Auf iPhone und iPad funktionieren Push-Nachrichten für Web-Apps seit iOS 16.4 – und nur, wenn die Web-App zum Home-Bildschirm hinzugefügt wurde (WebKit-Blog, Februar 2023).
Native App
Eine native App wird für die Betriebssysteme iOS und Android entwickelt und über den App Store beziehungsweise Google Play installiert. Sie hat vollen Zugriff auf die Gerätefunktionen, auch im Hintergrund. Mit Cross-Plattform-Technik wie React Native entstehen beide Apps aus einer gemeinsamen Codebasis; technisch sind es trotzdem native Apps, die durch die Prüfung der Stores müssen.
Web-App, PWA und native App im Vergleich
Die Web-App ist am einfachsten zu verteilen und zu pflegen, die native App hat den vollen Zugriff auf das Gerät, und die PWA liegt dazwischen. Die Tabelle zeigt die Unterschiede, auf die es in Unternehmensprojekten meist ankommt.
| Kriterium | Web-App | PWA | Native App |
|---|---|---|---|
| Installation | keine; Aufruf über Link oder QR-Code | optional über den Browser auf den Startbildschirm | über App Store oder Google Play, für interne Apps auch andere Wege |
| Prüfung durch App-Stores | nicht nötig | nicht nötig | nötig, mit Entwicklerkonto |
| Updates | sofort für alle Nutzer | sofort für alle Nutzer | über die Stores; kleinere Korrekturen je nach Technik auch ohne Neuinstallation |
| Nutzung ohne Internet | in der Regel nicht | zwischengespeicherte Inhalte möglich, Umfang begrenzt | vollständig planbar |
| Push-Nachrichten | am Computer und unter Android möglich, auf dem iPhone nicht | ja; auf dem iPhone ab iOS 16.4 nach Installation auf dem Home-Bildschirm | ja |
| Standort | nur, solange die Seite geöffnet ist | nur, solange die App geöffnet ist | auch im Hintergrund, mit Erlaubnis des Nutzers |
| Kamera und QR-Scan | ja | ja | ja |
| Bluetooth und NFC | auf dem iPhone nicht verfügbar, unter Android in Chrome möglich | wie Web-App | ja |
| Entwicklungsaufwand (relativ) | niedrig | niedrig bis mittel | mittel bis hoch, je nach Zahl der Plattformen |
Die Angaben zu Bluetooth und NFC beruhen auf den Browser-Übersichten von Can I use (Web Bluetooth, Web NFC, Stand Oktober 2026). Browser entwickeln sich weiter; prüfen Sie Gerätefunktionen, die für Ihr Projekt entscheidend sind, deshalb vor dem Start.
Wann reicht eine Web-App?
Eine Web-App reicht, wenn Ihre Nutzer die Anwendung gezielt öffnen, um etwas nachzusehen, einzugeben oder zu bestellen, und wenn nichts im Hintergrund laufen muss. Das ist typisch, wenn:
- Nutzer über einen Link oder QR-Code kommen und nichts installieren sollen,
- die Anwendung überwiegend am Computer genutzt wird, etwa im Büro oder in der Disposition,
- Sie Änderungen sofort für alle ausrollen möchten, ohne Prüfung durch einen Store,
- sich die Gerätefunktionen auf Kamera, Datei-Upload und Standort im Moment der Nutzung beschränken.
Ein Beispiel ist unser eigenes Produkt Menu-Pro: Gäste scannen im Restaurant einen QR-Code und lesen die Speisekarte im Browser, automatisch übersetzt in acht Sprachen. Für einen Restaurantbesuch würde kaum jemand eine App installieren – eine native App wäre hier ein Hindernis. Wie das Produkt aufgebaut ist, zeigt das Praxisbeispiel Menu-Pro. Auch das Portal, das wir für den Kfz-Zulassungsdienst FIX-ZUGELASSEN entwickelt haben, ist eine reine Web-Anwendung: Kunden beauftragen die Zulassung im Browser und bezahlen online.
Wenn eine Web-App zu Ihrem Vorhaben passt, lesen Sie unter Web-App entwickeln lassen, was wir dafür übernehmen.
Wann ist eine PWA die richtige Mitte?
Eine PWA ist die richtige Mitte, wenn Nutzer die Anwendung regelmäßig wie eine App öffnen sollen und Benachrichtigungen oder ein kurzer Betrieb ohne Verbindung wichtig sind, eine native App aber zu aufwendig wäre.
Typisch sind Kunden- und Mitarbeiterportale, die mehrmals pro Woche genutzt werden. Die Gutachten-Software, die wir für ein Sachverständigenbüro entwickelt haben, hat zum Beispiel einen Web-Zugang, der sich auf dem Handy als App installieren lässt – ergänzend zum Desktop-Programm im Büro. Grenzen hat die PWA vor allem auf dem iPhone: Nutzer müssen sie selbst über das Teilen-Menü auf den Home-Bildschirm legen, bevor Push-Nachrichten ankommen, und Bluetooth oder NFC stehen im Browser dort nicht zur Verfügung.
Die entscheidende Frage: Muss etwas laufen, während die Anwendung geschlossen ist – Standort übermitteln, im Hintergrund abgleichen, mit einem Gerät per Bluetooth sprechen? Wenn ja, brauchen Sie eine native App. Wenn nein, reicht in den meisten Fällen eine Web-App oder PWA.
Wann ist eine native App nötig?
Eine native App ist nötig, wenn Gerätefunktionen zuverlässig im Hintergrund laufen müssen, wenn Sie Bluetooth, NFC oder andere Hardware ansprechen oder wenn Ihre Zielgruppe die App im Store suchen soll. Typische Anforderungen sind:
- Standortübermittlung, Zeiterfassung oder Datenabgleich auch bei geschlossener App,
- Verbindung zu Geräten per Bluetooth oder NFC, etwa Scanner, Messgeräte oder Schlösser,
- umfangreiche Datenerfassung ohne Netz, etwa auf Baustellen oder in Hallen ohne Empfang,
- Kunden-Apps, die im App Store oder bei Google Play gefunden werden sollen.
Ein Beispiel aus unserer Praxis: Bei einem Kran- und Schwerlastbetrieb sollten Mitarbeiter ihren Standort während der Schicht übermitteln. Mit der Web-App riss die Übermittlung ab, sobald Mitarbeiter die App schlossen. Deshalb haben wir eine eigene native Mitarbeiter-App entwickelt. Sie übermittelt den Standort etwa stündlich und nur während der Schicht, liest Tankbelege per Foto mit KI aus, übernimmt Fahrzeuge per QR-Etikett, empfängt Push-Benachrichtigungen und erhält Updates ohne Neuinstallation. Die Details stehen in der Fallstudie zur Betriebsplattform mit Mitarbeiter-App.
Im selben Projekt bestehen beide Wege nebeneinander: Die Lager-App läuft im Browser. Mitarbeiter scannen den QR-Code am Regal und buchen Entnahmen, Leihgaben und Wareneingänge, auch per Spracheingabe. Dafür muss nichts im Hintergrund laufen, also reicht der Browser. Wenn Ihr Vorhaben eine native App braucht, lesen Sie unter App entwickeln lassen, wie wir vorgehen.
Was ist bei App Store und Google Play zu beachten?
Für die Veröffentlichung brauchen Sie Entwicklerkonten bei Apple und Google, Store-Einträge mit Datenschutzangaben und Zeit für die Prüfung. Planen Sie diese Schritte von Anfang an ein:
- Apple: Die Mitgliedschaft im Apple Developer Program wird je Mitgliedsjahr bezahlt. Unternehmen brauchen für die Anmeldung eine D-U-N-S-Nummer und eine öffentlich erreichbare Website unter eigener Domain (Apple Developer: Voraussetzungen). Die D-U-N-S-Nummer ist im Kranbetrieb der Punkt, auf den die vorbereitete iPhone-Version der Mitarbeiter-App noch wartet.
- Google: Für ein Google-Play-Konto fällt eine einmalige Registrierungsgebühr an. Private Entwicklerkonten, die nach dem 13. November 2023 erstellt wurden, müssen eine App vor der Veröffentlichung mit mindestens 12 Testpersonen über mindestens 14 Tage testen (Google-Play-Hilfe zu Testanforderungen).
- Interne Apps: Eine App nur für eigene Mitarbeiter muss unter Android nicht in den Store; sie kann als Installationsdatei verteilt werden, so wie die Mitarbeiter-App im Kranbetrieb. Auf dem iPhone führen auch interne Apps über Apples Vertriebswege und ein Entwicklerkonto.
Gibt es Mischformen?
Ja: Viele Unternehmenslösungen kombinieren mehrere Formen, die auf denselben Server und dieselben Daten zugreifen. Häufige Varianten sind:
- Cross-Plattform-App: Eine Codebasis für iPhone und Android, zum Beispiel mit React Native. Das erspart einen großen Teil der doppelten Arbeit, die zwei getrennt entwickelte Apps verursachen würden, ohne auf native Funktionen zu verzichten.
- Web-Plattform plus App: Büro und Disposition arbeiten im Browser, Mitarbeiter unterwegs mit der App – wie im Kranbetrieb.
- Desktop, Web und App: Die Gutachten-Software verbindet ein offline-fähiges Windows-Programm für das Büro, einen Web-Zugang, der sich als PWA installieren lässt, und eine Kunden-App für Schadensmeldungen.
Wichtig für alle Mischformen: Die Geschäftsregeln gehören auf den Server, nicht in die einzelne App. Dann lässt sich später eine weitere Oberfläche ergänzen, ohne Regeln doppelt pflegen zu müssen.
Kann man später von der Web-App zur nativen App wechseln?
Ja, ein späterer Wechsel ist gut möglich, wenn der Server mit seinen Schnittstellen sauber von der Oberfläche getrennt ist. Dann bleiben Datenbank, Rechte und Geschäftsregeln erhalten, und nur die Oberfläche wird für die App neu gebaut. Auch im Kranbetrieb arbeitet die später entstandene native Mitarbeiter-App mit denselben Daten wie die Web-Plattform. Planen Sie diese Trennung deshalb schon beim Start ein, auch wenn Sie zunächst nur eine Web-App bauen.
Checkliste: Welche Form passt zu Ihrem Projekt?
Die folgenden Fragen geben Ihnen eine erste Richtung für das Gespräch mit einem Entwickler. Je öfter Sie bei den Fragen 1 bis 5 mit Ja antworten, desto eher brauchen Sie eine native App.
- Muss die Anwendung etwas tun, während sie geschlossen ist, etwa den Standort übermitteln?
- Soll sie mit Geräten per Bluetooth oder NFC kommunizieren?
- Wird sie oft ohne Internetverbindung genutzt, und müssen dabei Daten erfasst werden?
- Sollen Kunden die App im App Store oder bei Google Play finden?
- Sollen Push-Nachrichten auf dem iPhone ankommen, ohne dass Nutzer eine Web-App erst selbst installieren?
- Öffnen Nutzer die Anwendung nur gelegentlich, etwa über einen Link oder QR-Code?
- Wird sie überwiegend am Computer genutzt?
- Sollen Änderungen sofort bei allen Nutzern ankommen, ohne Prüfung durch einen Store?
- Möchten Sie zuerst eine Version mit wenig Aufwand testen, bevor Sie weiter investieren?
Ja-Antworten bei den Fragen 6 bis 9 sprechen für eine Web-App oder PWA. Bei gemischten Antworten ist eine Kombination oft sinnvoll: Web für das Büro, App für unterwegs.
Quellen
- WebKit-Blog: Web Push for Web Apps on iOS and iPadOS (16.02.2023)
- Can I use: Web Bluetooth
- Can I use: Web NFC
- Apple Developer: Enrollment – Voraussetzungen für die Anmeldung
- Google Play Console-Hilfe: Registrierung für ein Google Play Developer-Konto
- Google Play Console-Hilfe: Testanforderungen für neu erstellte private Entwicklerkonten
Häufige Fragen
Kann eine Web-App Push-Nachrichten senden?
Ja, am Computer und unter Android direkt aus dem Browser. Auf dem iPhone geht das seit iOS 16.4 aber nur, wenn Nutzer die Web-App vorher zum Home-Bildschirm hinzugefügt haben.
Braucht eine PWA den App Store?
Nein. Eine PWA wird direkt aus dem Browser auf dem Startbildschirm installiert, ohne Store-Prüfung und ohne Entwicklerkonto bei Apple oder Google.
Kann ich später von der Web-App auf eine native App umsteigen?
Ja, wenn Server und Oberfläche sauber getrennt sind. Dann bleiben Datenbank, Rechte und Geschäftsregeln erhalten, und nur die Oberfläche wird für die App neu entwickelt.
Was ist günstiger, Web-App oder native App?
In der Regel die Web-App, weil eine Codebasis auf allen Geräten läuft und Store-Verfahren entfallen. Eine native App für iPhone und Android lässt sich mit einer gemeinsamen Codebasis aber deutlich schlanker umsetzen als mit zwei getrennten Apps.