WebView in Anwendungen: Was es ist und wann es sinnvoll ist, es zu verwenden

Viele Menschen haben eine Anwendung verwendet, bei der es sich, ohne es zu wissen, tatsächlich um eine Website handelte, die in einer Shell ausgeführt wurde. Das Laden des Bildschirms dauert etwas länger, das Scrollen sieht etwas anders aus und wenn Sie auf etwas tippen, erscheint die Ladeanzeige, die einem Browser ähnelt. Das ist WebView am Werk, und zwar in mehr Apps, als Sie vielleicht denken.

WebView ist eines der nützlichsten und gleichzeitig am meisten missverstandenen Konzepte in der mobilen Entwicklung. Richtig eingesetzt spart es Zeit und Geld und löst echte Probleme. Bei unsachgemäßer Anwendung sorgt es für ein lauwarmes Erlebnis, das den Benutzer abschreckt und die Wahrnehmung des Produkts trübt.

Dieser Text ist eine Einführung. Wenn Sie Gründer oder Produktmanager sind oder gerade erst in die mobile Welt einsteigen und von WebView gehört haben, ohne wirklich zu verstehen, was es ist, finden Sie hier einen Überblick: Was es ist, wie es funktioniert und, was am wichtigsten ist, wann es sinnvoll ist, es zu verwenden.

Was ist ein WebView in der Praxis?

Ein WebView ist im Wesentlichen ein Browser ohne Adressleiste, eingebettet in eine Anwendung. Dadurch kann die App Webinhalte, HTML-Seiten und ganze Webanwendungen so anzeigen, als wären sie native Bildschirme.

Aus Sicht des Nutzers gibt es oft keinen sichtbaren Unterschied: Er öffnet die App, navigiert, nutzt sie. Der darunter liegende Bildschirm wurde jedoch nicht mit den nativen Komponenten des Betriebssystems erstellt. Es handelt sich um eine Webseite, die in einem Container gerendert wird.

Sowohl Android als auch iOS bieten diese Komponente offiziell an. Mit anderen Worten: WebView ist kein Hack, sondern ein legitimes Tool, das von den Plattformen selbst weitgehend unterstützt wird. Die Frage war nie „Ist das erlaubt?“, sondern eher „Ist es in diesem Fall die richtige Wahl?“.

Warum es diesen Ansatz gibt

Der Grund für die Existenz von WebView ist einfach: Wiederverwendung. Wenn Ihr Unternehmen bereits über eine funktionsfähige Website oder Webanwendung verfügt, können Sie durch die Anzeige in einer App vermeiden, dass für jede Plattform alles von Grund auf neu erstellt werden muss.

Der Aufbau einer wirklich nativen App bedeutet in der Praxis, separate Codebasen für Android und iOS zu verwalten, jede mit ihrer eigenen Sprache, ihren eigenen Teams und Zyklen. Es ist teuer und zeitaufwändig. WebView bietet eine Abkürzung: Schreiben Sie die Schnittstelle einmal in Webtechnologien und zeigen Sie sie überall an.

Diese Abkürzung ist von echtem Wert, insbesondere für diejenigen, die schnell etwas zum Laufen bringen, eine Idee validieren oder Inhalte pflegen müssen, die sich häufig ändern. Aber wie jede Abkürzung hat sie ihren Preis, und das Verständnis dieses Preises unterscheidet eine gute Entscheidung von einer naiven.

Die These: WebView ist weder gut noch schlecht, es ist ein Kompromiss

Die Frage, die ich oft höre, lautet: „Ist WebView gut oder schlecht?“. Die Frage ist falsch. WebView ist ein Austausch, und worauf es ankommt, ist zu wissen, was Sie austauschen.

Sie gewinnen an Entwicklungsgeschwindigkeit, gemeinsamem Code auf allen Plattformen und einfacherer Aktualisierung. Sie verlieren in unterschiedlichem Maße an Leistung, Flüssigkeit und vollen Zugriff auf die Ressourcen des Geräts. Bei einigen Produkten ist dieser Austausch hervorragend. In anderen ist es katastrophal.

Diejenigen, die WebView als universelle Lösung betrachten und „alles in WebView tun, um Geld zu sparen“, neigen dazu, es zu bereuen, wenn das Produkt wächst und die lauwarme Erfahrung anfängt, Benutzer zu kosten. Und wer es grundsätzlich ablehnt, „WebView ist was für Amateure“, verschwendet ein Tool, das das Problem elegant lösen würde. Technische Reife bedeutet, zu wissen, wo jeder Ansatz hingehört.

Wenn WebView Sinn macht

Es gibt Szenarien, in denen WebView die kluge Wahl und nicht die Notlösung ist.

Wenn sich Inhalte, Nutzungsbedingungen, Richtlinien, Hilfeseiten, Newscenter häufig ändern, macht es wenig Sinn, diese in die App einzubetten und bei jeder Textanpassung eine neue Version starten zu müssen. In WebView ändern Sie die Seite und die Änderung wird sofort für alle sichtbar.

Wenn Sie bereits über eine ausgereifte Webanwendung verfügen und schnell im Handel erhältlich sein möchten, können Sie mit WebView mit deutlich geringeren Investitionen auf den Markt kommen. Um zu überprüfen, ob sich eine App lohnt, bevor man viel investiert, ist dies eine vernünftige Strategie.

Wenn das Budget und das Team begrenzt sind und die Alternative darin bestünde, überhaupt keine App zu haben, ist ein gut gemachtes WebView-Produkt besser als gar keines. Das Optimum ist in vielen realen Zusammenhängen der Feind des Möglichen.

Wenn die WebView im Weg steht

Andererseits gibt es Situationen, in denen es ein Fehler ist, auf WebView zu bestehen.

Anwendungen, deren Wertversprechen Erfahrung, Flüssigkeit, Animationen, sofortige Reaktion auf Berührungen und Qualitätsgefühl sind, leiden unter WebView. Der Benutzer kann möglicherweise nicht erklären, warum, aber er findet, dass es „merkwürdig“ ist. In wettbewerbsintensiven Märkten bestimmt dieser subtile Unterschied, wer bleibt und wer geht.

Funktionen, die stark von Hardware, Kamera mit Echtzeitverarbeitung, Sensoren, intensiver Offline-Nutzung und systemspezifischen Integrationen abhängig sind, stoßen in WebView auf Reibung. Es ist möglich, einiges davon zu umgehen, aber der Aufwand, es zu umgehen, macht manchmal die Einsparungen zunichte, die die Entscheidung motiviert haben.

Und es gibt das Problem der Leistung auf bescheideneren Geräten. In Brasilien, wo ein großer Teil der Basis Zwischengeräte verwendet, kann eine umfangreiche Webschnittstelle dort stecken bleiben, wo eine native hingehen würde. Wenn Sie sich für WebView entscheiden, ohne an das tatsächliche Gerät Ihres Benutzers zu denken, tappen Sie im Dunkeln.

Grenzen und Fallstricke

Die häufigste Falle besteht darin, die Entscheidung als rein technische Entscheidung zu betrachten, wenn es sich um eine Produktentscheidung handelt. Die richtige Frage ist nicht „Welche Technologie bevorzugen wir?“, sondern „Welche Erfahrung braucht unser Benutzer und was sind wir bereit, dafür zu zahlen?“.

Eine weitere Falle ist die „Alles oder Nichts“-Lüge. Viele gut entwickelte Produkte sind Hybride: kritische native Bildschirme, bei denen Erfahrung zählt, und sekundäre WebView-Bildschirme, bei denen sich die Wiederverwendung auszahlt. Man muss sich im Leben nicht für eine Seite entscheiden. Gute Architektur mischt sich entsprechend dem Wert jedes Bildschirms.

Es gibt immer noch einen Sicherheitspunkt, der von Anfang an Aufmerksamkeit verdient: Ein WebView trägt Webinhalte, und Webinhalte bringen die Belange des Webs mit sich. Das Laden von Seiten aus nicht vertrauenswürdigen Quellen oder das Offenlegen sensibler Funktionen für geladene Inhalte öffnet Türen, die eine rein native App nicht hätte. Dies ist kein Grund, WebView zu meiden, sondern ein Grund, es mit Vorsicht zu verwenden.

Die richtige Wahl ist die, die dem Benutzer dient

Letztlich ist WebView ein Werkzeug, und Werkzeuge haben keine Moral, sondern eine Anwendung. Die Frage sollte nie sein, ob WebView gut ist, sondern ob es den Anforderungen Ihres Produkts, Ihrem Budget und Ihrem tatsächlichen Benutzer gerecht wird.

Wer das versteht, hört auf, Technologie auf der Grundlage einer Ideologie zu diskutieren, und beginnt, Entscheidungen auf der Grundlage des Kontexts zu treffen. Manchmal ist die Antwort nativ, manchmal ist es WebView, oft ist es eine clevere Mischung aus beidem. Reife bedeutet, eine klare Entscheidung zu treffen und genau zu wissen, was man gewinnt und was man aufgibt.

Wenn Sie sich für die Architektur einer Anwendung entscheiden und sich zwischen nativ, hybrid und WebView nicht sicher sind, lohnt es sich, darüber zu reden, bevor Sie eine Entscheidung treffen, die Sie jahrelang belasten wird. Ich habe auf dem Blog weitere Texte zum Thema mobile Entwicklung und digitale Produkte und helfe gerne denjenigen, die an diesem Punkt der Entscheidung stehen.