Wer heute ein kleines Studio mit einer App beauftragt, stellt irgendwann diese Frage: nativ oder Cross-Platform? Die Antwort ist 2026 nicht mehr so eindeutig wie 2019 — und das ist gut so. Dieser Eintrag erklärt, warum Qorvano° seine Apps mit Flutter entwickelt, wo die Wahl tatsächlich unkritisch ist, und wo wir bis heute zu nativer Entwicklung raten würden.
Der ursprüngliche Zweifel
Es gab eine Zeit, da galt Cross-Platform-Entwicklung in ambitionierten Projekten als Kompromiss. Die Oberfläche lief, aber sie fühlte sich fremd an. Animationen ruckelten. Gesten verhielten sich auf iOS und Android unterschiedlich falsch. Dateizugriff, Haptik, Accessibility — alles war eine halbe Etage unter der nativen Implementierung. Und die App-Store-Reviewer merkten es.
Dart als Sprache war fremd. Flutter als Framework war jung. Wer seine App auf die 1.0-Note bringen wollte, schrieb Swift für iOS und Kotlin für Android — in zwei Teams, mit zwei Codebasen, bei etwa doppeltem Aufwand.
Was Flutter 2026 ist
Sieben Jahre später ist Flutter ein anderes Framework. Die Plattformintegration ist vollständig: haptisches Feedback, das sich auf iPhone wie auf Pixel korrekt anfühlt. Dynamische Schrift, die iOS' Dynamic Type und Androids Font Scaling parallel respektiert. Dark Mode, der automatisch der Systemeinstellung folgt. Accessibility-APIs, die VoiceOver und TalkBack gleichberechtigt bedienen. Material 3 und das Cupertino-Widgetset rendern pixelgleich zu den nativen Pendants.
Dart selbst ist eine gepflegte, stabile Sprache mit solidem Typsystem, guten Tools und einem Build-System, das sich angenehm klein anfühlt. Wer aus modernem TypeScript oder Kotlin kommt, sitzt nach einem Nachmittag.
Die Performance ist seit der Impeller-Rendering-Engine auf iOS und der Skia-Ablösung auf Android dort, wo man sie erwartet: 60 bis 120 fps auf modernen Geräten, flüssige Scroll-Performance, niedrige Startup-Zeiten. Für die Art App, die wir bauen — präzise Werkzeuge, keine AR-Filter, keine Echtzeit-Spiele — ist das mehr als ausreichend.
Wo native Entwicklung noch gewinnt
Wir wären unehrliche Fürsprecher, wenn wir behaupteten, Flutter sei immer die bessere Wahl. Es gibt Fälle, in denen wir Auftraggebern bis heute zu nativem Swift oder Kotlin raten:
- Tiefe Hardware-Integration. Wer an Kameras, Sensoren, Bluetooth-LE-Stacks oder CoreML / MLKit auf einem Tiefpunkt arbeitet, profitiert von nativem Zugriff auf die aktuellsten APIs — oft bevor es Flutter-Plugins dafür gibt.
- Plattform-exklusive Features mit Launch-Datum. Neue iOS-Features (zum Beispiel Live Activities, Widgets mit Interactivity, Vision-Pro-Integration) landen zuerst in Swift. Wer mit Apples Release-Rhythmus mitgehen will, ist dort richtiger aufgehoben.
- Apps mit hoher nativer UI-Dichte, bei denen System-Komponenten im Vordergrund stehen (denken Sie an Files, Mail, Kalender-Clients). Der Aufwand, solche Oberflächen pixelgenau in Flutter zu rekonstruieren, ist oft höher als in Swift/UIKit/SwiftUI direkt.
- Sehr große Teams mit getrennten iOS- und Android-Engineering-Abteilungen. Dort ist die organisatorische Dividende einer geteilten Codebasis geringer, und Flutter bringt unnötige Brückenlogik.
Für ein Ein-Personen-Studio wie Qorvano° trifft keiner dieser Punkte zu. Für einen Großkonzern mit dreißig iOS-Developern trifft mindestens einer zu.
Wo Flutter klar gewinnt
Gleichzeitig gibt es Szenarien, in denen Flutter die rationalere Wahl ist:
- Kleine Teams, zwei Plattformen. Jede native Implementierung verdoppelt Entwicklungsaufwand, Bugs, QA-Zyklen. Flutter halbiert das nahezu.
- Gleichwertige iOS + Android-Releases. Wer beide Plattformen gleichzeitig und gleichwertig bedienen will, ohne dass eine von beiden das Stiefkind wird, ist mit einer gemeinsamen Codebasis strukturell besser aufgestellt.
- Datenlastige, custom-gestaltete UIs. Finanz-Dashboards, Taschenrechner, Editor-Apps, B2B-Frontends — alles, wo die UI eher eigen als systemisch ist, rendert in Flutter effizient und konsistent.
- Planbare Wartung. Eine Codebasis, ein Build-Prozess, ein Dependency-Graph. Langfristig weniger Wartungsaufwand — und der Grund, warum Langlebigkeit bei uns ein Prinzip ist.
Unsere Entscheidung — und woran wir sie messen
Numeris, unsere erste öffentliche App, ist vollständig in Flutter umgesetzt. Live-LaTeX-Rendering, symbolische Ableitungen, 2D- und 3D-Flächenplots, Haptik, 20 Lokalisierungen, volle Accessibility — alles in einer Codebasis, auf iPhone, iPad und Android-Tablets. Die App fühlt sich auf jedem dieser Geräte nicht wie "eine Flutter-App" an, sondern wie eine App, die zum jeweiligen System gehört. Für uns der Erfolgsmaßstab.
Bei Auftragsarbeiten stellen wir die Native-vs.-Flutter-Frage im ersten Gespräch — ehrlich, mit den oben genannten Kriterien. Wenn nativ die bessere Wahl ist, sagen wir das. Die meisten Projekte, die bei uns ankommen, passen aber zu Flutter: klein bis mittelgroß, zweiplattform, mit Fokus auf Wartbarkeit über fünf Jahre statt auf das letzte Plattform-Feature.
Fazit
Flutter ist kein Kompromiss mehr. Für die meisten kleinen und mittelgroßen Apps ist es 2026 die rationalere Wahl als getrennte native Teams. Nicht, weil es überall gewinnt, sondern weil der Aufwand, den es spart, größer ist als die wenigen Stellen, an denen es nicht mithalten kann.
Wer ernsthaft überlegt, eine App zu bauen — egal ob als Startup, im Mittelstand oder als Einzelperson mit einer klaren Idee —, sollte die Entscheidung anhand der konkreten Anforderungen treffen. Nicht anhand alter Vorurteile. Dazu gehört im Zweifel ein Gespräch, das zehn Minuten dauert und die richtige Richtung klarer macht als jeder Blog-Post.
Wenn Sie so ein Gespräch suchen: Schreiben Sie uns.