Erstgespräch
App-Entwicklung

Warum Cross-Platform-Entwicklung?

Diese Seite beantwortet nicht, welche Bauart die richtige ist oder welches Framework. Sie beantwortet die wirtschaftliche Frage dahinter: Was ändert sich, wenn iOS und Android aus einer Codebasis kommen?

Kurz gesagt

Über drei Jahre summieren sich Fehlerbehebungen, jährliche Systemanpassungen und kleine Erweiterungen zu mehr Aufwand als der erste Durchgang. Dieser Teil fällt bei einer Codebasis einmal an statt zweimal. Je öfter ihr nach dem Start ausliefert, desto größer wird der Abstand.

Fällt einmal an
Pflege
Statt zwei
Ein Team
Wächst mit
Jeder Änderung

Der Kern

Was sich mit einer Codebasis ändert

Drei Folgen, die im Projektalltag ankommen. Technisch ist keine davon, deshalb halten sie auch.

  • Eine Änderung erreicht beide Plattformen

    Der praktische Unterschied im Alltag. Eine Korrektur wird einmal gebaut, einmal geprüft, einmal ausgeliefert. Bei zwei Codebasen ist dieselbe Änderung zweimal zu schreiben, zweimal zu prüfen und danach zweimal zu erklären, warum sie auf einer Plattform anders aussieht.

  • Die Versionen driften nicht auseinander

    Getrennte Teams entwickeln unterschiedliche Reihenfolgen und unterschiedliche Auslegungen derselben Anforderung. Das fällt zuerst im Support auf, wenn Antworten davon abhängen, welches Gerät jemand benutzt.

  • Ein Team statt zwei Spezialisierungen

    Das entscheidet sich weniger am Projektbudget als an der Personalplanung. Zwei native Codebasen brauchen dauerhaft Leute für beide Plattformen, auch in ruhigen Jahren.

Die Rechnung

Wo die Ersparnis wirklich herkommt

Der übliche Werbesatz lautet, man spare die Hälfte, weil man nur halb so viel Code schreibe. So funktioniert es nicht, und die tatsächliche Begründung trägt weiter.

  • Nicht dort, wo die meisten sie vermuten

    Die Ersparnis kommt nicht daher, dass halb so viel Code entsteht. Oberfläche und Fachlogik lassen sich teilen, der plattformnahe Teil nicht. Was wirklich wegfällt, ist die doppelte Abstimmung um denselben Code herum.

  • Sie liegt in der Pflege, nicht im Bau

    Der Bau ist der kürzere Abschnitt im Leben einer App. Über drei Jahre summieren sich Fehlerbehebungen, Anpassungen an neue Systemversionen und kleine Erweiterungen zu mehr Aufwand als der erste Durchgang. Genau dieser Teil halbiert sich.

  • Sie wächst mit der Zahl der Änderungen

    Bei einer App, die nach dem Start unangetastet bleibt, ist der Unterschied gering. Bei einer, die vierzehntägig ausgeliefert wird, ist er der größte Posten der Rechnung.

Zeitachse

Über drei Jahre gerechnet

Wer nur den ersten Durchgang vergleicht, vergleicht den kürzesten Abschnitt. Der Unterschied wächst mit jedem Jahr, in dem die App weiterläuft.

  1. 01

    Jahr eins: der Bau

    Hier ist der Unterschied am kleinsten und am leichtesten zu übersehen. Wer nur den ersten Durchgang vergleicht, sieht einen Teil des Bildes.

  2. 02

    Jahr zwei: die Pflichtarbeiten

    Apple und Google ändern jedes Jahr Anforderungen an Zielversionen, Berechtigungen und Datenschutzangaben. Diese Arbeit fällt pro Codebasis an, nicht pro App.

  3. 03

    Jahr drei: die Weiterentwicklung

    Bis hierhin hat sich meist herausgestellt, was tatsächlich benutzt wird. Was dann gebaut wird, ist der Teil, bei dem die gemeinsame Codebasis den größten Unterschied macht, weil jede Änderung doppelt zählt.

Grenzen

Wo die Rechnung nicht aufgeht

  • Der plattformnahe Anteil ist groß

    Je mehr eigene native Module gebraucht werden, desto kleiner wird der Vorteil. Für diese Stücke brauchst du wieder Wissen über beide Plattformen, und dann zahlst du den gemeinsamen Aufbau, ohne ihn auszunutzen.

  • Es gibt bereits zwei eingespielte native Teams

    Wenn zwei eingespielte Teams produktiv arbeiten, ist die Umstellung ein eigenes Projekt. Sie rechnet sich meist erst, wenn sowieso ein größerer Umbau ansteht.

  • Die App ist der Grenzfall aus dem Vergleich

    Dauerhaft hohe Bildrate, aufwendige Grafik, AR oder laufende Sensorauswertung. Hier programmierst du sowieso dicht am System, und die gemeinsame Schicht bringt dir nichts mehr.

FAQ

Häufige Fragen

Wie groß ist die Ersparnis tatsächlich?

Belastbar ist die Struktur, nicht eine Prozentzahl: eine Codebasis statt zwei, ein Team statt zweier Spezialisierungen, über die gesamte Laufzeit. Wie groß der Unterschied im konkreten Fall ausfällt, hängt am Anteil plattformnaher Funktionen und daran, wie oft nach dem Start ausgeliefert wird. Wer dir vorab eine feste Prozentzahl nennt, kennt dein Vorhaben nicht.

Leidet die Qualität darunter?

Nicht durch die Bauart. Cross-Platform-Apps stehen in beiden Stores und durchlaufen dieselbe Prüfung. Was leidet, wenn man nicht aufpasst, ist das Plattformgefühl: eine App, die auf beiden Systemen exakt gleich bedient wird, fühlt sich auf mindestens einem falsch an.

Was passiert, wenn wir doch nativ brauchen?

Einzelne Teile lassen sich als natives Modul ergänzen, ohne den Rest anzufassen. Das ist der übliche Weg und einer der Gründe, warum die Entscheidung weniger endgültig ist, als sie sich anfühlt.

Kann man später zurück auf nativ?

Ja, meist schrittweise: einzelne Bereiche werden ersetzt, der Rest bleibt. Wie teuer das wird, hängt daran, wie sauber Fachlogik und Datenzugriff von der Oberfläche getrennt sind.

Lässt sich daraus auch eine Web-Version machen?

Teilweise. Fachlogik und Datenzugriff lassen sich weiterverwenden, die Oberfläche selten unverändert, weil im Browser andere Bedienmuster gelten. Es ist ein Vorsprung, keine kostenlose dritte Plattform.

Womit arbeitet ihr?

React Native und Expo, auch für unsere eigenen Produkte. TypeScript trägt bei uns App, Backend und Web, was Wissen zwischen Projekten beweglich hält.

Nächster Schritt

Wie die Rechnung für dein Vorhaben aussieht.

Entscheidend sind zwei Angaben: wie groß der plattformnahe Anteil ist und wie oft nach dem Start ausgeliefert werden soll. Damit lässt sich der Unterschied für deinen Fall beziffern statt allgemein behaupten.

Erstgespräch vereinbaren →