Schritt für Schritt: die Wahl zwischen mobiler App und Web-App

Mobile App oder Web-App? Eine Frage so alt wie das iPhone, und die Antwort ist noch immer nicht offensichtlich. Bei Web Systems beschäftigen wir uns damit seit 2006 – wir haben als software house in Łódź angefangen und in fast zwei Jahrzehnten Dutzende Projekte beider Arten umgesetzt. Und wissen Sie was? Es gibt keine einzig richtige Antwort. Jeder Fall ist anders. Es hängt vom Budget ab, von der Zielgruppe, vom Zeitplan, von den geschäftlichen Anforderungen. Diesen Leitfaden habe ich auf Basis echter Umsetzungen geschrieben, nicht anhand von Lehrbuchvergleichen. Ich zeige Ihnen, wie Sie dieses Dilemma angehen, ohne ins Blaue zu schießen, denn wir sehen regelmäßig Kunden, die nach gescheiterten Projekten bei der Konkurrenz zu uns kommen. Und jedes Mal begann das Problem mit einer falschen Entscheidung zu Beginn.

Worin sich eine mobile App und eine Web-App eigentlich unterscheiden

Eine Web-App läuft im Browser. Ohne Installation. Das kann eine klassische Website sein, eine Single Page Application (SPA), die dynamisch auf Klicks reagiert, oder eine Progressive Web App (PWA) mit teilweisem Offline-Zugriff und einem Symbol auf dem Startbildschirm. Eine native mobile App ist eine ganz andere Geschichte – Software, die für iOS oder Android geschrieben und über den App Store oder Google Play verteilt wird. Und dieser Unterschied im Vertriebskanal verändert alles. Der Browser gegen den App-Store: zwei getrennte Welten mit eigenen Spielregeln.

Wo gewinnen native Apps auf ganzer Linie? Beim Zugriff auf die Hardware. GPS, das im Hintergrund läuft, eine Kamera mit voller Kontrolle über die Parameter, ein biometrischer Sensor, Bewegungssensoren, Push-Benachrichtigungen – all das funktioniert solide nur nativ. Das Web holt schrittweise auf, klar. Aber es reicht bei Flüssigkeit und beim Umfang der Systemintegration noch nicht an native Lösungen heran.

• Vertrieb – eine Web-App ist sofort über eine URL verfügbar, eine mobile muss aus dem Store geladen werden
• Aktualisierungen – eine Web-App aktualisiert sich automatisch, eine mobile erfordert das Laden einer neuen Version (oder ein Review im Store)
• Leistung – eine native App nutzt die Möglichkeiten von Prozessor und GPU des Geräts voll aus
• Offline-Zugriff – eine native App funktioniert ohne Netz, eine PWA bietet einen eingeschränkten Offline-Modus
• SEO – Web-Apps werden in Suchmaschinen indexiert, mobile bleiben für Google unsichtbar
• Einstiegskosten – eine Web-App ist ein Projekt, eine native bedeutet getrennte Umsetzungen für iOS und Android

Tipp: Eine PWA eignet sich als Ersatz für eine native mobile App, wenn Ihr Produkt keinen fortgeschrittenen Hardware-Zugriff, keine Offline-Arbeit mit großen Datenmengen und keine intensiven Grafikoperationen erfordert. Wenn der Hauptwert im Anzeigen von Inhalten und in einfacher Interaktion liegt, sparen Sie mit einer PWA im Vergleich zum nativen Ansatz bis zu 60% des Budgets.

Wann eine Web-App die bessere Wahl ist

Aus unserer Erfahrung heraus setzen wir die meisten B2B-Systeme, Administrationspanels, Analyse-Dashboards und E-Commerce-Plattformen als Web-Apps um. Denn die Nutzer dieser Werkzeuge sitzen am Schreibtisch, arbeiten an großen Bildschirmen und wollen schnellen Zugriff, ohne etwas zu installieren. Ein Panel zur Auftragsverwaltung, ein CRM, ein Werkzeug für Verkaufsberichte – all das passt naturgemäß in den Browser. Geben Sie jemandem eine URL, und fertig. Keine Einstiegshürde, und das Onboarding neuer Leute im Unternehmen dauert Minuten statt Stunden.

Und dann die Kosten. Eine Web-App ist in der Herstellung schlicht günstiger. Sie pflegen eine Codebasis statt zwei getrennter Projekte für iOS und Android. Ein Team, ein Testprozess, eine Deployment-Pipeline. Das Ergebnis? Eine kürzere Time-to-Market. Und das kann entscheidend sein, wenn Sie eine Geschäftsidee schnell validieren müssen. Wir schlagen Kunden regelmäßig vor, mit einem Web-MVP zu starten, bevor sie viel Geld in eine native mobile App stecken.

„Das wichtigste Prinzip ist die Trennung der Verantwortlichkeiten – die Aufteilung der Anwendung in Methoden, Klassen, Dateien, Pakete, Module und Schichten mit klar definierten Verantwortungsbereichen und Grenzen.”

Dieses Prinzip gilt in der Web-Welt genauso. Eine sauber aufgesetzte SPA mit getrennten Schichten für UI, Geschäftslogik und Datenzugriff ist deutlich leichter zu pflegen als monolithischer Code. React, Vue, Angular – mit diesen Technologien lassen sich Oberflächen bauen, die Desktop-Anwendungen an Flüssigkeit in nichts nachstehen. Das habe ich in eigenen Projekten vielfach überprüft.

Tipp: Bevor Sie Budget für eine native mobile App ausgeben, validieren Sie Ihre Idee mit einem Web-MVP. Drei Monate, in denen Sie Daten zum Nutzerverhalten sammeln, sagen Ihnen mehr als der beste Businessplan. Wenn 80% des Traffics von mobilen Geräten kommt, ist das ein klares Signal, dass sich die Investition in ein natives Erlebnis lohnt.

Wann Sie ohne eine mobile App nicht auskommen

Es gibt Situationen, in denen eine Web-App die Sache schlicht nicht liefert. Ihr Produkt muss offline funktionieren, sagen wir eine Anwendung für Servicetechniker, die ohne Netzabdeckung im Außendienst arbeiten? Eine native App mit lokaler Datenbank ist dann die einzig sinnvolle Option. Ebenso, wenn Sie die Kamera ernsthaft brauchen, dazu Bewegungssensoren, Bluetooth Low Energy oder Geolokalisierung im Hintergrund. Der Browser hat seine Grenzen, und keine JavaScript-Bibliothek überspringt sie.

Es geht aber auch um die Flüssigkeit der Oberfläche. Komplexe Animationen, Multitouch-Gesten, sofortige Reaktion auf jedes Antippen: Hier hängen native Apps das Web schlicht ab. Spiele, Fitness-Apps mit Visualisierungen in Echtzeit, Werkzeuge zur Bildbearbeitung. Jede Millisekunde Verzögerung bedeutet ein schlechteres Nutzererlebnis. Und der Nutzer spürt das, auch wenn er nicht sagen kann, warum.

„Mobile Geräte – selbst solche mit großen Bildschirmen – haben begrenzte Ressourcen, deshalb kann das Betriebssystem jederzeit den Prozess einer Anwendung beenden, um die Ressourcen anderen Prozessen zu übergeben.”

Diese Einschränkung erzwingt eine durchdachte Architektur. Native SDKs bieten Werkzeuge, um den Lebenszyklus der Anwendung zu steuern, den Zustand zu sichern und die Sitzung wiederherzustellen, nachdem das System etwas beendet hat. Web-Technologien? Sie haben keine so präzise Kontrolle über diese Mechanismen. Da braucht man sich nichts vorzumachen.

1. Ihre Nutzer brauchen Offline-Funktionen in Umgebungen ohne stabiles Internet
2. Das Produkt nutzt intensiv die Kamera, GPS im Hintergrund, den Beschleunigungssensor oder andere Sensoren
3. Push-Benachrichtigungen sind ein zentraler Kommunikationskanal zu den Nutzern
4. Sie benötigen die Integration mit Systemfunktionen wie HealthKit, Google Fit oder NFC-Zahlungen
5. Flüssige Animationen und eine sofort reagierende Oberfläche entscheiden über die Nutzerbindung
6. Das Geschäftsmodell setzt auf die Präsenz im App Store oder bei Google Play als Kanal zur Kundengewinnung

Kosten, Umsetzungszeit und verborgene Risiken beider Wege

Die Kosten einer Web-App und einer mobilen App nur auf der Ebene der Umsetzung zu vergleichen? Das ist der häufigste Fehler, den wir bei Kunden sehen. Eine einfache Web-App kostet zwischen 50 und 150 Tausend Złoty. Eine native für eine mobile Plattform zwischen 100 und 250 Tausend. Für beide? Fast der doppelte Betrag. Cross-Platform (Flutter, React Native) liegt irgendwo dazwischen und spart 30-40% im Vergleich zu zwei nativen Umsetzungen. Doch diese Zahlen sind erst der Anfang.

Die verborgenen Kosten mobiler Apps können selbst erfahrene PMs umhauen. Apple und Google nehmen 15-30% Provision auf Transaktionen in der Anwendung. Der Review-Prozess in den Stores kann die Auslieferung eines kritischen Hotfixes um mehrere Tage verzögern (und nein, beschleunigen lässt sich das nicht). Jede neue Version von iOS oder Android bedeutet Kompatibilitätstests und mögliche Korrekturen am Code. Und die Fragmentierung der Android-Geräte? Tests auf Dutzenden Auflösungen, Systemversionen und Oberflächen von Samsung, Xiaomi oder Huawei. Ein Albtraum.

Wenn Sie das über mehrere Jahre betrachten, ändert sich das Bild komplett. Die Pflege einer mobilen App auf zwei Plattformen kostet jährlich 15-25% des Werts der ursprünglichen Umsetzung. Aktualisierungen von Bibliotheken, Anpassungen an neue Systemversionen, Crash-Monitoring, Reaktion auf geänderte Store-Richtlinien: ein ständiger Strom an Arbeit, der nie endet. Eine Web-App verursacht geringere Pflegekosten, auch wenn sie ebenfalls regelmäßige Updates der Abhängigkeiten und das Schließen von Sicherheitslücken erfordert.

Tipp: Rechnen Sie beim Projektbudget einen Puffer von 25-30% für unvorhergesehene Ausgaben ein. Berücksichtigen Sie die Kosten der ersten 12 Monate Pflege schon vor dem Start der Entwicklungsarbeiten. Bei Web Systems zeigen wir Kunden immer die TCO (Total Cost of Ownership) über 3 Jahre, nicht nur die Kosten der Umsetzung selbst. Ein solch realistisches Finanzbild verhindert Situationen, in denen das Geld für den Betrieb eines laufenden Produkts fehlt.

Hybrider und Cross-Platform-Ansatz – lohnt sich der Kompromiss

Flutter, React Native, Kotlin Multiplatform – alle versprechen dasselbe: einmal schreiben, auf beiden Plattformen starten. Und in vielen Fällen hält dieses Versprechen. Aber nicht immer. Cross-Platform funktioniert hervorragend bei Anwendungen mit Standard-UI, typischer Navigation und maßvoller Nutzung der Hardware. Informations-Apps, E-Commerce-Plattformen, Werkzeuge zur Aufgabenverwaltung: Hier sparen Sie Zeit und Budget ohne sichtbare Qualitätseinbußen.

Das Problem beginnt bei tiefer Integration mit der Plattform. Fortgeschrittenes ARKit unter iOS, spezifisches Verhalten von Material Design unter Android, nicht standardmäßige UI-Komponenten: An diesen Stellen erzeugt Cross-Platform technische Schulden. Umgehungen, native Bridges, plattformspezifischer Code. Und plötzlich ist der Hauptvorteil, die gemeinsame Codebasis, dahin. Ich habe selbst Projekte gesehen, in denen 40% des Cross-Platform-Codes am Ende doch für jedes System getrennt geschrieben werden mussten. Und wozu soll das gut sein?

Die Strategie, die wir Kunden häufig vorschlagen, ist ein zweistufiger Ansatz. Zuerst setzen wir eine solide Web-App auf – responsiv, performant, mit ordentlich entworfener API. Später, wenn Marktdaten bestätigen, dass die Nutzer tatsächlich ein natives mobiles Erlebnis wollen, erweitern wir das Ökosystem um eine eigene App. Die API ist schon da, die Geschäftslogik getestet, das Team kennt die Domäne. Minimales Risiko, und das Geld fließt dorthin, wo es den größten Ertrag bringt.

Unsere Erfahrungen mit Flutter in mittelgroßen Projekten sind positiv, besonders wenn der Kunde auf beiden mobilen Plattformen präsent sein muss, aber ein begrenztes Budget hat. React Native wiederum bewährt sich in Teams, die tief in JavaScript stecken, denn es erlaubt, Wissen zwischen Web-Frontend und Mobile zu teilen. Alles in allem logisch.

Wie Sie an die Entscheidung herangehen – eine praktische Checkliste

Bevor Sie sich für eine Technologie entscheiden, beantworten Sie sich ehrlich einige Fragen zu Ihrem Produkt und Ihrem Markt. Bei uns beginnt jedes Projekt mit einem Discovery-Workshop: Wir setzen uns mit dem Kunden zusammen und gehen die Entscheidungsmatrix durch. Wir drängen keine Lösung auf. Wir sammeln Daten, damit die Entscheidung bewusst fällt. Denn zu oft kommen Leute mit der festen Überzeugung zu uns, sie „müssen eine mobile App haben”, während eine responsive Web-App die Sache genauso gut erledigen würde. Oder besser.

• Wer ist Ihr Nutzer? Eine Fachkraft am Schreibtisch oder jemand im Außendienst mit dem Smartphone?
• Welche Hardware-Funktionen sind unverzichtbar? Kamera, GPS im Hintergrund, Bluetooth – braucht Ihr Produkt sie wirklich?
• Wie sieht das Budget für die ersten 3 Jahre aus? Berücksichtigen Sie Umsetzung, Pflege, Aktualisierungen und Weiterentwicklung
• Welche Time-to-Market ist akzeptabel? Können Sie sich 6-9 Monate Entwicklung einer nativen App leisten?
• Ist der Offline-Modus kritisch? Wirklich kritisch, nicht nur „wäre schön zu haben”
• Wie sieht die Vertriebsstrategie aus? SEO und organischer Traffic gegen Präsenz in den App-Stores

Die Entscheidungsmatrix stützt sich auf vier Achsen: Zielgruppe, benötigte Funktionen, verfügbares Budget und zulässige Umsetzungszeit. Ihre Zielgruppe sind Unternehmensleute am Laptop? Dann brauchen Sie keine native mobile App. Die Funktionen verlangen Gerätesensoren und das Budget trägt 12 Monate Entwicklung? Dann ergibt der native Weg Sinn. Die meisten Fälle liegen jedoch irgendwo zwischen diesen Extremen. Und die Antwort ist meist ein stufenweiser Ansatz.

Prototyping und Marktvalidierung vor der endgültigen Technologieentscheidung zahlen sich vielfach aus. Ein klickbarer Prototyp in Figma, getestet an einer Gruppe der Zielnutzer, deckt Lücken in den Annahmen schneller auf als Monate des Programmierens. Ebenso wichtig ist, mit wem Sie arbeiten. Suchen Sie einen Technologiepartner, der Projekte beider Arten umgesetzt hat und objektiv beraten kann, ohne die Lösung zu bevorzugen, auf die er sich gerade selbst spezialisiert hat.

FAQ

Kann ich mit einer Web-App starten und später eine mobile hinzufügen?

Ja, und ehrlich gesagt empfehlen wir das oft. Entscheidend ist, von Anfang an eine solide API zu entwerfen. Eine Web-App, die über eine REST API oder GraphQL mit dem Backend kommuniziert, bildet das Fundament, an das Sie später eine native mobile App anschließen, ohne die Server-Logik neu zu schreiben. Wichtig ist, dass die Architektur den mehrkanaligen Zugriff auf Daten vom ersten Tag an vorsieht. Die Kosten für das Hinzufügen einer mobilen App in der zweiten Stufe sind geringer, weil Backend, Datenbank und Geschäftslogik bereits existieren und den Praxistest in der Produktion bestanden haben.

Was kostet die Pflege einer mobilen App im Vergleich zu einer Web-App?

Die jährlichen Pflegekosten einer nativen mobilen App auf zwei Plattformen liegen üblicherweise bei 15-25% des Werts der ursprünglichen Umsetzung. Dazu gehören Aktualisierungen für neue Versionen von iOS und Android, Stabilitäts-Monitoring, Korrekturen von Fehlern aus der Nutzerschaft und Anpassungen an geänderte Store-Richtlinien. Eine Web-App ist günstiger in der Pflege, meist 10-15% pro Jahr, denn das Verfolgen von Änderungen in zwei mobilen Ökosystemen und die Reviews in den Stores entfallen. Der Unterschied wird nach einigen Jahren beträchtlich.

Ist eine PWA eine gute Alternative zur nativen mobilen App?

Das hängt vom Projekt ab. Eine PWA bewährt sich dort, wo der Hauptwert im Darstellen von Inhalten, in einfacher Interaktion mit dem Nutzer und in grundlegender Offline-Funktionalität liegt. Nachrichtenportale, Produktkataloge, einfache Geschäftswerkzeuge: In diesen Fällen liefert eine PWA 80% des nativen Erlebnisses zu 40% der Kosten. Ein guter Deal. Die Grenze verläuft dort, wo Sie Push-Benachrichtigungen unter iOS mit voller Kontrolle, fortgeschrittenen Hardware-Zugriff oder die Präsenz in den Stores als Marketingkanal brauchen. Dann gibt es keine Abkürzung: Eine native Lösung ist die einzige Option.

Zusammenfassung

Die Wahl zwischen einer mobilen App und einer Web-App sollte nicht von Trends oder persönlichen Vorlieben abhängen. Es ist eine geschäftliche Entscheidung. Das Nutzerprofil, die benötigten Funktionen, das Budget für Umsetzung und Pflege, die akzeptable Zeit bis zum Markteintritt: Das sind die harten Daten, auf die man sie stützen sollte. Eine universelle Lösung gibt es nicht. Aber eine optimale für Ihren konkreten Fall? Durchaus.

Die Analyse der geschäftlichen Anforderungen sollte an erster Stelle stehen. Vor jedem Gespräch über Technologie. Zu oft sehen wir die umgekehrte Reihenfolge: Der Kunde kommt mit dem Wunsch „ich will eine mobile App” statt mit dem geschäftlichen Problem, das diese App lösen soll. Ein gut geführter Discovery-Workshop spart Monate an Arbeit und Zehntausende Złoty. Denn er deckt falsche Annahmen auf, bevor irgendjemand die erste Codezeile schreibt.

Wenn Sie vor der Entscheidung über die Technologie für Ihr digitales Produkt stehen, lassen Sie uns sprechen. Bei Web Systems helfen wir Unternehmen seit 2006, von der Idee zu einer funktionierenden Lösung zu kommen – ganz gleich, ob es eine Web-App, eine mobile oder eine hybride wird. Kontaktieren Sie uns, um eine kostenlose technische Beratung zu vereinbaren und gemeinsam festzulegen, welcher Weg Ihren geschäftlichen Zielen am besten entspricht.