Teil 5 – Fazit: Was würde ich heute wählen?

Vier Teile lang habe ich Sprachen und Frameworks seziert, verglichen und eingeordnet. Jetzt kommt der Teil, den viele am liebsten zuerst lesen wollen – und den ich bewusst ans Ende gestellt habe. Denn wer die Antwort kennen will, muss zuerst die richtigen Fragen stellen. Welches Framework gewinnt, hängt schlicht davon ab, was man eigentlich baut – und mit wem.

Kein Ranking, aber eine klare Haltung

Ich werde hier keine Rangliste aufstellen. Nicht weil ich keine Meinung hätte – sondern weil eine Rangliste in diesem Kontext schlicht das falsche Werkzeug ist. Ein Multimeter misst Spannung. Ein Oszilloskop zeigt Signalverläufe. Beides ist unverzichtbar, keines ist besser. Wer in der Elektronik mit solchen Vergleichen arbeitet, weiß: Das Werkzeug folgt der Aufgabe, nicht umgekehrt.

Trotzdem: Es gibt Muster, die sich durch die Praxis ziehen – und die ich hier ehrlich benennen möchte.

Wenn ich alleine oder im kleinen Team starte

Für ein Solo-Projekt oder ein kleines Team ohne starke Vorerfahrung in einer bestimmten Sprache würde ich heute zu Flutter greifen. Die Entwicklungsgeschwindigkeit ist hoch, das Tooling ist ausgereift, Dart lässt sich schnell erlernen, und das Ergebnis sieht auf beiden Plattformen sauber aus. Die Community liefert für fast jeden Anwendungsfall ein Package – und wenn mal etwas fehlt, findet man die Antwort in der Regel schneller als bei anderen Frameworks.

Flutter hat sich in meinen Augen vom spannenden Experiment zum soliden Produktionswerkzeug entwickelt. Das war vor drei Jahren noch anders.

Wenn ein Web-Team mit ins Boot soll

React Native. Keine lange Diskussion. Wer ein Team hat, das React kennt und täglich damit arbeitet, sollte dieses Wissen nicht wegwerfen. Die neue Architektur hat die alten Performance-Probleme weitgehend entschärft, TypeScript bringt die nötige Struktur, und das Ökosystem ist schlicht riesig. Der Einstieg fällt leicht, die Lernkurve ist flach – und das zählt in der Praxis mehr als jeder Benchmark.

Wenn die App tief ins System greifen muss

Dann führt kein Weg an nativer Entwicklung vorbei. Swift für iOS, Kotlin für Android – fertig. Wer AR-Features, komplexe Audioverarbeitung, tiefe Systemintegration oder maximale Performance braucht, sollte Cross-Platform gar nicht erst in Betracht ziehen. Das ist keine Schwäche der Frameworks, das ist schlicht die Realität der Plattformen.

Hier spreche ich aus eigener Erfahrung: AuraHarmony, meine App für Solfeggio-Frequenzen und Binaural Beats, setzt auf Kotlin und Jetpack Compose – weil Audiosynth auf diesem Niveau native APIs verlangt, die kein Cross-Platform-Framework sauber abstrahiert. Diese Entscheidung bereue ich nicht einen Moment.

Wenn Kotlin bereits gesetzt ist

Dann lohnt sich ein ernsthafter Blick auf Kotlin Multiplatform. Die Geschäftslogik einmal schreiben, auf beiden Plattformen nutzen – das ist kein Traum mehr, sondern gelebte Praxis in wachsenden Teams. Compose Multiplatform reift zusehends, und wer die Konzepte von Jetpack Compose bereits verinnerlicht hat, findet sich sofort zurecht. KMP ist meine persönliche Wette für die nächsten Jahre – nicht als Ersatz für die anderen Optionen, sondern als logische Weiterentwicklung für Teams, die bereits in der Kotlin-Welt verwurzelt sind.

Für AuraHarmony ist KMP der nächste Schritt, den ich konkret plane: Die Audiologik und Datenbankschicht auf iOS portieren, ohne die gesamte App neu zu schreiben. Genau dafür ist KMP gemacht.

Was sich durch alle Entscheidungen zieht

Egal für welchen Ansatz man sich entscheidet – ein paar Dinge bleiben immer wahr. Erstens: Die Sprache ist selten das eigentliche Problem. Architektur, Teamstruktur und klare Anforderungen wiegen schwerer als die Frage, ob man nun Dart oder JavaScript schreibt. Zweitens: Kein Framework löst schlechtes Software-Design. Ein schlecht strukturiertes Flutter-Projekt ist genauso unwartbar wie eine schlecht strukturierte native App. Drittens: Die Community um ein Framework ist mindestens so wichtig wie das Framework selbst. Wer bei einem Problem allein dasteht, hat die falsche Wahl getroffen – egal wie elegant die Syntax ist.

Mein persönliches Fazit

Wenn ich heute von null anfangen würde – kein bestehendes Projekt, kein Team, keine Vorerfahrung: Ich würde Flutter wählen. Schnell, konsistent, produktionsreif. Wenn ich mein bestehendes Android-Projekt erweitern will: KMP. Wenn ich ein Web-Team integrieren muss: React Native. Und wenn die App systemnahe Features braucht, die keine Abstraktion verträgt: nativ, ohne Kompromisse.

Das ist kein widersprüchliches Fazit. Es ist das ehrlichste, das ich geben kann – weil mobile Entwicklung eben keine Einheitsgröße kennt. Die beste Entscheidung ist die, die zum eigenen Kontext passt. Nicht die, die gerade auf Twitter am lautesten gefeiert wird.

Diese Serie endet hier – aber das Thema entwickelt sich weiter. KMP reift, Flutter wächst, und irgendwo in einem Berliner Startup arbeitet gerade jemand an dem Framework, über das wir in drei Jahren alle reden werden. Ich bleibe dran – und berichte.