Native App oder Cross-Platform: was euch die Entscheidung über die Jahre kostet
Nicht die erste Auslieferung entscheidet, sondern die Pflege danach. Beide Plattformen ziehen ihre Anforderungen jedes Jahr nach, und diese Arbeit fällt in jeder Codebasis erneut an.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Gerechnet wird der Bau, bezahlt wird der Unterhalt
In fast jedem Angebotsvergleich steht der Aufwand für das erste Release im Mittelpunkt, und dort gewinnt eine gemeinsame Codebasis erwartungsgemäß. Nur wird eine App nicht einmal gebaut, sondern über Jahre gepflegt, und die Pflege besteht zu einem großen Teil aus Arbeit, die niemand bestellt hat. Apple verlangt seit dem 28. April 2026, dass hochgeladene Apps mit Xcode 26 und einem SDK der 26er-Generation gebaut sind. Google Play verlangt, dass neue Apps und Aktualisierungen ab dem 31. August 2026 mindestens Android 16 mit API-Stufe 36 als Ziel angeben, und dass bestehende Apps mindestens API-Stufe 35 erreichen, um für neue Nutzer überhaupt sichtbar zu bleiben.
Diese Termine wiederholen sich jedes Jahr, und sie bringen jedes Mal Verhaltensänderungen mit, die euer Code beachten muss: neue Berechtigungsdialoge, geänderte Hintergrundregeln, andere Anforderungen an Datenzugriffe. Bei zwei nativen Anwendungen erledigt ihr diese Arbeit zweimal, in zwei Sprachen, mit zwei Testläufen. Bei einer gemeinsamen Codebasis erledigt sie zu einem guten Teil das Framework, allerdings erst dann, wenn das Framework selbst nachgezogen hat, und ihr steht so lange still.
Die zweite unterschätzte Größe ist das Personal. Zwei native Anwendungen brauchen zwei Kompetenzen im Team, und wer nur eine davon besetzt, hat eine Plattform, die immer hinterherhinkt. Eine gemeinsame Codebasis reduziert das auf eine Kompetenz plus ein wenig Plattformwissen, verlagert die Abhängigkeit aber auf ein Framework, dessen Fortbestand ihr nicht steuert. Die ehrliche Frage lautet deshalb nicht, welcher Weg technisch überlegen ist, sondern: Welche Kompetenz könnt ihr über fünf Jahre halten, und welche Abhängigkeit haltet ihr dafür aus?
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Drei Wege an denselben Kriterien
Verglichen werden hier keine Produkte, sondern drei Bauweisen. Innerhalb der mittleren Spalte unterscheiden sich Flutter und React Native in vielen Details, in der Abwägung gegenüber den anderen beiden Wegen verhalten sie sich aber sehr ähnlich.
Nativ je Plattform
Kotlin mit Jetpack Compose für Android, Swift mit SwiftUI für iOS, zwei getrennte Anwendungen
Gemeinsame Codebasis
Flutter oder React Native: eine Codebasis samt Oberfläche, die auf beiden Plattformen läuft
Geteilte Logik, native Oberfläche
Kotlin Multiplatform für Fachlogik und Datenzugriff, Oberfläche wahlweise nativ oder ebenfalls geteilt
| Entscheidungsfrage | Nativ je Plattform | Gemeinsame Codebasis | Geteilte Logik, native Oberfläche |
|---|---|---|---|
| Wie schnell seid ihr am Tag einer neuen Plattformversion einsatzbereit? | Stärke Ihr baut mit dem SDK des Herstellers und könnt ab dem ersten Vorabstand testen. Wenn Apple oder Google eine neue Anforderung veröffentlichen, hängt der Zeitplan allein an eurem Team, nicht an einem Dritten. | Kommt darauf an Ihr wartet darauf, dass das Framework die neue Plattformversion unterstützt, und danach gegebenenfalls noch auf einzelne Zusatzpakete. Bei den großen Frameworks dauert das inzwischen Wochen und nicht mehr Quartale, aber die Reihenfolge bleibt: erst das Framework, dann ihr. | Stärke Die Oberflächenschicht ist nativ und damit sofort anschlussfähig; der geteilte Teil berührt Plattformänderungen an der Oberfläche gar nicht. Betroffen ist er nur dort, wo er selbst auf Systemschnittstellen zugreift. |
| Was kostet die zweite Plattform an Personal? | Schwäche Zwei Sprachen, zwei Oberflächensysteme, zwei Werkzeugketten, zwei Testläufe. Faktisch braucht ihr zwei Kompetenzen im Team, und in kleinen Teams führt das regelmäßig dazu, dass eine der beiden Plattformen dauerhaft hinterherläuft. | Stärke Eine Sprache, ein Oberflächensystem, ein Testlauf für den größten Teil des Verhaltens. Plattformwissen braucht ihr trotzdem, für Signaturen, Store-Einreichung, Berechtigungen und die Fälle, in denen ein Zusatzpaket doch nativen Code braucht. | Kommt darauf an Die Fachlogik entsteht einmal, die Oberfläche zweimal. Das halbiert den Aufwand nicht, entfernt aber die Fehlerquelle, dass dieselbe Regel auf zwei Plattformen unterschiedlich umgesetzt wird, und genau dort entstehen die teuren Abweichungen. |
| Wie nah kommt ihr an Gerätefunktionen heran? | Stärke Alles, was das Betriebssystem anbietet, steht direkt zur Verfügung: Hintergrundverarbeitung, Bluetooth, Kamerasteuerung, Widgets, Uhr, Fahrzeugintegration, Gesundheitsdaten, Verwaltung durch die Unternehmens-IT. | Kommt darauf an Für die verbreiteten Funktionen gibt es gepflegte Pakete. Für alles Ungewöhnliche schreibt ihr eine Brücke in nativem Code, und dann habt ihr doch wieder zwei Plattformen zu pflegen, nur an einer schlechter sichtbaren Stelle. | Stärke Der plattformnahe Teil bleibt nativ und ist damit unbeschränkt. Der geteilte Teil ruft ihn über eine schmale, selbst definierte Schnittstelle auf, was diese Grenze sichtbar und pflegbar hält. |
| Wie sehr fühlt sich die App nach der jeweiligen Plattform an? | Stärke Bedienelemente, Übergänge, Textgrößen, Bedienungshilfen und Systemeinstellungen wie Kontrast oder Schriftgröße kommen ohne Zutun mit. Wer eine App für Menschen baut, die täglich damit arbeiten, merkt diesen Unterschied schnell. | Kommt darauf an Flutter zeichnet die Oberfläche selbst und liefert damit auf beiden Plattformen dasselbe Bild, was für ein starkes Markenbild ein Vorteil und für Systemtreue ein Nachteil ist. React Native bildet auf native Bedienelemente ab und liegt darin näher am System. Bedienungshilfen brauchen in beiden Fällen bewusste Arbeit. | Stärke Die Oberfläche ist die des Systems, mit allem, was daran hängt. Wer stattdessen auch die Oberfläche teilt, landet bei denselben Abwägungen wie in der mittleren Spalte. |
| Wie stabil ist der Unterbau über fünf Jahre? | Stärke Ihr hängt an den Plattformbetreibern selbst, und die haben ein Eigeninteresse an Verlässlichkeit. Google hat im Mai 2026 erklärt, dass Android-Oberflächen mit Compose gebaut werden sollen und die alte View-Welt zwar keine neuen Funktionen mehr bekommt, aber weiter gepflegt und nicht abgekündigt wird. | Kommt darauf an Beide großen Frameworks sind erwachsen geworden: React Native hat mit Version 0.76 vom Oktober 2024 die neue Architektur zur Voreinstellung gemacht und damit die alte Leistungskritik erledigt. Trotzdem hängt ihr an einer Roadmap, die euch nicht gehört, und größere Umstellungen kommen als Projekt und nicht als Aktualisierung. | Kommt darauf an Die geteilte Schicht ist bewusst schmal, das begrenzt den Schaden bei einem Bruch. Compose Multiplatform ist seit Version 1.8.0 vom Mai 2025 auch für iOS als stabil erklärt, womit dieser Weg von der Wette zur Option geworden ist. Ein junges Ökosystem bleibt es trotzdem. |
| Wie groß ist die Einstiegshürde für euer vorhandenes Team? | Schwäche Zwei neue Sprachen und zwei neue Oberflächensysteme, wenn niemand aus dem Mobilbereich kommt. Das ist machbar, aber es ist die längste Anlaufstrecke von allen drei Wegen. | Stärke Ein Team mit Weberfahrung findet sich in React Native schnell zurecht, weil Sprache und Denkweise bekannt sind. Flutter verlangt mit Dart eine neue Sprache, dafür ist der Rahmen in sich geschlossen und der Einstieg gut dokumentiert. | Kommt darauf an Für ein Team, das ohnehin Kotlin schreibt, etwa auf der Serverseite oder in einer bestehenden Android-App, ist das der kürzeste Weg. Für alle anderen ist es der Weg mit dem meisten neuen Vokabular auf einmal. |
Wie schnell seid ihr am Tag einer neuen Plattformversion einsatzbereit?
Ihr baut mit dem SDK des Herstellers und könnt ab dem ersten Vorabstand testen. Wenn Apple oder Google eine neue Anforderung veröffentlichen, hängt der Zeitplan allein an eurem Team, nicht an einem Dritten.
Ihr wartet darauf, dass das Framework die neue Plattformversion unterstützt, und danach gegebenenfalls noch auf einzelne Zusatzpakete. Bei den großen Frameworks dauert das inzwischen Wochen und nicht mehr Quartale, aber die Reihenfolge bleibt: erst das Framework, dann ihr.
Die Oberflächenschicht ist nativ und damit sofort anschlussfähig; der geteilte Teil berührt Plattformänderungen an der Oberfläche gar nicht. Betroffen ist er nur dort, wo er selbst auf Systemschnittstellen zugreift.
Was kostet die zweite Plattform an Personal?
Zwei Sprachen, zwei Oberflächensysteme, zwei Werkzeugketten, zwei Testläufe. Faktisch braucht ihr zwei Kompetenzen im Team, und in kleinen Teams führt das regelmäßig dazu, dass eine der beiden Plattformen dauerhaft hinterherläuft.
Eine Sprache, ein Oberflächensystem, ein Testlauf für den größten Teil des Verhaltens. Plattformwissen braucht ihr trotzdem, für Signaturen, Store-Einreichung, Berechtigungen und die Fälle, in denen ein Zusatzpaket doch nativen Code braucht.
Die Fachlogik entsteht einmal, die Oberfläche zweimal. Das halbiert den Aufwand nicht, entfernt aber die Fehlerquelle, dass dieselbe Regel auf zwei Plattformen unterschiedlich umgesetzt wird, und genau dort entstehen die teuren Abweichungen.
Wie nah kommt ihr an Gerätefunktionen heran?
Alles, was das Betriebssystem anbietet, steht direkt zur Verfügung: Hintergrundverarbeitung, Bluetooth, Kamerasteuerung, Widgets, Uhr, Fahrzeugintegration, Gesundheitsdaten, Verwaltung durch die Unternehmens-IT.
Für die verbreiteten Funktionen gibt es gepflegte Pakete. Für alles Ungewöhnliche schreibt ihr eine Brücke in nativem Code, und dann habt ihr doch wieder zwei Plattformen zu pflegen, nur an einer schlechter sichtbaren Stelle.
Der plattformnahe Teil bleibt nativ und ist damit unbeschränkt. Der geteilte Teil ruft ihn über eine schmale, selbst definierte Schnittstelle auf, was diese Grenze sichtbar und pflegbar hält.
Wie sehr fühlt sich die App nach der jeweiligen Plattform an?
Bedienelemente, Übergänge, Textgrößen, Bedienungshilfen und Systemeinstellungen wie Kontrast oder Schriftgröße kommen ohne Zutun mit. Wer eine App für Menschen baut, die täglich damit arbeiten, merkt diesen Unterschied schnell.
Flutter zeichnet die Oberfläche selbst und liefert damit auf beiden Plattformen dasselbe Bild, was für ein starkes Markenbild ein Vorteil und für Systemtreue ein Nachteil ist. React Native bildet auf native Bedienelemente ab und liegt darin näher am System. Bedienungshilfen brauchen in beiden Fällen bewusste Arbeit.
Die Oberfläche ist die des Systems, mit allem, was daran hängt. Wer stattdessen auch die Oberfläche teilt, landet bei denselben Abwägungen wie in der mittleren Spalte.
Wie stabil ist der Unterbau über fünf Jahre?
Ihr hängt an den Plattformbetreibern selbst, und die haben ein Eigeninteresse an Verlässlichkeit. Google hat im Mai 2026 erklärt, dass Android-Oberflächen mit Compose gebaut werden sollen und die alte View-Welt zwar keine neuen Funktionen mehr bekommt, aber weiter gepflegt und nicht abgekündigt wird.
Beide großen Frameworks sind erwachsen geworden: React Native hat mit Version 0.76 vom Oktober 2024 die neue Architektur zur Voreinstellung gemacht und damit die alte Leistungskritik erledigt. Trotzdem hängt ihr an einer Roadmap, die euch nicht gehört, und größere Umstellungen kommen als Projekt und nicht als Aktualisierung.
Die geteilte Schicht ist bewusst schmal, das begrenzt den Schaden bei einem Bruch. Compose Multiplatform ist seit Version 1.8.0 vom Mai 2025 auch für iOS als stabil erklärt, womit dieser Weg von der Wette zur Option geworden ist. Ein junges Ökosystem bleibt es trotzdem.
Wie groß ist die Einstiegshürde für euer vorhandenes Team?
Zwei neue Sprachen und zwei neue Oberflächensysteme, wenn niemand aus dem Mobilbereich kommt. Das ist machbar, aber es ist die längste Anlaufstrecke von allen drei Wegen.
Ein Team mit Weberfahrung findet sich in React Native schnell zurecht, weil Sprache und Denkweise bekannt sind. Flutter verlangt mit Dart eine neue Sprache, dafür ist der Rahmen in sich geschlossen und der Einstieg gut dokumentiert.
Für ein Team, das ohnehin Kotlin schreibt, etwa auf der Serverseite oder in einer bestehenden Android-App, ist das der kürzeste Weg. Für alle anderen ist es der Weg mit dem meisten neuen Vokabular auf einmal.
Was passt wann
- Wenn die App tief ins Gerät greift, für viele Leute die tägliche Arbeitsoberfläche ist oder von der Unternehmens-IT verwaltet wird
- baut nativ und plant beide Plattformen von Anfang an mit eigenem Personal ein, statt eine davon nebenher zu betreiben.
- Wenn die App im Kern Daten darstellt und Formulare abbildet und ihr aus der Webentwicklung kommt
- nehmt eine gemeinsame Codebasis und legt vorher fest, für welche drei Funktionen ihr notfalls nativen Code schreibt.
- Wenn die Fachlogik der teure Teil ist, die Oberfläche aber auf beiden Plattformen zu Hause sein soll
- teilt die Logik mit Kotlin Multiplatform und lasst die Oberflächen nativ, und schneidet die Grenze dazwischen bewusst schmal.
Fünf Fragen vor der Entscheidung
- 01 Wie viele Funktionen greifen tief ins Betriebssystem, etwa Hintergrundverarbeitung, Widgets oder Geräteanbindung?
- 02 Welche Kompetenz habt ihr im Team schon, Web, Backend oder Mobile?
- 03 Wie schnell müsst ihr auf neue Plattformfunktionen reagieren können?
- 04 Wer pflegt die App in fünf Jahren, und mit welcher Teamgröße?
- 05 Was passiert, wenn das gewählte Framework einen Bruch veröffentlicht?
Was danach mit Zahlen statt mit Vorlieben entschieden wird
Sechs Prüfungen reichen aus, und alle sechs lassen sich mit Informationen beantworten, die ihr bereits habt: mit der Funktionsliste, mit der Zusammensetzung des Teams und mit den veröffentlichten Fristen der beiden Plattformbetreiber.
Die Pflichtarbeit der Plattformen beziffern
Du kennst die jährlich wiederkehrenden Vorgaben beider Stores und rechnest sie als festen Posten ein, statt sie als Störung zu behandeln, wenn sie eintreten.
Die Funktionsliste auf Plattformnähe abklopfen
Du gehst die geplanten Funktionen durch und markierst die, die tief in das Betriebssystem greifen. Diese Liste, nicht der Gesamtumfang, entscheidet über die Machbarkeit einer gemeinsamen Codebasis.
Die drei Wege sauber trennen
Vollständig nativ, gemeinsame Codebasis mit eigener Oberfläche und geteilte Fachlogik mit nativer Oberfläche sind drei verschiedene Antworten mit drei verschiedenen Risiken, nicht zwei Lager.
Vom vorhandenen Team aus denken
Ein Team mit Weberfahrung, ein Team mit Backend-Erfahrung und ein Team ohne jede Mobilerfahrung kommen bei derselben Aufgabe zu unterschiedlichen sinnvollen Antworten. Du kannst begründen, welche zu euch passt.
Die Abhängigkeit vom Framework bewerten
Du weißt, welche Fragen du an ein Framework stellst, bevor ihr euch für fünf Jahre daran bindet, von der Veröffentlichungspolitik über die Größe der Community bis zum Umgang mit Brüchen.
Den Ausstieg mitplanen
Du legst fest, welche Teile der Anwendung so geschnitten sind, dass ein späterer Wechsel des Oberflächenwegs nicht die gesamte Fachlogik mitreißt.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der Aufwand liegt nicht im ersten Release
Beide Stores schreiben regelmäßig vor, womit eine App gebaut sein muss und welche Plattformversion sie als Ziel angeben darf, und beide setzen diese Regeln über Ablehnungen beim Hochladen durch. Bei Apple gilt seit dem 28. April 2026, dass in App Store Connect hochgeladene Apps mit Xcode 26 oder neuer und einem SDK der 26er-Generation gebaut sein müssen. Bei Google Play müssen neue Apps und Aktualisierungen ab dem 31. August 2026 mindestens Android 16 mit API-Stufe 36 als Ziel angeben; bestehende Apps müssen mindestens API-Stufe 35 erreichen, sonst sind sie für neue Nutzer auf aktuelleren Geräten nicht mehr sichtbar und nicht mehr installierbar.
Das Anheben der Zielversion ist dabei nicht das Setzen einer Zahl. Mit jeder Stufe kommen Verhaltensänderungen, die nur für Apps gelten, die diese Stufe als Ziel angeben: strengere Regeln für Hintergrundarbeit, geänderte Zugriffe auf Fotos und Dateien, neue Berechtigungsdialoge, andere Anforderungen an Benachrichtigungen. Ihr müsst also nicht nur neu bauen, sondern die betroffenen Stellen prüfen und testen. Rechnet damit als festem jährlichen Posten im Budget, unabhängig davon, ob es neue Funktionen gibt.
Genau an dieser Stelle entscheidet sich der Vergleich. Zwei native Anwendungen bedeuten diese Arbeit zweimal, dafür in eurer eigenen Hand. Eine gemeinsame Codebasis bedeutet sie einmal, dafür mit einer Abhängigkeit davor: Ihr könnt erst dann bauen, wenn das Framework und die verwendeten Zusatzpakete die neue Plattformversion unterstützen. Bei den großen Frameworks ist diese Wartezeit heute überschaubar, sie ist aber nicht null, und bei kleineren Zusatzpaketen kann sie erheblich werden.
Was nativ heute konkret bedeutet
Auf der Android-Seite ist die Lage seit Mai 2026 eindeutig: Google hat erklärt, dass Oberflächen mit Jetpack Compose gebaut werden sollen. Die klassischen View-Komponenten gelten als in Pflege befindlich, sie werden weiter mit kritischen Fehlerbehebungen versorgt, bekommen aber keine neuen Funktionen mehr, und dasselbe gilt für Fragments, RecyclerView und ViewPager. Neue Werkzeuge in Android Studio entstehen nur noch für Compose, und Dokumentation, Beispiele und Lernstrecken sind darauf ausgerichtet. Die Sprache dafür ist Kotlin.
Auf der Apple-Seite ist Swift die Sprache, und SwiftUI das Oberflächensystem, das Apple in seinen eigenen Anleitungen und Beispielen voranstellt. Beide Plattformen haben damit dieselbe Bewegung vollzogen: weg von einem Oberflächenbaum, den man von Hand pflegt, hin zu einer Beschreibung, aus der das System die Anzeige ableitet. Für ein Team bedeutet das, dass die Denkweise auf beiden Seiten ähnlicher geworden ist als früher, auch wenn Sprache und Bibliothek verschieden bleiben.
Der Zeitpunkt ist deshalb günstig für eine Grundsatzentscheidung. Wer heute eine App mit den alten View-Layouts neu beginnt, baut auf einem Fundament auf, das keine neuen Funktionen mehr bekommt. Und wer den Umstieg auf Compose ohnehin vor sich hat, kann bei dieser Gelegenheit prüfen, ob die Fachlogik dabei gleich so geschnitten wird, dass sie später auch auf der iOS-Seite wiederverwendbar wäre.
Die drei Wege, sich Arbeit zu teilen
Flutter zeichnet die Oberfläche selbst, statt sie an die Bedienelemente des Systems zu geben. Das Ergebnis sieht auf beiden Plattformen identisch aus, was für eine Anwendung mit eigenem Markenbild ein Vorteil ist und für eine, die sich nahtlos einfügen soll, ein Nachteil. Sprache ist Dart, die Werkzeuge kommen aus einer Hand, und das Ökosystem ist über Mobil hinaus auf Web und Desktop ausgedehnt. Wer Flutter wählt, entscheidet sich bewusst für eine eigene Oberflächenwelt.
React Native geht den anderen Weg und bildet auf native Bedienelemente ab. Der lange gepflegte Vorwurf, das koste zu viel Leistung, hat sich mit der neuen Architektur erledigt: Seit Version 0.76 vom 23. Oktober 2024 ist sie in neuen Projekten die Voreinstellung, mit direktem Aufruf zwischen JavaScript und nativem Code statt über eine serialisierende Brücke. Für Teams mit React-Erfahrung ist das der kürzeste Weg zu einer App, weil Sprache, Werkzeuge und Denkweise bereits sitzen.
Der dritte Weg teilt nicht die Oberfläche, sondern das, was darunter liegt. Mit Kotlin Multiplatform schreibt ihr Fachlogik, Datenmodelle, Netzwerkzugriff und lokale Speicherung einmal und benutzt sie auf beiden Plattformen, während die Oberfläche jeweils nativ bleibt. Wer auch die Oberfläche teilen will, kann das mit Compose Multiplatform tun, das seit Version 1.8.0 vom Mai 2025 auch für iOS als stabil gilt und dort Navigation, Ressourcenverwaltung und Bedienungshilfen mitbringt. Der Reiz dieses Wegs liegt darin, dass ihr die Grenze selbst zieht und sie später verschieben könnt.
Wo eine gemeinsame Codebasis regelmäßig endet
Die erste Grenze verläuft bei allem, was im Hintergrund passiert. Standortverfolgung über längere Zeit, Datenabgleich ohne offene App, dauerhafte Bluetooth-Verbindungen zu einem Gerät und Weckzeitpunkte unterliegen auf beiden Plattformen eigenen, sich häufig ändernden Regeln. Fertige Pakete gibt es, aber sie hinken den Regeländerungen nach, und wenn eine Kernfunktion eurer App daran hängt, seid ihr in einer schlechten Position.
Die zweite Grenze ist alles, was außerhalb des App-Fensters stattfindet: Widgets auf dem Startbildschirm, Uhrenanwendungen, Erweiterungen für Teilen und Tastatur, Einbindung ins Fahrzeug, Steuerung über die Sprachassistenten. Diese Teile schreibt ihr nativ, auch wenn der Rest geteilt ist. Das ist kein Ausschlussgrund, muss aber im Angebot stehen, denn es bedeutet, dass ihr die native Kompetenz doch braucht, nur in kleinerer Dosis.
Die dritte Grenze betrifft Unternehmensanwendungen. Zertifikatsbasierte Anmeldung, Verwaltung durch eine Mobilgeräte-Verwaltung, Richtlinien für Datentrennung und Vorgaben aus dem Sicherheitsbereich sind auf beiden Plattformen unterschiedlich gelöst, und die Werkzeuge dafür sind auf native Anwendungen ausgerichtet. Wenn eure App in eine verwaltete Flotte ausgerollt wird, klärt diesen Punkt vor der Frameworkwahl und nicht danach.
Die Entscheidung an eurem eigenen Fall durchrechnen
Nehmt die geplante Funktionsliste und markiert jede Zeile, die auf eine Systemschnittstelle zugreift. Wenn diese Markierungen unter einem Fünftel bleiben und keine davon zu den drei Grenzbereichen oben gehört, spricht viel für eine gemeinsame Codebasis. Liegt der Anteil höher oder liegt eine Kernfunktion in einem der Grenzbereiche, rechnet die Brücken als eigene Aufwände mit ein, und dann verschiebt sich das Bild oft deutlich.
Der zweite Rechenschritt betrifft die Zeit. Schätzt den jährlichen Pflegeaufwand für die Plattformvorgaben, einmal für zwei native Anwendungen und einmal für eine gemeinsame Codebasis, und multipliziert ihn mit der geplanten Lebensdauer der App. Erst dieser Betrag ist mit den Mehrkosten des ersten Releases vergleichbar. Bei einer App, die zwei Jahre leben soll, gewinnt fast immer die gemeinsame Codebasis; bei einer, die zehn Jahre laufen soll und tief im Gerät sitzt, kippt die Rechnung.
Der dritte Schritt ist der unangenehmste und der wichtigste: Klärt, wer die App in fünf Jahren pflegt. Eine gemeinsame Codebasis, die von einer Agentur gebaut und von einem internen Team weitergeführt wird, verlangt von diesem Team eine Kompetenz, die es vielleicht nicht hat und für die es schwerer Leute findet als für die verbreiteten nativen Wege. Diese Frage entscheidet in der Praxis häufiger als jedes technische Argument.
Dazu passende Kurse
Wenn die Android-Seite den Anfang macht, sind Android-Kurse, in denen ihr mit Kotlin arbeitet der kürzeste Weg zu einer belastbaren Einschätzung.
Für die zweite Plattform, an der sich die Rechnung entscheidet, gibt es die Kurse zur App-Entwicklung auf der Apple-Seite .
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Sehr umfangreicher Überblick über Zusammenhänge und Anwendungsbereiche. Sehr zu empfehlen.
Effektives, gemeinsames Erarbeiten der Aufgaben mit vielen praktischen Tipps.
Sehr guter Trainer und gute Aufbereitung der Inhalte und auch eingehen auf Fragen der Beteiligten.
Häufige Fragen
Ist Flutter oder React Native langsamer als eine native App?
Können wir zuerst cross-platform starten und später auf nativ wechseln?
Was ist mit einer Web-App statt einer App im Store?
Lohnt sich Kotlin Multiplatform, wenn wir bisher nur Android machen?
Wie oft müssen wir mit erzwungenen Anpassungen rechnen?
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Programmierung-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Die App-Entscheidung an einem eigenen Vorhaben durchspielen
Ob Kotlin, Swift oder eine gemeinsame Codebasis mit Flutter: Bei cmt baust du eine lauffähige App vom leeren Projekt bis auf das Gerät und siehst dabei, wo die Wege tatsächlich auseinandergehen.