← Zurück zum Blog

Web-App, native App oder PWA: Welche Plattform passt zu deinem Vorhaben?

Die wichtigsten Unterschiede zwischen Web-App, Progressive Web App und nativer App, mit Entscheidungsfragen zu Hardware, Offline-Betrieb, Verteilung und Kosten.

Web-AppPWANative AppPlattformwahl

"Wir brauchen eine App." Der Satz steht am Anfang vieler Projekte, und er lässt offen, was gemeint ist: eine Anwendung im Browser, eine installierbare Web-App oder eine App aus dem App Store. Die Wahl beeinflusst Kosten, Entwicklungsdauer und Funktionsumfang. Sie sollte deshalb vor dem Angebot feststehen und im Lastenheft stehen. Dieser Artikel erklärt die Optionen und gibt dir Fragen an die Hand, mit denen du die Entscheidung begründest.

Die vier Varianten im Überblick

Web-App: Läuft im Browser auf Rechner, Tablet und Smartphone. Es gibt nichts zu installieren, Updates erscheinen für alle Nutzenden gleichzeitig, und eine einzige Codebasis deckt alle Geräte ab.

Progressive Web App (PWA): Eine Web-App mit zusätzlichen Fähigkeiten. Sie lässt sich wie eine App auf den Startbildschirm legen, kann Daten zwischenspeichern und in begrenztem Umfang offline arbeiten. Push-Benachrichtigungen sind möglich, die Unterstützung unterscheidet sich aber je nach Betriebssystem und Version. Prüfe sie für die Geräte, die deine Nutzenden tatsächlich verwenden.

Native App: Wird speziell für ein Betriebssystem (iOS oder Android) entwickelt und über die App-Stores oder eine Geräteverwaltung verteilt. Sie hat den umfassendsten Zugriff auf Gerätefunktionen.

Cross-Platform-App: Eine App, die mit Frameworks wie Flutter oder React Native aus einer Codebasis für beide Betriebssysteme gebaut wird. Sie wird ebenfalls über die Stores verteilt, spart aber gegenüber zwei getrennten nativen Apps Entwicklungsaufwand.

Fragen, die die Entscheidung steuern

  1. Welche Gerätefunktionen brauchst du? Kamera und Standort sind auch im Browser verfügbar. Bluetooth-Geräte, NFC, Hintergrunddienste oder tiefe Integration ins Betriebssystem sprechen eher für eine native oder Cross-Platform-App. Lass die Machbarkeit im Browser für deine konkreten Geräte prüfen.
  2. Wo arbeiten die Nutzenden? Im Büro mit stabilem Netz genügt meist eine Web-App. Im Lager, im Keller oder beim Kunden vor Ort entscheidet die Offline-Fähigkeit mit.
  3. Wie verteilst du die Software? Eine Web-App erreichst du per Link. Native Apps durchlaufen Store-Prüfungen oder brauchen eine Geräteverwaltung (MDM). Beides kostet Zeit und verursacht laufenden Aufwand.
  4. Wer nutzt sie? Interne Mitarbeitende, die du schulen kannst, haben andere Anforderungen als Kundinnen und Kunden, die sich spontan registrieren und erwarten, dass alles sofort funktioniert.
  5. Wie wichtig ist der Auftritt im Store? Wenn deine Zielgruppe nach einer App im Store sucht, kann das ein Argument sein. Für interne Werkzeuge spielt es meist keine Rolle.
  6. Welches Budget und welchen Zeitrahmen hast du? Eine Codebasis für alle Geräte ist in der Regel günstiger zu bauen und zu pflegen als mehrere. Der Unterschied hängt vom Funktionsumfang ab. Lass dir die Varianten vom Dienstleister getrennt kalkulieren.

Gegenüberstellung

Kriterium Web-App PWA Native / Cross-Platform
Installation keine optional, über den Browser über Store oder Geräteverwaltung
Updates sofort für alle sofort für alle Veröffentlichung im Store bzw. Verteilung nötig
Offline-Betrieb stark eingeschränkt begrenzt möglich umfassend möglich
Gerätefunktionen Browser-Funktionen Browser-Funktionen, teils erweitert voller Zugriff
Codebasis eine eine eine (Cross-Platform) oder mehrere (nativ)
Typischer Einsatz Fachanwendungen im Büro mobile Nutzung mit gelegentlichem Offline-Bedarf Außendienst, Hardware-Anbindung, Kundenapp

Die Tabelle gibt Tendenzen wieder. Im Einzelfall entscheidet der konkrete Funktionsumfang.

Häufige Wege in der Praxis

Viele Vorhaben im Mittelstand starten als Web-App oder PWA, weil sich damit der fachliche Kern am schnellsten validieren lässt. Das Vorgehen entspricht dem Gedanken des Artikels SaaS MVP in 90 Tagen: erst prüfen, ob die Lösung im Alltag trägt, dann investieren. Eine native App kommt dazu, wenn sich zeigt, dass eine Funktion im Browser nicht ausreicht.

Wichtig ist eine Architektur, die das offenlässt. Wenn die Fachlogik im Backend liegt und über eine Schnittstelle erreichbar ist, kann später ein weiterer Client hinzukommen, ohne dass alles neu gebaut wird. Fragen dazu stehen auch im Artikel Vom MVP zum Produkt.

Was ins Lastenheft gehört

  • Geräte und Betriebssysteme mit Mindestversionen, auf denen die Software laufen muss
  • Szenarien mit schlechtem oder fehlendem Netz und das erwartete Verhalten
  • Gerätefunktionen, die benötigt werden (Kamera, Scanner, Standort, Benachrichtigungen)
  • Art der Verteilung (Link, Store, Geräteverwaltung)
  • Browser, die unterstützt werden sollen

Fazit

Die Plattformwahl folgt aus den Anforderungen. Kläre, welche Gerätefunktionen du brauchst, ob die Nutzenden offline arbeiten und wie du die Software verteilst. Dann ergibt sich die passende Variante, und du kannst Angebote vergleichbar anfragen.

Häufig gestellte Fragen

Ist eine PWA ein Ersatz für eine native App?

Für viele Fachanwendungen reicht sie aus. Sobald du Funktionen brauchst, die der Browser auf deinen Zielgeräten nicht bietet, ist eine native oder Cross-Platform-App die passendere Wahl.

Muss ich meine App im App Store veröffentlichen?

Für interne Anwendungen kannst du die Verteilung auch über eine Geräteverwaltung lösen. Öffentliche Verbraucher-Apps erreichen ihre Zielgruppe meist über die Stores.

Kann ich später von einer Web-App zu einer nativen App wechseln?

Das ist möglich, besonders wenn Fachlogik und Daten über eine Schnittstelle bereitstehen. Plane diese Trennung von Anfang an ein, sie spart später Aufwand.

Verwandte Themen


Plattform, Geräte und Offline-Verhalten gehören ins Pflichtenheft. Pairlios KI prüft dein Dokument kostenlos auf Lücken. Jetzt kostenlos prüfen →