Flutter oder nativ? Was wir nach Jahren mit beidem wirklich empfehlen

Flutter oder nativ ist die Glaubensfrage der App-Entwicklung — und wir stehen mit einem Bein in beiden Lagern. Unsere Flutter-Apps laufen in beiden Stores, unsere nativen Apps auf vier Apple-Plattformen. Hier ist die unaufgeregte Antwort, die wir auch Kunden im Erstgespräch geben.

Vorweg die Karten auf den Tisch: ClickTestBuy haben wir 2021 zweimal nativ gebaut — Swift für iOS, Kotlin für Android. RoadReview und LS-Athletics sind Flutter, eine Codebasis für beide Stores. MyMonty ist nativ für iPhone, iPad, Mac und Apple Vision. Drei Projekte, drei verschiedene Antworten — und alle drei waren für ihr Projekt richtig. Genau das ist die These dieses Artikels: Die Frage ist nicht, welches Framework besser ist, sondern was zu Produkt, Team und Budget passt.

Die Frage kommt in fast jedem App-Erstgespräch, meist in der Form „Wir haben gehört, Flutter sei günstiger — stimmt das?“. Die ehrliche Antwort ist ein Entscheidungsbaum, kein Ja. Und sie beginnt mit einer Beobachtung, die in Framework-Debatten gern untergeht: Für die Nutzer ist das Framework unsichtbar. Niemand löscht eine App, weil sie in Flutter geschrieben ist — aber sehr wohl, weil sie langsam startet, ruckelt oder das Feature fehlt, das die andere Plattform längst hat. Die Framework-Wahl ist ein Mittel für genau diese Ziele, nicht umgekehrt.

Wo Flutter glänzt

Die kurze Version: bei Business-Apps, die auf iOS und Android gleichzeitig erscheinen müssen und deren Oberfläche der App gehört — nicht dem Betriebssystem. RoadReview ist unser bester Beleg: Die App dokumentiert Fahrstunden — Karte, Fehler-Tags, Sprachnotizen, Fahrfortschritt — und läuft für Fahrlehrer wie Fahrschüler auf iOS und Android. Das Frontend ist Flutter, dahinter arbeiten NestJS und PostgreSQL, Karten kommen von Google Maps, Push über Firebase. Jedes Feature wird einmal gebaut und erscheint in beiden Stores am selben Tag.

• Ein Team statt zwei. Derselbe Entwickler, derselbe Pull-Request, derselbe Bugfix für beide Plattformen. Für ein kleines Studio wie unseres — und für das Budget unserer Kunden — ist das der entscheidende Unterschied.
• Feature-Parität ist der Normalzustand, kein Projekt. Bei zwei nativen Apps läuft eine Plattform immer hinterher; bei ClickTestBuy haben wir das täglich gespürt.
• Das Ökosystem ist erwachsen. Kamera, Karten, Push, Bezahlung — für LS-Athletics hängt sogar die HealthKit-Anbindung hinter einem gepflegten Plugin. Die Zeiten, in denen man für jede native API selbst Brücken bauen musste, sind vorbei.
• Die Rechnung. Der Frontend-Anteil wird einmal bezahlt statt zweimal — bei Business-Apps oft der größte Einzelposten.

Und ehrlich: Flutter-Apps sehen per Default nach Flutter aus, nicht nach iOS oder Android. Für Business-Apps mit eigener Designsprache ist das egal bis erwünscht — die App soll nach Marke aussehen, auf beiden Plattformen gleich. Wer dagegen pixelgenaues Plattform-Gefühl will, bezahlt es mit Zusatzaufwand, der den Vorteil der einen Codebasis anknabbert.

Wo nativ gewinnt

• Tiefe Plattform-Features. Widgets, Live Activities, App Intents, Watch-Apps: mit Flutter machbar — aber jedes davon ist ohnehin nativer Code, der dann über Brücken angebunden wird. Wer davon lebt, fährt direkt nativ besser.
• Mehrere Apple-Plattformen. MyMonty, unser digitales Handbuch für die Wasserschadensanierung, läuft auf iPhone, iPad, Mac und Apple Vision — aus einer Swift-Codebasis. Innerhalb der Apple-Welt dreht sich das „eine Codebasis“-Argument um.
• Höchste Grafik- und Sensorleistung. Echtzeit-Rendering, aufwändige Animationen bei 120 Hz, AR: Hier will man keine Abstraktionsschicht zwischen sich und dem System.
• Der erste Tag eines neuen OS. Native Apps können neue System-Features am Tag der Keynote adoptieren. Das Flutter-Ökosystem braucht Wochen bis Monate, bis die Plugins nachziehen — meistens egal, manchmal entscheidend.

Der MyMonty-Fall ist der lehrreichste: Android war dort schlicht keine Anforderung. Die Zielgeräte waren die iPhones und iPads der Monteure, dazu Mac und Apple Vision für Schulungen. Flutter hätte dort nichts halbiert — nur eine Schicht hinzugefügt.

Ein zweiter Punkt, der selten offen ausgesprochen wird: Nativ ist auch eine Personalfrage. Swift- und Kotlin-Entwickler denken in ihren Plattformen, kennen die Konventionen, die Review-Fallstricke, die Eigenheiten der Geräte. Wer ein eingespieltes iOS-Team im Haus hat, verschenkt mit Flutter dessen stärksten Muskel. Wer — wie die meisten Mittelständler — gar kein App-Team hat und einen Partner beauftragt, für den zählt dieses Argument nicht: Dann entscheiden Produkt und Budget.

Was ist mit der Performance?

Die häufigste Sorge im Gespräch, deshalb ein eigener Absatz. Für Business-Apps ist Flutter-Performance seit Jahren ein Nicht-Thema: Listen, Formulare, Karten und Animationen laufen flüssig — RoadReview rendert Routen mit Markern in Echtzeit, und kein Fahrlehrer hat je nach dem Framework gefragt. Die ehrlichen Grenzen liegen woanders: Sehr lange Listen mit komplexen Zellen wollen sauber gebaut sein (das gilt nativ genauso), der Kaltstart ist einen Tick schwerer als bei einer schlanken nativen App, und wer wirklich an die Grenzen der Grafikleistung geht, spürt die Abstraktionsschicht. Kurz: Performance ist selten der Grund für die Entscheidung — Plattform-Tiefe und Team-Zuschnitt sind es.

Der Entscheidungsleitfaden

Fünf Fragen, in dieser Reihenfolge. Meistens ist die Sache nach dreien entschieden:

1. Braucht ihr iOS und Android? Wenn nein — nur Apple, vielleicht sogar iPad und Mac dazu — ist nativ der kürzeste Weg.
2. Lebt die App von Plattform-Features? Widgets, Watch, tiefe System-Integration als Kern des Produkts (nicht als Nice-to-have): nativ.
3. Ist die Oberfläche eure eigene Designsprache? Business-App, eigenes Branding, identisch auf beiden Plattformen: Flutter.
4. Wie sieht das Team aus? Ein kleines Team, das beide Stores bedienen muss, ist mit einer Codebasis ehrlicher aufgestellt als mit zwei halben.
5. Was ist mit Grafik? Spiele, AR, Echtzeit-Visualisierung: nativ — oder gleich eine richtige Engine.

Was das für Budget und Wartung heißt

Fürs Budget ist die Sache klar: Für ein Produkt auf beiden Plattformen spart Flutter den zweiten Frontend-Bau — je nach Projekt grob ein Drittel der Gesamtrechnung, denn Backend, Design und Projektführung bleiben gleich. Wer nur eine Plattform braucht, spart mit Flutter dagegen nichts. Und für die Verhandlung mit jedem Anbieter gilt: Lasst euch die Ersparnis zeigen, nicht nur versprechen. Ein Angebot „Flutter, daher günstiger“ ohne aufgeschlüsselten Backend- und Design-Anteil hat die Rechnung nicht gemacht, sondern nur das Schlagwort übernommen.

Bei der Wartung wird gern geschummelt, in beide Richtungen. Flutter heißt: eine Codebasis pflegen, aber die Framework-Upgrades jedes Jahr mitmachen — und gelegentlich auf ein Plugin warten. Nativ heißt: zwei Codebasen, die den jeweiligen OS-Zyklen folgen — dafür nie eine Zwischenschicht zwischen sich und Apple oder Google. Nach unseren Jahren mit beidem: Für Business-Apps ist die Flutter-Wartung in Summe deutlich günstiger; bei plattform-tiefen Apps kehrt sich das um.

Konkret sieht Wartung bei uns so aus: Einmal im Jahr steht das große Flutter-Upgrade an — ein bis zwei Tage, wenn die Abhängigkeiten gepflegt sind, deutlich mehr, wenn nicht. Dazwischen kleine Plugin-Updates, die mit den regulären Store-Releases mitfahren. Bei den nativen Apps ist es der jährliche OS-Zyklus: neue Xcode-Version, geänderte Berechtigungen, angepasste APIs. Keiner der beiden Wege ist wartungsfrei — wer euch das erzählt, hat noch keine App selbst über Jahre betrieben.

Unsere Default-Empfehlung ist deshalb unspektakulär: Business-App für beide Stores → Flutter. Apple-only oder plattform-tief → nativ. Im Erstgespräch beantworten wir die Frage ehrlich — auch wenn die Antwort „nativ“ lautet. Wie wir Apps bauen und betreiben, steht auf der Seite zur App-Entwicklung; RoadReview lässt sich im Showcase im Detail ansehen. Und wer schon eine native App hat, die funktioniert: nicht umschreiben. Ein Rewrite aus Framework-Gründen ist fast nie die beste Investition.