Welche App braucht ihr wirklich? Und was kostet der Unterschied?
Wenn jemand sagt „Wir brauchen eine App", steckt dahinter selten eine technische Entscheidung. Meistens steckt ein Wunsch dahinter: Nutzer:innen sollen etwas auf dem Handy tun können. Schnell. Mit Icon auf dem Homescreen. Vielleicht im App Store. Vielleicht auch offline.
Das Problem: Zwischen „läuft im Browser" und „native App" liegen vier grundverschiedene Ansätze, mit enormen Unterschieden bei Aufwand, Kosten und Ergebnis. Und die richtige Wahl hängt fast nie von der Technologie ab, sondern von zwei Fragen.
Frage 1: Muss die App in den Store?
Viele Projekte brauchen gar keine Store-Präsenz. Eine klassische Web-App läuft auf jedem Gerät mit Browser, ist sofort updatebar und braucht keine App-Store-Freigaben. Oft ist das der schnellste und günstigste Weg zu einem funktionierenden Produkt.
Wird Offline-Fähigkeit wichtig oder soll die App flexibel auf verschiedenen Geräten laufen, lohnt sich der Schritt zur Progressive Web App (PWA). Technisch baut das direkt auf der bestehenden Web-App auf: Service Worker, Web Manifest, fertig. Die App kann auf dem Homescreen installiert werden, läuft ohne Browser-UI und funktioniert auch ohne Netz. Und weil es eine Web-App bleibt, läuft sie genauso auf dem Desktop. In der Praxis erleben wir das regelmäßig: Eine App, die als mobile Lösung gedacht war, wird am Ende auch am Desktop genutzt, oder umgekehrt.
Ein konkretes Beispiel: Für die grewe-Gruppe haben wir eine Baustellen-App als PWA entwickelt. Zeiterfassung, Teamplanung und Maschinenverwaltung, auch ohne Mobilfunkempfang auf der Baustelle. Installierbar auf dem Homescreen, offline-fähig mit automatischer Synchronisierung bei Netzverbindung. Allein bei der Teamplanung konnte der Aufwand pro Bauleiter:in von acht Stunden im Monat auf drei Stunden im Jahr reduziert werden.
Der Haken bei PWAs: Unter Android ist die Situation noch recht komfortabel. Die Installation aus dem Browser heraus ist prominent, und Google ermöglicht es sogar, Web-Apps als sogenannte Trusted Web Activities in den Play Store zu bringen. Auf iOS sieht es anders aus. Die Installation ist immer noch versteckt, „Zum Home-Bildschirm hinzufügen" kennen die wenigsten Nutzer:innen, und im Apple App Store taucht die App nicht auf.
Wenn Store-Präsenz tatsächlich wichtig ist, etwa weil Endkund:innen die App dort erwarten oder weil potenzielle Nutzer:innen im Store nach einer Lösung suchen, gibt es einen pragmatischen Mittelweg: die Hybrid-App. Die bestehende Web-App wird in einen nativen Container gepackt. Für Nutzer:innen sieht es aus wie eine App aus dem Store. Technisch ist es ein WebView. Man bleibt komplett im Web-Stack und bekommt trotzdem Store-Listung, Push-Notifications und tieferen Zugriff auf Gerätefunktionen wie Bluetooth, NFC oder das Dateisystem.
Für die meisten B2B-Apps und viele B2C-Produkte ist das die pragmatischste Antwort. Nicht die eleganteste: Manchmal fühlt sich das Scrolling oder das Klick-Feedback subtil anders an als bei nativen Apps. Aber für den Großteil der Anwendungsfälle fällt das nicht ins Gewicht. Bekannte Beispiele für diesen Ansatz sind etwa die Apps von Burger King, JustWatch oder MarketWatch, die alle auf Web-Technologie in einem nativen Container setzen.
Was man dabei im Kopf behalten sollte: Sobald eine App in den Store geht, gelten die Spielregeln der Plattformen. Releases müssen durch teils langwierige Review-Prozesse, Zertifikate wollen verwaltet werden, und Apple wie Google haben eigene Richtlinien dafür, was eine App darf und was nicht. Das ist kein Blocker, aber ein Faktor, den man bei der Planung einrechnen sollte.
Frage 2: Ist die App euer Produkt?
Hier wird es grundsätzlicher. Wenn die App nicht Mittel zum Zweck ist, sondern das Produkt selbst, eine Consumer-App, mit der Menschen täglich arbeiten, bei der sich die Experience direkt im Geschäftserfolg niederschlägt, dann reicht ein WebView-Wrapper irgendwann nicht mehr.
Cross-Platform-Frameworks mit nativer UI
Der nächste Schritt sind Frameworks wie React Native oder Flutter, die echte native UI-Komponenten rendern, statt eine Web-App im Container darzustellen. Die Logik wird einmal geschrieben, die Oberfläche fühlt sich aber auf beiden Plattformen nativ an. Animationen laufen flüssiger, Gesten fühlen sich echt an, und der Unterschied zu einer rein nativen App ist für Nutzer:innen kaum spürbar.
Aber, und das ist wichtig: Der Schritt von Hybrid zu einem solchen Framework ist kein graduelles Upgrade. Es ist eine Grundsatzentscheidung. Anderes Tooling, anderes Debugging, anderes Denken. Code-Sharing zwischen Web und einer React-Native- oder Flutter-App ist möglich, vor allem bei der Business-Logik. Das UI muss man aber größtenteils neu bauen.
Wer diesen Weg geht, sollte das bewusst tun. Nicht, weil es technisch spannend klingt, sondern weil die Anforderungen es verlangen.
Komplett nativ
Und dann gibt es noch den Weg über komplett nativen Code: Swift oder Objective-C für iOS, Kotlin oder Java für Android. Maximale Performance, sofortiger Zugang zu den neuesten Betriebssystem-Features, keine Abhängigkeiten von Bridges oder Frameworks. Aber auch: zwei getrennte Codebases, die mit der Zeit auseinanderdriften können, mehr spezialisiertes Personal und damit deutlich höhere Kosten. Und wenn zusätzlich noch eine Web-App oder ein eigenständiges Backend dazukommt, sind es schnell drei parallele Codebases, die gepflegt werden wollen.
Was wir empfehlen, und warum
Wir kommen aus der Web-Entwicklung und haben dort tiefe Expertise, von Frontend über Backend bis hin zu Infrastruktur. Das beeinflusst unsere Perspektive, und wir sind da transparent.
Für die meisten Projekte, die bei uns landen, ist der richtige Weg eine PWA oder eine Hybrid-App. Überschaubarer Aufwand, geringere Kosten, keine unnötige Komplexität. Cross-Platform-Frameworks wie React Native kommen ins Spiel, wenn die App das Kernprodukt ist und sich für Nutzer:innen perfekt anfühlen muss. Und wenn die Anforderungen klar in Richtung nativ zeigen, finden wir auch dafür den richtigen Weg.
Die wichtigste Frage ist am Ende nicht „Was ist technisch möglich?", sondern: Was braucht ihr wirklich, und was kostet der Unterschied?
Wenn ihr gerade vor dieser Entscheidung steht, sprecht uns an. Wir helfen euch, den Weg zu finden, der zu eurem Produkt, eurem Budget und euren Nutzer:innen passt.
