PWA oder native Store-App – warum die kürzere Antwort meist falsch ist
Die meisten Geschäftsführer fragen nach der nativen App, weil „im App Store“ nach richtiger Software klingt. Eine Progressive Web App klingt dagegen wie ein Kompromiss – eine Webseite, die so tut als ob. In der Praxis ist das Verhältnis oft umgekehrt: Die PWA liefert das ruhigere Update-Verhalten, die kürzere Onboarding-Strecke, die niedrigere Wartungskosten und mehr Kontrolle über die eigenen Daten. Dieser Artikel zeigt, wann das stimmt – und wann nicht.
Was eine PWA wirklich ist
Progressive Web App bedeutet: eine Webseite, die sich wie eine App verhält. Eigenes Icon auf dem Startbildschirm, Vollbild-Modus ohne Browser-Leiste, eigener Splash-Screen beim Start, lokaler Zwischenspeicher für Offline-Betrieb. Technisch ist sie HTML, CSS und JavaScript – ausgeliefert von Ihrem Server, geöffnet im Browser, der sie aber wie eine native Anwendung darstellt.
Der entscheidende Unterschied liegt nicht in dem, was die App kann, sondern darin, wer dazwischen sitzt. Bei einer nativen App ist Apples App Store oder Googles Play Store der Vermittler zwischen Ihnen und Ihren Mitarbeitern. Jedes Update geht durch deren Prüfung. Bei einer PWA gibt es keinen Vermittler – Sie liefern direkt aus, der Browser stellt dar.
Warum Updates der größte Punkt sind
Apple prüft jede neue App-Version, bevor sie freigegeben wird. Im Schnitt 24 bis 72 Stunden, in besonderen Fällen bis zu sieben Tagen. Bei kritischen Sicherheits-Patches kann man eine beschleunigte Prüfung beantragen, die meist nach 12 Stunden durch ist. Google ist im Schnitt schneller, aber auch dort liegen mehrere Stunden zwischen Hochladen und Sichtbarkeit.
Das ist nur die halbe Geschichte. Selbst wenn das Update freigegeben ist, muss der Mitarbeiter es aktiv aus dem Store ziehen. Bei privaten Geräten (BYOD-Politik) und Mitarbeitern, die Auto-Update abgeschaltet haben, dauert das oft Wochen. In größeren Betrieben sind nach drei Wochen meist noch fünf bis sieben verschiedene Versionen im Umlauf. Bei sicherheitskritischen Bugs ist das ein echtes Problem.
Eine PWA hat dieses Problem nicht. Beim nächsten Öffnen prüft der Browser im Hintergrund, ob der Server eine neue Version anbietet. Falls ja, wird sie geladen. Beim übernächsten Öffnen ist sie aktiv. Sie haben innerhalb weniger Stunden eine konsistente Version auf allen Geräten – ohne dass jemand etwas tun muss.
Onboarding: 30 Sekunden gegen 10 Minuten
Ein neuer Mitarbeiter kommt am Montag rein. Bei einer Store-App muss er den App Store öffnen, den korrekten Namen suchen (Verwechslungsgefahr bei generischen Namen), die richtige App identifizieren, herunterladen, installieren, öffnen, Account-Daten eintippen. Bei schlechtem Empfang im Werkshof: weitere 5 bis 10 Minuten Wartezeit. Bei iPhone ohne hinterlegte Apple-ID: Sackgasse, der IT-Verantwortliche muss anrichten.
Bei einer PWA: Einladungs-Mail mit Link öffnen, im Browser auf das Teilen-Symbol tippen, „Zum Startbildschirm hinzufügen“, fertig. 30 Sekunden, kein Store, keine Apple-ID, keine Versions-Verwechslung. Der Link führt automatisch zur richtigen Instanz, das Icon erscheint auf dem Startbildschirm, der erste Login läuft direkt über denselben Link.
Für Personal- oder IT-Abteilungen ist das ein konkreter Kostenfaktor: Bei 50 neuen Mitarbeitern im Jahr und 10 Minuten Onboarding-Zeit pro Person sind das 8 Stunden Aufwand – plus die Folgefragen, wenn etwas nicht klappt. Bei der PWA ist das im Onboarding-Mail-Workflow erledigt.
Alte Diensthandys, sparsame Datentarife, schlechter Empfang
Native Apps haben Mindestanforderungen. Eine moderne Marktbegleiter-Plattform fordert iOS 16 oder Android 8. iOS 16 erschien 2022, läuft also auf iPhones ab Modell 8 (2017). Android 8 erschien 2017. In der Theorie weit genügend Reichweite. In der Praxis: Werkstatt-iPads, die seit fünf Jahren auf dem Hochregal stehen, und Diensthandys, die bei einem ausgeschiedenen Mitarbeiter zurückblieben, fallen oft raus.
Eine PWA stellt im Browser dar. Ein Browser von 2018 reicht in der Regel für alle Lese-Funktionen, ein Browser von 2020 für alle Schreib-Funktionen inklusive Offline. Wir hatten schon Kunden, deren ältestes Diensthandy Android 5 war – die App lief, mit ein paar Komfort-Einbußen, aber sie lief.
Auch die Download-Größe ist anders: Eine native App kommt schnell auf 80 bis 250 MB, eine PWA lädt initial 1 bis 5 MB. Bei Mitarbeitern mit kleinem Datentarif oder Empfang, der häufig auf Edge zurückfällt, ist das ein realer Unterschied.
Was eine native App wirklich besser kann
Es gibt vier Fälle, in denen eine native App technisch überlegen ist. Wir nennen sie ehrlich, damit Sie nicht in eine PWA gedrängt werden, die Ihren Anwendungsfall nicht abdeckt:
Tiefer Hardware-Zugriff. Wenn die App per NFC mit einer Werksanlage kommunizieren soll, ein Bluetooth-Pairing mit Spezial-Hardware aufbauen muss oder einen Hochleistungs-Barcode-Scanner mit eigener Kamera-Pipeline braucht, ist nativ klar im Vorteil. PWAs können NFC, Bluetooth und Kamera mittlerweile ansprechen, aber mit Einschränkungen je nach Browser und Betriebssystem-Version.
Push-Benachrichtigungen auf iPhones. Auf Android funktioniert Push bei beiden Varianten gleich. Auf iPhones ist Push in einer PWA seit iOS 16.4 (März 2023) möglich – aber nur, wenn die App zum Startbildschirm hinzugefügt wurde. Wenn das nicht passiert, kommt keine Push-Nachricht an. Für missionskritische Alarmierungen (Notfall, Gefährdung, Schichtwechsel) kann das ein Problem sein. Native iOS-Apps bekommen Push-Berechtigung beim ersten Start abgefragt, das ist robuster.
Listing in App Stores. Wenn externes Personal – etwa Subunternehmer, Partnerfirmen, Bewerber – die App über den App Store finden soll, brauchen Sie nativ. Eine PWA wird nirgends gelistet. Für interne Mitarbeiter ist das egal, weil die direkt eingeladen werden. Für Mitarbeiter-Apps ist Listing fast nie das Argument; für Endkunden-Apps schon.
Komplexe Mehrtages-Offline-Workflows mit großen Datenmengen. Eine PWA kann offline arbeiten, aber der Browser darf den Zwischenspeicher räumen, wenn er Speicherdruck bekommt. Bei Außendienst-Apps mit großen lokalen Datenbanken und Wochen-langer Offline-Phase ist nativ verlässlicher.
Die Kostenrechnung über 5 Jahre
Eine native App für iOS und Android braucht zwei Codebasen: Swift für iOS, Kotlin für Android. Plus ein Web-Backend für die Verwaltung. Drei Code-Bereiche, drei Pflege-Aufwände, drei Test-Strecken. Bei jedem neuen Feature wird er dreimal gebaut, dreimal getestet, dreimal getrennt aktualisiert.
Eine PWA ist eine Codebasis. Sie läuft auf iPhone, Android, Tablet, Desktop, alten Büro-Rechnern. Jedes Feature wird einmal gebaut. Bei der Erstentwicklung sparen wir damit 40 bis 60 Prozent der Aufwände. Über fünf Jahre Wartung sparen wir noch mehr, weil Bug-Reports nicht dreifach reproduziert und behoben werden müssen.
Konkret: Eine mittelgroße Mitarbeiter-App nativ liegt bei uns Setup zwischen 12.000 und 25.000 Euro plus jährliche Pflege. Dieselbe App als PWA liegt bei 1.490 bis 6.900 Euro Setup plus Server-Kosten von 5 bis 15 Euro pro Monat. Für 95 Prozent der Mitarbeiter-Apps ist die PWA-Variante völlig ausreichend – und der Unterschied lässt sich besser in andere Themen investieren (Mitarbeiter-Schulung, eigene Hardware, eigenen Server).
Datenschutz: weniger Tracking, mehr Kontrolle
Native Apps werden über App Stores ausgeliefert. Apple und Google liefern Frameworks, die in der App enthalten sein müssen – darunter Telemetrie-Bibliotheken, Werbe-IDs (IDFA bei Apple, GAID bei Android) und Diagnose-Daten, die an die Hersteller gehen. Auch wenn Sie als Entwickler nichts tracken wollen, sammeln Apples und Googles SDKs trotzdem Verhaltensdaten.
Eine selbst gehostete PWA überträgt nur das, was Sie programmieren. Keine Werbe-IDs, keine fremde Telemetrie, keine Daten an Apple oder Google. Sie haben volle Kontrolle darüber, was die App in Ihre eigenen Server schickt. Für DSGVO-Audits, Betriebsräte und sicherheits-bewusste Branchen (Pflege, Verwaltung, Anwaltskanzleien) ist das ein konkretes Argument.
Wann Sie sich selbst entscheiden können – und wann nicht
Sie kommen mit einer PWA aus, wenn: Ihre Mitarbeiter direkt über Einladungslink onboarden, die App nicht im Store gefunden werden muss, Push-Benachrichtigungen auf iPhones nicht missionskritisch sind, kein NFC- oder Bluetooth-Pairing mit Sondertechnik anliegt, und Sie kein Mehrtages-Offline-Szenario im Außendienst haben. Das trifft auf den allergrößten Teil der Mitarbeiter-Apps in produzierenden Betrieben, Kommunen, Handwerk und Gastronomie zu.
Sie brauchen nativ, wenn: einer der vier oben genannten Fälle zutrifft. Konkret: Industrielle Hardware-Anbindung, garantierte iPhone-Push-Notifications für Notfälle, App-Store-Sichtbarkeit für externe Zielgruppen, oder Wochen-lange Offline-Phasen mit großen lokalen Daten.
In Grenzfällen empfehlen wir den schrittweisen Weg: Erst die PWA bauen, ein bis zwei Quartale im echten Betrieb laufen lassen, dann anhand realer Daten entscheiden, ob die nativen Vorteile in Ihrem Alltag wirklich greifen. Falls ja, ergibt sich nativ als sinnvolle Ergänzung. Falls nein, sparen Sie Setup- und Wartungskosten dauerhaft.
Ihre eigene Mitarbeiter-App – gebaut von uns
Wir bauen Ihre Mitarbeiter-App als PWA, individuell für Ihr Team. Eine Codebasis, ein Server (Hetzner empfehlen wir, IONOS oder All-Inkl gehen genauso), keine Pro-Kopf-Gebühren, kein App-Store-Gatekeeper. Ab 1.490 Euro einmalig.
Mehr zur Mitarbeiter-App →Häufige Fragen
Was ist überhaupt eine PWA?
Progressive Web App ist eine Web-Anwendung, die sich auf dem Smartphone wie eine richtige App verhält. Sie wird nicht aus dem Store geladen, sondern über die Webseite zum Startbildschirm hinzugefügt. Sie hat ein eigenes Icon, eigenen Splash-Screen, läuft im Vollbild ohne Browser-Leiste und kann offline funktionieren. Technisch ist sie eine Webseite, die Apples Safari oder Googles Chrome wie eine App behandeln.
Warum ist eine PWA bei Updates schneller als eine native App?
Native Apps müssen jedes Update erst von Apple oder Google geprüft werden. Apple braucht im Schnitt 24 bis 72 Stunden, in Spitzenzeiten bis zu 7 Tage. Google ist meist innerhalb eines Tages durch. Bei einer PWA gibt es keinen Prüfer dazwischen: Sie laden den neuen Code auf Ihren Server, beim nächsten Öffnen ist er aktiv. Sicherheits-Patches greifen sofort, Bugfixes erreichen alle Mitarbeiter ohne Aktion ihrerseits.
Funktioniert eine PWA auch offline?
Ja, im Rahmen dessen, was technisch möglich ist. Lese-Inhalte wie News, Wiki, Dokumente, Personenverzeichnis, Kalender und eigene Aufgaben werden auf dem Gerät zwischengespeichert und sind auch ohne Empfang abrufbar. Schreib-Aktionen wie Krankmeldung, Spesen-Beleg, Aufgaben-Status oder Zeiterfassungs-Stempel landen in einer Warteschlange und werden synchronisiert, sobald die Verbindung wieder steht. Live-Chat und Videocall brauchen aktives Netz – das gilt für PWA und native App gleichermaßen.
Was kann eine native App, was eine PWA nicht kann?
Tiefer Hardware-Zugriff: NFC-Kommunikation mit Industrie-Anlagen, Bluetooth-Pairing mit Spezial-Hardware, eigene Kamera-Pipeline für Hochleistungs-Barcode-Scanner. Push-Benachrichtigungen sind auf iPhones bei PWAs an Bedingungen geknüpft – die App muss zum Startbildschirm hinzugefügt sein. Auf Android funktioniert Push bei beiden gleich. Listing im App Store oder Google Play ist nur mit nativer App möglich.
Kostet eine PWA weniger als eine native App?
Ja, deutlich. Eine native Lösung braucht zwei Codebasen (Swift für iOS, Kotlin für Android) plus ein Web-Backend. Eine PWA ist eine Codebasis für alle Geräte. Bei Erstentwicklung spart das 40 bis 60 Prozent der Aufwände. Bei Wartung über fünf Jahre noch mehr, weil jedes Feature nur einmal gebaut, getestet und gepflegt wird.
Sieht meine Mitarbeiter-App aus wie eine echte App?
Ja. Eigenes Icon auf dem Startbildschirm, eigener Splash-Screen beim Öffnen, kein Browser-Rand sichtbar, Vollbild-Modus. Die meisten Anwender erkennen den Unterschied zu einer Store-App nicht, wenn sie nicht gezielt darauf achten. Auch Wischgesten, Scrollverhalten und Tastatur-Verhalten sind identisch zur nativen App.
Was passiert, wenn Apple oder Google die Regeln für PWAs ändern?
Theoretisches Risiko, praktisch sehr gering. PWAs sind im Grunde standardisierte Web-Technologie. Apple und Google haben in den letzten zehn Jahren PWA-Funktionen schrittweise erweitert, nicht zurückgenommen. Selbst wenn ein Hersteller einzelne Funktionen einschränkt, läuft die App weiter – sie verliert höchstens einen Komfort. Bei nativen Apps haben App-Store-Anbieter weit mehr Hebel: sie können einzelne Apps jederzeit entfernen.
Wir wollen, dass unsere App im App Store findbar ist. Geht das mit PWA?
Nein. Im Apple App Store und Google Play Store findet man nur native Apps. Wenn das ein wichtiges Argument ist – etwa weil externes Personal über den Store sucht – ist die native App die richtige Wahl. In der Mehrheit unserer Projekte ist das nicht der Fall: Mitarbeiter werden direkt eingeladen, der Link aus der Begrüßungs-Mail führt sie zur App, der Store ist gar nicht im Spiel.
Können Sie auch native Apps bauen, wenn wir uns dafür entscheiden?
Ja. In der Regel bauen wir die App zuerst als PWA und ergänzen die native Variante, wenn der Bedarf nachweislich da ist. Das spart Zeit und Geld bei der Erstentwicklung und gibt Ihnen die Möglichkeit, im laufenden Betrieb zu prüfen, ob die nativen Vorteile in Ihrem Alltag wirklich greifen. Wenn ja, ergänzen wir – wenn nein, sparen Sie sich den Aufwand.
Verwandte Themen: Mitarbeiter-App individuell bauen · DSGVO-Team-Plattform statt Microsoft Teams · Individualsoftware