Native App oder Webanwendung: nach welchen Kriterien Unternehmen entscheiden

Ob eine native App oder eine Webanwendung passt, entscheidet sich an den Aufgaben, die das Programm ohne Zutun des Nutzers erledigen muss, und an den Gerätefunktionen, die es braucht. Für Erfassung, Übersichten und Freigaben reicht meist der Browser; dauerhafter Hintergrundbetrieb und tiefer Gerätezugriff sprechen für eine installierte App.

Native App und Webanwendung: die Begriffe

Als nativ gilt ein Programm, das für ein Betriebssystem gebaut und über dessen Store installiert wird, also für iOS oder Android. Es spricht die Schnittstellen des Systems direkt an und darf mehr, als eine Webseite je dürfte. Dafür gibt es in der Regel zwei Codebasen oder eine Zwischenschicht, die beide Systeme bedient.

Eine Webanwendung läuft im Browser und auf jedem Gerät, das einen modernen Browser mitbringt. Als Progressive Web App lässt sie sich zusätzlich auf dem Startbildschirm ablegen und übersteht Funklöcher. Sie wird über einen Link verteilt und bei jedem Öffnen auf dem neuesten Stand geladen.

Vier Kriterien für die Entscheidung

Arbeit ohne Nutzer

Muss das Programm Standortdaten aufzeichnen, während das Telefon in der Tasche steckt, oder nachts Daten abgleichen, stößt der Browser an seine Grenzen. Solche Aufgaben erledigt eine native App oder ein Server, der die Arbeit übernimmt und das Ergebnis bereitstellt.

Gerätefunktionen

Kamera, Mikrofon, Standort und Dateien stehen auch im Browser bereit. Bluetooth-Geräte, NFC-Karten, besondere Scanner oder die Anbindung an Fahrzeugelektronik sind dagegen meist Fälle für native Entwicklung, weil nicht jeder Browser diese Schnittstellen anbietet.

Verteilung

Richtet sich das Programm an die breite Öffentlichkeit, ist der Store ein Vertriebskanal und die Auffindbarkeit dort ein Argument. Für Mitarbeiter, Partner und bestehende Kunden ist er eher ein Hindernis: Konten, Prüfungen jeder Fassung und verzögerte Updates kommen hinzu, ohne dass jemand die App im Store sucht.

Pflege über Jahre

Betriebssysteme ändern ihre Vorgaben jedes Jahr, und Store-Programme müssen mitziehen, sonst verschwinden sie oder verlieren Funktionen. Eine Webanwendung ist davon weniger betroffen. Wer über die Laufzeit rechnet, bezieht diese Pflege ein, wie es der Beitrag zur App-Wartung beschreibt.

Hybride Wege und ihre Kosten

Zwischen beiden Welten liegen Rahmenwerke, die eine gemeinsame Codebasis in Programme für beide Stores übersetzen, und Hüllen, die eine Webanwendung in eine installierbare App verpacken. Sie verringern den doppelten Aufwand, heben ihn aber nicht auf. Die Store-Prüfung bleibt, die Anpassung an neue Systemversionen ebenso, und bei Sonderfunktionen wird doch wieder nativer Code nötig.

Ein solcher Mittelweg lohnt sich, wenn ein einzelnes Merkmal den Store erzwingt, der Rest der Anwendung aber im Web bestens aufgehoben wäre. Er lohnt sich nicht, wenn er nur gewählt wird, weil »eine richtige App« besser klingt.

Eine Entscheidungsfolge in fünf Fragen

1. Muss das Programm etwas tun, während es geschlossen ist? Wenn ja: nativ oder Serverlösung prüfen.
2. Braucht es eine Gerätefunktion, die Browser nicht zuverlässig anbieten? Wenn ja: nativ.
3. Sucht die Zielgruppe das Programm im Store? Wenn ja: Store-Präsenz einplanen.
4. Lässt sich der Ablauf in wenigen Bildschirmen mit Formularen, Listen und Kamera abbilden? Wenn ja: Webanwendung.
5. Wer pflegt das Programm in drei Jahren, und mit welchem Budget? Die Antwort gehört vor die Entscheidung, nicht dahinter.

Ergibt die Folge kein klares Bild, hilft ein Klickdummy, den eine kleine Gruppe am eigenen Telefon ausprobiert. Dann zeigt sich schnell, ob die vermisste Funktion wirklich gebraucht wird.

Irrtümer rund um die native App

• »Nativ ist immer schneller.« Für Formulare und Listen merkt niemand einen Unterschied. Spürbar wird er bei Spielen, aufwendiger Grafik und großen lokalen Datenmengen.
• »Im Store wirkt es seriöser.« Für interne Werkzeuge zählt, dass die Anwendung am ersten Tag funktioniert, nicht das Symbol im Store.
• »Später können wir immer noch nativ bauen.« Das stimmt, wenn Daten und Geschäftslogik von Anfang an auf dem Server liegen. Steckt die Logik in der Oberfläche, beginnt der Umstieg bei null.

Wie wir die Frage klären

Wir gehen die fünf Fragen mit den Menschen durch, die das Programm später benutzen, nicht nur mit der Geschäftsführung. Die meisten Vorhaben, die wir sehen, landen bei einer Webanwendung; wo ein Fall den Store verlangt, sagen wir das vor dem Angebot. Wie die Umsetzung dann aussieht, beschreibt die Seite App-Entwicklung.