Kurz gesagt
Für die meisten Apps ist Cross-Platform der richtige Standard: eine Codebasis, ein Team, beide Plattformen auf demselben Stand. Nativ lohnt sich, wenn es auf jede Millisekunde ankommt, wenn eine frisch veröffentlichte Systemfunktion sofort gebraucht wird, wenn die Hardware selbst der Kern der App ist, oder wenn die Oberfläche sich in jedem Detail plattformeigen anfühlen muss.
- Der Normalfall
- Cross-Platform
- Vier klare Ausnahmen
- Nativ
- Unser Stack
- React Native
-
Die alte Bauart: eine Website in einer App-Hülle
Cordova, Ionic und Verwandte zeigen eine Webseite in einem eingebetteten Browser. Das merkt man an der Bedienung, und daher stammt der schlechte Ruf hybrider Apps.
-
Die heutige Bauart: echte Bedienelemente des Systems
React Native und Flutter erzeugen die tatsächlichen Bedienelemente der Plattform. Es gibt keinen eingebetteten Browser. Wer heute Cross-Platform sagt, meint fast immer das.
-
Warum das die Debatte verzerrt
Ein großer Teil der Argumente gegen hybride Apps stammt aus der ersten Bauart und wird auf die zweite übertragen. Der Vergleich unten bezieht sich ausschließlich auf die heutige.
| Cross-Platform und native Entwicklung nach Kriterien verglichen | Cross-Platform | Nativ |
|---|---|---|
| Eine für iOS und Android | Je eine pro Plattform | |
| Ein Durchlauf für beide Plattformen | Zwei Durchläufe | |
| Eine Codebasis pflegen | Zwei Codebasen pflegen | |
| Erreichen beide Plattformen gleichzeitig | Nacheinander, die Versionen driften auseinander | |
| Ein Team deckt beides ab | Getrennte iOS- und Android-Entwickler | |
| Aus derselben Codebasis möglich | Getrennt zu bauen | |
| Vollständig, tiefe Zugriffe über native Module | Direkt, ohne Zwischenschicht | |
| Für die allermeisten Apps nicht unterscheidbar | Alles, was das Gerät hergibt | |
| Nah dran, aber nicht in jedem Detail | Exakt die Konventionen der Plattform | |
| Erst, wenn das Framework nachzieht | Ab dem ersten Tag | |
| Vollständig möglich | Vollständig möglich | |
| Dieselben Mechanismen des Systems | Dieselben Mechanismen des Systems |
-
Anwendungen für den Geschäftsbetrieb
Kundenportale, Vertriebswerkzeuge, Buchungen, Verwaltung. Es kommt auf die Fachlogik an, nicht auf das letzte Prozent Leistung aus dem Gerät.
-
Ein erstes Produkt, das sich beweisen muss
Solange niemand weiß, ob die Idee funktioniert, ist eine doppelte Codebasis das teuerste Risiko im Projekt. Ein Durchlauf für beide Plattformen bringt dich schneller an echte Nutzer.
-
Beide Plattformen sollen gleich funktionieren
Wenn iOS und Android denselben Stand haben müssen, ist eine gemeinsame Codebasis der direkte Weg dorthin. Getrennte Teams driften sonst auseinander, und das fällt zuerst dem Support auf.
-
Das Team ist klein
Zwei native Codebasen brauchen dauerhaft Leute für beide Plattformen. Das entscheidet sich weniger am Projektbudget als an der Personalplanung über Jahre.
-
Es kommt auf jede Millisekunde an
Spiele mit anspruchsvoller Grafik, Verarbeitung von Video- oder Audiosignalen in Echtzeit, alles mit dauerhaft hoher Bildrate.
-
Neue Systemfunktionen ab dem ersten Tag
Wenn eine App auf ein frisch veröffentlichtes iOS- oder Android-Feature aufsetzen soll, bevor die Frameworks nachgezogen haben.
-
Die Hardware ist der Kern
AR, 3D-Darstellung, laufende Sensorauswertung. Hier programmierst du sowieso dicht am System, und die Zwischenschicht bringt dir nichts mehr.
-
Die Oberfläche muss plattformeigen wirken
Wenn eine App sich in jedem Detail wie eine Apple- oder Google-App anfühlen soll, sind die plattformeigenen Werkzeuge der kürzere Weg.
Was bedeutet "hybrid" heute eigentlich?
Der Begriff deckt zwei sehr verschiedene Dinge ab. Ältere hybride Apps packten eine Website in einen Container, das erkannte man an der Bedienung. Heutige Cross-Platform-Frameworks wie React Native und Flutter nutzen die echten Bedienelemente des Systems. Wenn von den Nachteilen hybrider Apps die Rede ist, meint das meistens noch die erste Bauart.
Merken Nutzer, ob eine App cross-platform gebaut ist?
In der Regel nicht, solange die Bedienmuster der jeweiligen Plattform eingehalten werden. Auffällig wird es an den Rändern: bei ungewohnten Übergängen, bei Gesten, die sich anders anfühlen als gewohnt, oder wenn ein plattformeigenes Element nachgebaut statt benutzt wurde.
Wie groß ist der Leistungsunterschied wirklich?
Für Listen, Formulare, Karten und Medienwiedergabe ist er im Alltag nicht wahrnehmbar. Spürbar wird er bei dauerhaft hoher Bildrate, aufwendiger Grafik und rechenintensiver Verarbeitung auf dem Gerät. Wer nicht in diese Kategorie fällt, entscheidet die Frage nicht über Leistung.
Können Cross-Platform-Apps alle Gerätefunktionen nutzen?
Ja. Was das Framework nicht mitbringt, ergänzt ihr über ein natives Modul. Dabei schrumpft die Ersparnis, denn für dieses Stück braucht ihr wieder Wissen über beide Plattformen.
Welches Framework empfehlt ihr?
Wir arbeiten mit React Native und Expo. Ausschlaggebend war weniger die Technik als das Umfeld: JavaScript und TypeScript können viele, damit lassen sich Stellen besetzen und über Jahre halten. Flutter ist technisch eine gute Wahl, setzt aber Dart voraus.
Lässt sich eine bestehende native App umstellen?
Ja, und meistens schrittweise: einzelne Bereiche werden ersetzt, während der Rest nativ bleibt. Das ist der risikoärmere Weg, weil die App durchgehend lieferfähig bleibt.
Wie steht es um die Prüfung im App Store?
Beide Bauarten durchlaufen dieselbe Prüfung. Cross-Platform ist kein Ablehnungsgrund. Abgelehnt wird, was gegen die Richtlinien verstößt, unabhängig davon, womit es gebaut wurde.
Was kostet der Unterschied?
Der belastbare Teil der Rechnung ist strukturell: eine Codebasis statt zwei, ein Team statt zweier Spezialisierungen, und das nicht nur in der Entwicklung, sondern über die gesamte Laufzeit. Wie groß die Ersparnis im konkreten Fall ausfällt, hängt am Anteil plattformspezifischer Funktionen.