Die Hülle braucht eine konkrete Begründung
Eine Progressive Web App reicht, wenn der zentrale Ablauf in den Browsern der Zielgruppe zuverlässig funktioniert und direkter Webzugang genügt. Capacitor wird interessant, wenn eine bestimmte native Integration oder Vertriebsanforderung die zusätzliche Betreuung mobiler Projekte rechtfertigt. Ein Symbol auf dem Telefon entscheidet das nicht.
Eine PWA ergänzt eine Webanwendung um Möglichkeiten wie Installation und Offline-Verhalten. Umsetzung und Browserunterstützung bleiben entscheidend. Googles PWA-Leitfaden behandelt diese Aspekte als eigene Gestaltungs- und Entwicklungsaufgaben, nicht als pauschalen Gleichstand mit jeder installierten Anwendung.
Browsergrenze und Bedienproblem unterscheiden
Vor dem zusätzlichen Container muss die im Browser scheiternde Anforderung benannt werden. Ein umständliches Formular, unklare Navigation oder langsamer Start sind nicht zwangsläufig Browsergrenzen. Dieselbe Oberfläche in einem anderen Container kann dieselben Probleme behalten.
Capacitor stellt eine native Laufzeit für Webanwendungen und eine Plugin-Schnittstelle zu Plattformfähigkeiten bereit. Das beschreibt die offizielle Dokumentation. Es verbindet Webanwendung und native Funktionen, gestaltet die Bedienung aber nicht automatisch in plattformspezifische Interaktionsmuster um.
Ein bestehendes Webprodukt mit klar begrenztem nativem Bedarf ist ein plausibler Einsatzfall. Benötigt dagegen fast jede zentrale Interaktion spezielle Plattformlogik, sollte eine breitere mobile Architektur geprüft werden. Dann bleibt die Hülle möglicherweise keine kleine Ergänzung.
Den Lebenszyklus statt nur den Aufruf testen
Ein beispielhafter Scanvorgang endet nicht mit dem Ergebnis der Kamera. Die Anwendung kann unterbrochen werden, eine Berechtigung kann fehlen, das Netz kann ausfallen und ein offener Vorgang muss später fortgesetzt werden. Diese Zustände gelten für Browser-APIs genauso wie für native Plugins.
Bei der PWA werden die vorgesehenen Browser und installierten Betriebsarten auf realen Zielgeräten geprüft. Bei Capacitor muss das konkrete Plugin auf jeder Plattform passen und eine zuständige Person für native Änderungen benannt sein. Eine dokumentierte Funktion belegt noch keinen verlässlichen Gesamtprozess.
Dasselbe gilt offline. Eine zwischengespeicherte Oberfläche löst keine widersprüchlichen Änderungen und bestätigt keine serverseitige Verarbeitung. Das Wiederherstellungsverhalten gehört vor die Containerentscheidung.
Die zusätzliche Release-Fläche kalkulieren
Eine native Hülle bringt Projektkonfiguration, Signierung, Store-Einreichung und plattformspezifische Tests mit. Auch bei weitgehend gemeinsamer Oberfläche brauchen diese Aufgaben klare Zuständigkeiten. Die jeweiligen Vertriebsregeln sind zu prüfen, statt bei jeder Webänderung eine umgehbare Prüfung vorauszusetzen.
Auch die Webanwendung benötigt Wartung: Browseränderungen, Service-Worker-Aktualisierungen, Speicherung und Anmeldung müssen zuverlässig bleiben. Verglichen werden unterschiedliche Betriebsaufgaben, nicht eine wartbare und eine wartungsfreie Lösung.
Unser früherer Beitrag Webanwendung oder native App behandelt die vorgelagerte Frage nach dem nativen Bedarf. Clodrons App-Entwicklung sollte die native Grenze daraus nachvollziehbar und angemessen ableiten.
Diese Woche eine Fähigkeitsprüfung durchführen
Die im Browser fehlende Anforderung wird als beobachtbarer Abnahmetest formuliert. Verweigerte Berechtigung, Unterbrechung, Wiederverbindung und Aktualisierung werden aufgenommen, soweit sie den Vorgang betreffen. Derselbe Ablauf läuft mit realistischen Geräten und Konten in PWA und kleinem Capacitor-Prototyp.
Besteht die PWA ohne Hülle, bleibt sie die naheliegende Wahl. Schliesst der native Weg eine echte Lücke und ist sein Release-Aufwand akzeptiert, spricht das für Capacitor. Weitet sich die native Arbeit über das ganze Erlebnis aus, muss die Architekturentscheidung erneut geöffnet werden.