Mobile App entwickeln lassen: Native, Cross-Platform oder Web-App?
Der teuerste Kostentreiber ist nicht der Bau, sondern zwei Codebasen für immer. Wie man zwischen nativ, Cross-Platform und Web-App entscheidet — nach Bedarf, nicht nach Trend.
Die Frage kommt fast immer als Wunsch nach einer App. Die richtige Antwort hängt selten an der Lieblingstechnologie und fast immer an einer Zahl, die niemand gern ausspricht: die Wartungskosten über fünf Jahre.
Nativ, Cross-Platform oder Web ist keine Geschmacks-, sondern eine Kosten- und Bedarfsentscheidung.
Der eigentliche Kostentreiber ist nicht der Bau
Zwei native Codebasen (iOS und Android) plus Backend sind nicht doppelter, sondern dauerhaft mehrfacher Aufwand: zwei Sprachen, zwei Release-Zyklen, zwei Mal jede Änderung, zwei Mal jeder Bug. Der Bau ist einmalig, die Wartung ist für immer. Genau hier entscheidet sich der Preis, nicht im ersten Sprint.
Die drei Optionen ehrlich eingeordnet
1. Nativ (Swift / Kotlin)
Beste Performance, volle Gerätefunktionen, beste Store-Integration — und die höchsten laufenden Kosten. Sinnvoll, wenn tiefe Gerätefunktionen oder maximale Performance die echte Anforderung sind, nicht der Wunsch.
2. Cross-Platform (z. B. React Native)
Eine Codebasis für beide Stores, gute Performance für die meisten Geschäfts-Apps, deutlich geringere Wartung. Der pragmatische Mittelweg, wenn Store-Präsenz nötig ist, aber zwei native Teams nicht zu rechtfertigen sind. React-Erfahrung trägt hier oft direkt (siehe Web-App mit Next.js).
3. Web-App / PWA
Keine Store-Hürde, eine Codebasis, am schnellsten live und am billigsten im Betrieb — solange Offline und tiefe Gerätefunktionen keine harte Anforderung sind. Für viele interne B2B-Prozesse die ehrliche Default-Wahl (siehe PWA oder native App?).
Die Frage vor der Technologie: Wo ist der Nutzer?
Ein Außendienst ohne stabiles Netz, ein Lager mit Scannern, ein Kunde, der einmal im Quartal etwas einreicht — das sind drei völlig verschiedene Anforderungen. Die Plattform folgt aus dem Nutzungskontext, nicht aus dem Org-Chart. Apple und Google setzen zusätzlich Store-Regeln, die Teil des Projektrisikos sind, nicht eine Formalität am Ende.
Wer wartet das in zwei Jahren?
Die unbequemste, wichtigste Frage. Eine native Doppel-App, die niemand dauerhaft pflegen kann, ist teurer als eine etwas langsamere Web-App, die ein bestehendes Team trägt. Technologie, die man nicht warten kann, ist keine Lösung, sondern aufgeschobene Schuld.
Checkliste vor der Mobile-Entscheidung
- Ist der Nutzungskontext klar (Netz, Gerät, Häufigkeit)?
- Sind Wartungskosten über fünf Jahre gerechnet, nicht nur der Bau?
- Ist Store-Präsenz echte Anforderung oder Gewohnheit?
- Werden tiefe Gerätefunktionen wirklich gebraucht?
- Ist geklärt, wer die App in zwei Jahren wartet?
- Wurde Web/PWA als Default geprüft, bevor nativ entschieden wird?
- Ist der erste Schritt klein und messbar, nicht das Gesamtsystem?
Häufige Fragen
Ist nativ nicht immer am besten? Technisch oft, wirtschaftlich selten. Die beste Technik, die man nicht dauerhaft warten kann, ist die teuerste.
Reicht Cross-Platform für Business-Apps? Für die allermeisten ja. Native Höchstleistung braucht es nur, wo Geräte- oder Performance-Anforderungen sie wirklich erzwingen.
Was ist der häufigste teure Fehler? Mit zwei nativen Codebasen starten, ohne den Wartungsaufwand über Jahre eingeplant zu haben.
Können wir mit Web starten und später nativ gehen? Oft ja — wenn Logik und Daten sauber vom Frontend getrennt sind. Genau dafür lohnt sich die Architekturfrage am Anfang.
Fazit
Nativ, Cross-Platform oder Web ist keine Technologiefrage, sondern eine Rechnung: Nutzungskontext, Gerätebedarf, Store-Notwendigkeit, Wartungskosten über Jahre. Wer zuerst klärt, wo der Nutzer ist und wer es pflegt, wählt die billigste tragfähige Option statt die prestigeträchtigste.
Weiterlesen
- PWA oder native App? Die richtige Plattformentscheidung — die Detailachse Offline, Gerät, Store.
- Web-App mit Next.js: B2B-Portal entwickeln — die Web-Grundlage, die oft schon reicht.
Nächster Schritt
Sie wollen eine Mobile-Lösung, aber keine teure Doppelpflege? Beginnen Sie mit einer kurzen Einschätzung Ihrer Anforderungen. Wir klären Nutzungskontext und Wartungsmodell — und wählen die billigste tragfähige Plattform.
Quellen
- Apple Developer, App Store Review Guidelines — developer.apple.com
- Android Developers, Guide to app architecture — developer.android.com
- React, React 19 Release — react.dev