Web-App oder native App: Unterschiede und Entscheidung

Was eine Web-App ist

Eine Web-App läuft im Browser und wird über eine Adresse aufgerufen. Sie funktioniert auf dem Rechner im Büro, auf dem Tablet und auf dem Smartphone, ohne dass jemand etwas aus einem Store laden muss. Eine neue Fassung liegt auf dem Server und ist beim nächsten Aufruf für alle da; niemand muss ein Update einspielen.

Eine native App wird dagegen für ein bestimmtes System gebaut, etwa für Android oder iOS, und über den jeweiligen Store oder einen eigenen Download verteilt. Sie läuft direkt auf dem Gerät und kann tiefer auf dessen Funktionen zugreifen.

Installierbar und auch ohne Verbindung

Der Unterschied ist kleiner geworden. Eine Web-App kann als Progressive Web App gebaut werden. Laut MDN läuft sie dann aus einer gemeinsamen Codebasis auf mehreren Plattformen und Geräten, lässt sich auf dem Gerät installieren und kann auch ohne Netz arbeiten. Für Nutzerinnen und Nutzer sieht das aus wie eine App: ein Symbol auf dem Startbildschirm, ein eigenes Fenster ohne Adressleiste.

Möglich macht das ein Service Worker. MDN beschreibt ihn als Vermittler zwischen Web-App, Browser und Netz: Er kann Anfragen abfangen, Inhalte für den Betrieb ohne Verbindung bereithalten und den Zugang zu Push-Mitteilungen und Abgleich im Hintergrund öffnen. So kann zum Beispiel ein Formular im Keller ausgefüllt und gesendet werden, sobald wieder Netz da ist.

Mitteilungen auf iPhone und iPad

Ein häufiger Grund für eine native App waren Mitteilungen auf dem Sperrbildschirm. Seit iOS und iPadOS 16.4 unterstützt Safari laut WebKit Web-Push für Web-Apps, allerdings nur für Web-Apps, die zum Home-Bildschirm hinzugefügt wurden. Die Erlaubnis darf eine solche Web-App erst nach einer Handlung der Nutzerin oder des Nutzers erfragen, etwa nach einem Tipp auf „Mitteilungen einschalten“. Mit derselben Version kamen Kennzeichen am App-Symbol hinzu, zum Beispiel die Zahl neuer Nachrichten.

Für die Praxis heißt das: Mitteilungen gehen auch mit einer Web-App, aber nur bei Menschen, die sie vorher auf den Home-Bildschirm gelegt haben. Bei einer Anwendung für das eigene Team lässt sich das bei der Einführung einmal zeigen. Bei Kundschaft, die nur gelegentlich vorbeischaut, ist es eine Hürde.

Wo eine native App im Vorteil ist

Nicht jede Gerätefunktion steht im Browser zur Verfügung. Ein Beispiel ist Bluetooth: MDN führt die Schnittstelle Web Bluetooth als experimentell und als nicht in allen verbreiteten Browsern verfügbar. Soll eine Anwendung Messgeräte, Drucker oder Sensoren per Bluetooth ansprechen, ist eine native App meist der verlässlichere Weg.

Auch wenn eine Anwendung dauerhaft auf einem Gerät laufen soll, spricht vieles für eine native App. Die Android-App von DisplaySync, einem eigenen Produkt von ARENJA, läuft als Startbildschirm des Geräts und spielt Videos über eine eigene Wiedergabe ab, damit sie ruhig laufen. Die Steuerung kommt trotzdem aus einer Web-Anwendung. Native App und Web-App ergänzen sich hier.

Schließlich erwarten manche Zielgruppen eine App im Store, weil sie dort danach suchen. Dafür braucht es Entwicklerkonten bei Google und Apple, und jede Fassung durchläuft die Prüfung der Stores.

Eine Grundlage für mehrere Systeme

Native heißt nicht, dass alles doppelt entstehen muss. Mit Kotlin Multiplatform lassen sich laut Hersteller Geschäftslogik, Datenmodelle, Netzwerkzugriffe und Prüfregeln für Android, iOS und weitere Plattformen gemeinsam nutzen, ohne die eigene Oberfläche jedes Systems aufzugeben. Für Programme auf dem Rechner baut Electron Anwendungen für Windows, macOS und Linux aus JavaScript, HTML und CSS, also mit derselben Technik wie eine Web-App.

Welche Grundlage passt, hängt davon ab, wie ähnlich die Anwendung auf allen Systemen aussehen soll und wie viel sie vom jeweiligen Gerät braucht.

Fragen für die Entscheidung

• Wer nutzt die Anwendung: das eigene Team, das sie einmal einrichtet, oder Kundschaft, die sie ohne Vorbereitung öffnen soll?
• Auf welchen Geräten: nur Smartphones, auch Rechner im Büro, Tablets an der Theke oder Bildschirme an der Wand?
• Welche Gerätefunktionen braucht sie: Kamera und Standort gehen oft auch im Browser, Bluetooth-Geräte und Betrieb als Startbildschirm eher nicht.
• Muss sie ohne Verbindung arbeiten, und wie lange?
• Sind Mitteilungen wichtig, und dürfen Nutzerinnen und Nutzer dafür einen Schritt mehr machen?
• Soll die Anwendung im Store gefunden werden, oder reicht eine Adresse, die Sie selbst verteilen?

Oft ist die Antwort eine Kombination: Verwaltung und Kundenbereich im Browser, eine App dort, wo Gerätefunktionen gebraucht werden. Klären Sie die Fragen vor der Entwicklung, dann lässt sich der Umfang verlässlich planen.