Zum Inhalt springen
Codedock
LeistungenWie wir arbeitenInsightsFallstudienKarriereKontakt
Zurück zu allen Artikeln
Architektur & Consulting

·

6 Min Lesezeit

·

Geschrieben von Tomáš Mikeš

PWA statt iOS/Android-App: wann es funktioniert und wann Sie Nutzer verlieren

Für Fotopast.cloud haben wir die SaaS-Plattform als PWA statt zwei nativen Apps gebaut. In 2 Monaten ausgeliefert, funktioniert. Aber hier sind fünf Faktoren, nach denen wir entscheiden — nicht jedes Projekt passt in eine PWA.

PWAMobileArchitekturiOSAndroid

„Wir wollen eine App.“ Typischer erster Satz, wenn ein Kunde mit einem Mobile-Use-Case kommt. Oft die richtige Antwort — aber nicht immer. Für Fotopast.cloud, einem SaaS zur Verwaltung von Wildkamera-Fotos, haben wir eine PWA statt zwei nativer Apps gebaut. In 2 statt 5-6 Monaten ausgeliefert, mit vollem Push-Support und Offline-Fallback.

Funktioniert. Aber nicht jede Mobile-App würde diesen Wechsel überstehen. Fünf Faktoren, die wir abwägen.

1. Hardware- / Sensorzugriff — wo PWA an die Wand stößt

PWAs haben begrenzten Hardware-Zugriff. Kamera geht über den File-Picker, aber nicht Live-Capture mit eigenem Overlay. Bluetooth Low Energy? In Chrome ja, in Safari immer noch nicht. NFC? Nur Android Chrome. Background-Geolocation? Nirgendwo zuverlässig.

Für Fotopast war das ok — Fotos werden aus der Wildkamera über einen anderen Weg gesammelt (4G-Modul der Kamera), die PWA zeigt und verwaltet nur. Müsste die App Nutzer QR-Codes direkt mit AR-Preview scannen lassen, wäre PWA draußen. Es ist eine Trennung: was die App mit dem Telefon macht vs. mit den Daten.

2. Push-Benachrichtigungen — Apple ist die Barriere

Web-Push funktioniert seit 2015 in Browsern. Auf iOS Safari erst ab iOS 16.4 (April 2023), und selbst dann nur, wenn die PWA per „Zum Home-Bildschirm hinzufügen“ installiert ist. Ohne Install-Prompt kein Push — Apple hat es absichtlich erschwert, um den App-Store zu schützen.

Fotopasts Zielgruppe (Jäger, Förster) braucht Push kaum — die Wildkamera mailt ohnehin. Wenn Ihr Use Case ohne Instant-Push kollabiert (Chat, Transaktions-Alerts, Security-Alerts), blockiert PWA 30-40 % Ihrer iOS-Nutzer.

3. App-Store-Präsenz — Marketing-Faktor

Unterschätzen Sie nicht den Glaubwürdigkeits-Effekt von „wir sind im App Store“. Für ein Consumer-Produkt ist das Signal oft wichtig („wir sind eine echte Marke“). Für ein B2B-Werkzeug für eine bestimmte Berufs-Community — Fotopast ist genau das — irrelevant. Jäger finden die App über QR-Codes in Anzeigen, Mundpropaganda, Google-Suche. „Im App Store entdeckt“ trägt nichts bei.

Fragen Sie: Wo finden Ihre Nutzer die App tatsächlich? Wenn über App-Store-Suche, ist PWA ein Handicap. Wenn über Web/QR/Direct-Link — PWA ist genauso gut wie nativ.

4. UX-Erwartungen der Zielgruppe

30+, Profis, B2B — 90 % ist egal, ob die App nativ oder PWA ist, solange sie funktioniert. Gen Z, jüngere Millennials, Gaming, Entertainment — erwarten den Install-from-App-Store-Flow; sonst fühlt sich die App „nicht richtig an“.

Fotopasts Zielgruppe ist 40+, Jäger, Förster, Landwirte. Für sie ist eine Web-App mit dem gleichen Home-Screen-Icon wie WhatsApp ein Bonus, kein Problem. Für die Quick-Service-App einer 25-Jährigen wäre dieselbe Entscheidung falsch.

5. Offline-Szenarien und Zuverlässigkeit

PWAs können offline via Service Worker, aber es ist mehr Arbeit als bei nativen Apps (wo SQLite oder Core Data first-class sind). Wenn Ihre App 100 % ohne Signal laufen muss — Field-Tools, Logistik — ist nativ zuverlässiger.

Fotopasts Offline ist nice-to-have, nicht must-have. Ein Jäger im Wald hat kein Signal, braucht es aber auch nicht — die Fotos wurden vorher heruntergeladen, er browst nur. Bei Wiederverbindung wird synchronisiert.

Ein Entscheidungsrahmen

PWA ist sinnvoll, wenn:

  • Hardware-Zugriff in Browser-APIs passt (Kamera via Picker, GPS während Nutzung, Notifications mit Limits)
  • B2B oder 30+ professionelle Zielgruppe
  • Verteilung via Web/QR/Direct-Link, nicht App Store
  • Offline in reduzierter Form akzeptabel ist
  • Schnelle Iteration — eine Codebase statt zwei

Nativ ist besser, wenn:

  • Hardware-Use-Case Custom-Capture / Sensoren / BLE erfordert
  • Consumer-Zielgruppe App-Store-Präsenz erwartet
  • Push tragend ist (iOS-Barriere ist ein Blocker)
  • 100 % Offline zum Core-Use-Case gehört
  • Budget für 2 Codebases und 2 Deployment-Pipelines reicht (App-Store-Review verzögert jeden Ship um 1-3 Tage)

Fotopast-Ergebnis

2 Monate vom Kickoff zur Produktion. Eine Codebase, drei Deployment-Ziele (Web, iOS-Home-Screen, Android-Home-Screen). Nutzer-Feedback nach 6 Monaten: niemand sagte „mir fehlt eine native App“. Das sagt uns, die Entscheidung passte.

Mit anderer Zielgruppe wäre die Entscheidung anders. PWA ist nicht besser oder schlechter als nativ — es ist ein anderer Trade-off. Diese fünf Faktoren sind die Karte, auf der Sie Ihre Position finden.

Arbeiten Sie an etwas Ähnlichem?

Vereinbaren Sie ein 30-minütiges technisches Gespräch. Kein Vertriebsprozess — direktes architektonisches Feedback.

Termin auswählen

Architektur, Cloud und Integration für komplexe Systeme. Ein Senior-Architekt in jedem Projekt.

Navigation

LeistungenWie wir arbeitenInsightsFallstudienKarriereKontaktAgentur vs. Freelancer vs. wir

Leistungen

EntwicklungCloudDevOpsAI & DatenBeratungDelivery

Kontakt

CodeDock s.r.o.

Zlenická 863/9, 104 00 Praha 22

Tschechische Republik

info@codedock.com

IČO: 14292769

DIČ: CZ14292769


© 2026 Codedock

KontaktDatenschutzerklärung
Termin buchen