Ratgeber
Flutter oder native Entwicklung?
Kurz erklärt
Mit Flutter entsteht aus einer Codebasis in der Sprache Dart eine App für Android und iOS. Native Entwicklung bedeutet zwei getrennte Apps, in Kotlin für Android und in Swift für iOS. Für die meisten Firmen-Apps reicht Flutter, native Entwicklung lohnt sich vor allem bei sehr plattformnahen Funktionen.
Bevor eine App gebaut wird, steht die Frage nach der Technik. Die zwei verbreiteten Wege sind eine gemeinsame Codebasis für Android und iOS, etwa mit Flutter, oder zwei getrennte native Apps. Dieser Artikel erklärt die Unterschiede ohne Fachjargon und zeigt, welche Kriterien für eine Firmen-App den Ausschlag geben.
Welche Technik passt für eine Firmen-App?
Für die meisten Firmen-Apps passt eine gemeinsame Codebasis wie Flutter, weil eine App für Android und iOS entsteht und Änderungen nur einmal gebaut werden. Native Entwicklung mit Kotlin und Swift lohnt sich, wenn die App sehr eng mit dem Betriebssystem arbeitet oder nur eine Plattform braucht. Entscheidend sind Funktionsumfang, Budget und wer die App später pflegt.
Bei SaracAI verwenden wir beide Wege: Flutter für Apps, die auf Android und iOS erscheinen, wie die Karten-Scanner-App ScanLoot, und Kotlin für reine Android-Apps im Play Store.
Was ist Flutter?
Flutter ist ein quelloffenes Framework von Google, mit dem aus einer einzigen Codebasis Apps für mehrere Plattformen entstehen. Programmiert wird in der Sprache Dart. Neben Android und iOS unterstützt Flutter auch Web, Windows, macOS und Linux.
Die offizielle Dokumentation beschreibt das Ziel als „multiplatform apps from a single codebase“. Flutter zeichnet die Oberfläche mit einer eigenen Grafik-Engine. Dadurch sieht die App auf beiden Systemen gleich aus und verhält sich gleich, was Tests und Gestaltung vereinfacht. Wo eine Gerätefunktion nicht abgedeckt ist, kann nativer Code eingebunden werden.
### Stärken von Flutter - eine Codebasis, ein Team, ein Zeitplan für Android und iOS - Änderungen und Fehlerbehebungen nur einmal umsetzen - einheitliches Erscheinungsbild auf allen Geräten - schnelle Entwicklung durch sofort sichtbare Änderungen während der Arbeit
### Grenzen von Flutter - neue Funktionen von Android oder iOS kommen teils erst mit Verzögerung in Erweiterungen an - sehr systemnahe Funktionen wie Widgets auf dem Startbildschirm oder Apps für die Uhr brauchen nativen Code - die App-Dateien sind meist etwas größer als bei einer nativen App
Was bedeutet native App-Entwicklung?
Native Entwicklung heißt, für jede Plattform eine eigene App in der Sprache zu schreiben, die der Hersteller vorsieht: Kotlin für Android und Swift für iOS. Die App nutzt die Bedienelemente und Schnittstellen des Systems direkt. Dafür entstehen zwei Codebasen, die getrennt gebaut und gepflegt werden.
Google empfiehlt für neue Android-Apps Kotlin und entwickelt Werkzeuge, Bibliotheken und Dokumentation nach eigener Aussage „Kotlin-first“. Apple stellt mit Swift und SwiftUI die Sprache und das Oberflächen-Framework für iOS bereit. Neue Systemfunktionen sind in diesen Sprachen am ersten Tag verfügbar.
### Stärken nativer Entwicklung - voller Zugriff auf alle Funktionen des Systems ab dem ersten Tag - Bedienung genau so, wie Nutzer es von ihrem System gewohnt sind - gut geeignet für Apps, die es nur auf einer Plattform gibt
### Grenzen nativer Entwicklung - zwei Apps bedeuten in der Regel doppelten Aufwand für Entwicklung, Tests und Pflege - Funktionen erscheinen auf beiden Plattformen nicht automatisch gleichzeitig - das Team braucht Kenntnisse in beiden Sprachen
Flutter oder native: Was ist der Unterschied in der Praxis?
Der wichtigste Unterschied liegt im Aufwand für zwei Plattformen: Flutter baut eine App für beide, native Entwicklung zwei. Bei Leistung und Gerätefunktionen sind die Unterschiede für typische Firmen-Apps klein. Groß werden sie erst bei sehr systemnahen oder grafiklastigen Anwendungen.
| Kriterium | Flutter | Native (Kotlin und Swift) |
|---|---|---|
| Codebasen für Android und iOS | eine | zwei |
| Sprache | Dart | Kotlin (Android), Swift (iOS) |
| Aufwand für zweite Plattform | gering | etwa wie für die erste |
| Zugriff auf neue Systemfunktionen | über Erweiterungen oder eigenen nativen Code | sofort |
| Erscheinungsbild | auf beiden Systemen gleich | jeweils systemtypisch |
| Pflege und Updates | einmal umsetzen | zweimal umsetzen |
| Geeignet für | Firmen-Apps, Kunden-Apps, Werkzeuge mit Kamera und Server | systemnahe Apps, nur eine Plattform, Uhren und Widgets |
Welche anderen plattformübergreifenden Ansätze gibt es?
Neben Flutter sind React Native und Kotlin Multiplatform verbreitet, außerdem die Web-App, die ganz ohne Store auskommt. Sie unterscheiden sich vor allem in der Programmiersprache und darin, wie viel Code wirklich geteilt wird. Welcher Ansatz passt, hängt oft davon ab, was im Unternehmen schon vorhanden ist.
- React Native: Ein Framework von Meta, das mit JavaScript beziehungsweise TypeScript und dem Programmiermodell von React arbeitet. Die Bausteine werden laut Projektseite auf die Bedienelemente des jeweiligen Systems abgebildet. Naheliegend, wenn ein Team bereits Web-Anwendungen mit React baut.
- Kotlin Multiplatform: Ein Ansatz von JetBrains, mit dem sich vor allem Programmlogik zwischen Android, iOS und weiteren Plattformen teilen lässt (Kotlin-Dokumentation). Interessant für Teams, die schon eine native Android-App in Kotlin haben und iOS ergänzen wollen.
- Web-App: Läuft im Browser und lässt sich auf dem Startbildschirm ablegen. Es fallen keine Store-Gebühren und keine Store-Prüfung an, dafür sind manche Gerätefunktionen eingeschränkt, und die App ist im Store nicht auffindbar.
Wir arbeiten neben Flutter und Kotlin auch mit React Native. Die Entscheidung treffen wir je Projekt nach den Fragen weiter unten, nicht nach Vorliebe.
Welche Rolle spielen Wartung und Store-Vorgaben bei der Wahl?
Eine App ist nach dem Start nicht fertig, denn Apple und Google verlangen regelmäßig Anpassungen an neue Systemversionen. Mit einer gemeinsamen Codebasis fallen diese Arbeiten großteils einmal an, bei zwei nativen Apps zweimal. Dafür hängt eine Flutter-App zusätzlich von den Updates des Frameworks selbst ab.
Ein Beispiel: Google verlangt, dass neue Apps und Updates seit dem 31. August 2026 mindestens Android 16 (API-Level 36) als Zielplattform angeben (Zielplattform-Anforderungen von Google Play). Solche Vorgaben betreffen jede Android-App, egal mit welcher Technik sie gebaut ist. Der Unterschied liegt darin, wie viele Codebasen angepasst und erneut getestet werden müssen.
Für die Wahl bedeutet das: Rechnen Sie nicht nur die Entwicklung bis zum Start, sondern mindestens zwei Jahre Pflege. Bei zwei getrennten nativen Apps sind auch Fehlerbehebungen, neue Funktionen und Tests doppelt einzuplanen.
Wann ist native Entwicklung die bessere Wahl?
Native Entwicklung ist sinnvoll, wenn die App nur auf einer Plattform erscheinen soll oder tief mit dem System arbeitet. Typische Beispiele sind Apps für Uhren, Widgets, umfangreiche Hintergrunddienste oder Funktionen, die direkt nach ihrer Vorstellung durch Apple oder Google genutzt werden sollen.
Eine reine Android-App für einen klar umrissenen Zweck, etwa ein Werkzeug für Mitarbeiter, die alle Android-Geräte nutzen, lässt sich in Kotlin schlank umsetzen. Soll später doch iOS dazukommen, muss die Oberfläche neu geschrieben werden. Diese Möglichkeit sollte man bei der Entscheidung bedenken.
Wann ist Flutter die bessere Wahl?
Flutter passt, wenn dieselbe App auf Android und iOS erscheinen soll und Budget und Zeit begrenzt sind. Das gilt für die meisten Kunden-Apps, Service-Apps und Apps mit Formularen, Listen, Kamera und Server-Anbindung. Auch eine spätere Web-Version lässt sich aus derselben Codebasis ableiten.
Prüfen Sie vor der Entscheidung diese Fragen:
- Muss die App auf beiden Plattformen erscheinen?
- Gibt es Funktionen, die es nur auf einem System gibt?
- Wie oft soll die App nach dem Start erweitert werden?
- Wer pflegt die App in zwei Jahren, und welche Sprache beherrscht dieses Team?
Wie sich die Wahl auf Budget und Zeitplan auswirkt, zeigen die Artikel Was kostet eine App-Entwicklung? und Wie lange dauert eine App-Entwicklung?. Unabhängig von der Technik gelten für die Veröffentlichung dieselben Store-Regeln, die im Artikel App nicht im Store auffindbar beschrieben sind.
Häufige Fragen
Ist eine Flutter-App langsamer als eine native App?
Für typische Firmen-Apps mit Formularen, Listen, Kamera und Server-Anbindung ist der Unterschied im Alltag in der Regel nicht spürbar, weil Flutter-Apps zu Maschinencode kompiliert werden. Bei sehr rechenintensiven oder grafiklastigen Anwendungen sollte man die Leistung mit einem Prototyp auf echten Geräten prüfen.
Kann eine Flutter-App auf Kamera, GPS und Benachrichtigungen zugreifen?
Ja. Für Gerätefunktionen gibt es Erweiterungen, die die nativen Schnittstellen von Android und iOS ansprechen. Fehlt eine Funktion, lässt sich nativer Code in Kotlin oder Swift gezielt einbinden, ohne die ganze App nativ zu schreiben.
Was ist React Native, und wie unterscheidet es sich von Flutter?
React Native ist ein weiteres Framework für eine gemeinsame Codebasis, entwickelt von Meta. Es nutzt JavaScript beziehungsweise TypeScript und die Bedienelemente des jeweiligen Systems, während Flutter mit Dart arbeitet und seine Oberfläche selbst zeichnet. Welches besser passt, hängt oft davon ab, welche Sprache das Team und eine vorhandene Web-Anwendung schon nutzen.
Kann ich später von Flutter auf native Entwicklung wechseln?
Ja, aber das bedeutet in der Regel, die Oberfläche neu zu schreiben. Server, Datenbank und Schnittstellen bleiben dagegen erhalten. Deshalb lohnt es sich, Geschäftslogik möglichst im Backend zu halten.