Eine Web-App in die native App holen: Wie das ohne zweiten Codebestand geht

Warum das Thema bei uns auf dem Tisch liegt

Fast jede zweite Anfrage für ein Serviceportal endet mit demselben Nachsatz: „Und das sollte dann auch als App gehen." Der Wunsch ist berechtigt. Wer Zählerstände meldet, Termine bucht oder eine Störung fotografiert, macht das am Telefon, und ein Symbol auf dem Startbildschirm ist näher als eine Adresse im Browser.

Der Reflex vieler Anbieter ist, dann zwei Dinge zu entwickeln: das Portal fürs Web und eine App für iOS und Android. Das verdoppelt den Aufwand, verdreifacht die Pflege und sorgt dafür, dass die App nach zwei Jahren hinter dem Web zurückhängt, weil dort schneller entwickelt wird.

Es geht anders, und Shopify hat im April 2025 sehr offen beschrieben, wie.

Was Shopify gemacht hat

Die Shopify-App hat rund 600 Bildschirme. Die wichtigsten davon sind nativ entwickelt, weil dort jede Millisekunde zählt. Der Rest wurde im Web entwickelt und in der App über WebViews angezeigt. Das ist ein Browserfenster ohne Adressleiste, das in der App steckt.

Das Problem, das jeder kennt, der so etwas schon einmal benutzt hat: WebViews fühlen sich fremd an. Sie laden langsamer, sie sehen anders aus als der Rest der App, und sie verhalten sich beim Zurückspringen und bei Dialogen wie eine Website, nicht wie eine App.

Das Team hat das in drei Schritten angegangen, und jeder davon lässt sich übertragen.

1. Schneller machen: vorladen statt warten

Die Analyse ergab, dass die Ladezeit vor allem an der Anmeldung hing. Jeder WebView musste durch mehrere Weiterleitungen, bis die Sitzung stand. Die Lösung war unspektakulär: WebViews werden beim Start der App im Hintergrund geladen und angemeldet, danach behalten und wiederverwendet. Die Ladezeit im 75. Perzentil fiel von rund sechs Sekunden auf 1,4 Sekunden.

Für ein Serviceportal heißt das: Die App meldet den Nutzer einmal an und reicht die Sitzung an den WebView weiter. Der Nutzer tippt sein Passwort einmal, nicht bei jedem Bildschirm.

2. Aussehen angleichen: die Dinge entfernen, die verraten, dass es Web ist

Zoom per Fingergeste abschalten. Textauswahl abschalten. Kopf- und Fußzeile der Website ausblenden, weil die App ihre eigene Navigation hat. Die Bausteine der Web-Oberfläche so anpassen, dass sie den nativen Mustern folgen: gleiche Abstände, gleiche Schaltflächen, gleiche Bewegungen.

Das klingt nach Kleinkram. Es ist der Unterschied zwischen „Warum ist das hier so komisch?" und „Ich habe gar nicht gemerkt, dass das Web war."

3. Verhalten angleichen: eine Brücke zwischen Web und App

Der interessanteste Teil. Web und App brauchen einen Kanal, über den sie sich Dinge sagen: Der Nutzer hat gerade auf Speichern getippt. Der Titel dieses Bildschirms lautet „Zählerstand melden". Öffne bitte die Kamera.

Shopify hat dafür ein eigenes Framework entwickelt, Mobile Bridge, das auf einer bereits vorhandenen Bibliothek für Fernaufrufe aufsetzt. Darüber laufen vier Dinge, die aus einem WebView eine App machen:

Titel und Aktionen wandern in die native Leiste. Die Web-Seite sagt der App, wie sie heißt und welche Knöpfe sie oben rechts braucht. Die App zeigt das in ihrer eigenen Navigationsleiste an. Für den Nutzer sieht der Bildschirm aus wie jeder andere.

Navigation ohne Neuladen. Im Browser lädt jeder Link eine neue Seite. In einer App wird ein neuer Bildschirm auf einen Stapel gelegt, und der alte bleibt darunter. Shopify verschiebt deshalb den bestehenden WebView von Bildschirm zu Bildschirm, statt für jeden einen neuen zu öffnen. Sitzung, Formulareingaben und geladene Daten bleiben erhalten.

Zurück ohne weißen Bildschirm. Beim Zurückspringen würde der Nutzer kurz eine leere Fläche sehen, während der WebView zurückwandert. Das Team macht vor jedem Wechsel ein Bildschirmfoto und zeigt es so lange an, bis der echte Inhalt wieder da ist.

Dialoge als eigene Bildschirme. Web-Dialoge legen sich über die Seite. App-Dialoge schieben sich von unten herein. Shopify zeigt Web-Dialoge als native Bildschirme an und lässt den Inhalt erst erscheinen, wenn die Bewegung abgeschlossen ist.

Dazu kommt der Teil, der den größten Unterschied im Alltag macht: native Bausteine aus dem Web heraus aufrufen. Die Datumsauswahl, der Barcode-Scanner, „Zur Wallet hinzufügen". Die Web-Seite fragt, die App liefert, das Ergebnis geht zurück ins Web.

Was das für Ihr Portal heißt

Die Vorgehensweise passt auf fast jedes Serviceportal, das wir entwickeln. Der Weg sieht dann so aus:

Das Portal ist eine Web-Anwendung. Es läuft im Browser, ist als installierbare Web-App eingerichtet und wird dort weiterentwickelt. Das ist der eine Codebestand.

Die App ist eine dünne Hülle. Sie kümmert sich um Anmeldung, Push-Nachrichten, Kamera, Standort und die Navigationsleiste. Sie zeigt das Portal in WebViews an und stellt die Brücke bereit.

Nativ wird nur, was nativ sein muss. Der Startbildschirm, damit die App in unter einer Sekunde da ist. Die Kamera für das Foto vom Zählerstand oder vom Schaden. Push-Nachrichten für „Ihr Antrag wurde bearbeitet". Der Rest kommt aus dem Web.

Bei einem Stadtwerk sind das typischerweise drei native Bildschirme und dreißig aus dem Web. Bei einer Klinik mit Bewerberportal und Intranet ist das Verhältnis ähnlich.

Wo es sich lohnt und wo nicht

Der Ansatz ist richtig, wenn das Portal bereits als Web-Anwendung existiert oder entsteht, wenn die App-Nutzer dieselben Dinge tun wie die Web-Nutzer, und wenn die App vor allem Erreichbarkeit und einen Platz auf dem Startbildschirm liefern soll.

Er ist der falsche Weg, wenn die App etwas grundsätzlich anderes tun soll als die Website, wenn es um dauerhafte Offline-Arbeit geht, oder wenn Animationen und Gesten den Kern der Anwendung ausmachen. Ein Wanderführer mit Karten im Funkloch braucht eine native App. Ein Zählerstandsformular braucht das nicht.

Wir sagen das im Erstgespräch offen, in beide Richtungen.

Was es kostet, grob

Eine dünne App-Hülle mit Anmeldung, Push, Kamera und Brücke liegt bei uns erfahrungsgemäß zwischen 15 und 25 Personentagen für beide Plattformen, dazu die Veröffentlichung in den Stores und der laufende Betrieb. Das ist ein Bruchteil dessen, was zwei parallel gepflegte Anwendungen kosten, und die Weiterentwicklung findet danach an einer Stelle statt.

Was wir anders machen als Shopify

Shopify hat ein Framework mit eigenem Namen entwickelt, weil 600 Bildschirme und mehrere Apps das rechtfertigen. Für ein Serviceportal reichen die vorhandenen Werkzeuge: Capacitor als Hülle, eine kleine Brücke für Titel, Aktionen und native Funktionen, und die Disziplin, die Web-Oberfläche von Anfang an so zu gestalten, dass sie in der App aussieht, als gehöre sie dahin.

Der Rest ist Handwerk, das man einmal richtig lernt und dann bei jedem Projekt wiederverwendet.

Aus dem ProjektFür einen kommunalen Entsorger entwickeln wir gerade eine Anwendung, bei der Bürger Abfall per Foto einordnen lassen und den Wertstoffhof auf der Karte finden. Die Erkennung, die Karte und die Ergebnisseiten laufen im Web und werden im Browser weiterentwickelt. Die App liefert die Kamera, den Standort und die Push-Nachricht, wenn der Sperrmülltermin ansteht. Wer die App öffnet, merkt den Unterschied zwischen beiden Teilen nur daran, dass die Kamera sofort da ist.

Quelle für den Vergleich: Shopify Engineering, „Mobile Bridge: Making WebViews Feel Native“, April 2025