Flutter-Apps: eine Codebasis, zwei Stores live
Flutter baut iOS- und Android-Apps aus einer Codebasis. Wo das wirklich Zeit und Kosten spart und wo ein natives Team die bessere Wahl bleibt.
rabbitclip-TeamVeröffentlicht: 4 Min. Lesezeit
Kurz gesagt
Flutter baut Ihre iOS- und Android-App aus einer einzigen Codebasis. Ein Team schreibt sie einmal, und sie erscheint gleichzeitig in beiden Stores. Für kleine und mittlere Unternehmen, die beide Plattformen abdecken wollen, ohne zwei getrennte native Teams aufzubauen, ist das der praktische Weg.
Wenn ein Unternehmen sich für eine App entscheidet, lautet die eigentliche Frage selten 'welche Technologie', sondern 'wie viele Teams'. Swift für iOS und Kotlin für Android zu schreiben bedeutet zwei Entwicklungslinien, zwei Testzyklen, zwei Fehlerdatenbanken. Flutter hebt diese Trennung größtenteils auf und lässt ein Team beide Plattformen gemeinsam tragen.
Was Flutter tatsächlich leistet
Flutter ist ein von Google entwickeltes Interface-Framework, geschrieben in Dart, das aus einer einzigen Codebasis lauffähige Apps für iOS, Android, Web und Desktop erzeugt. Es zeichnet die Oberfläche mit einer eigenen Rendering-Engine, sodass derselbe Button und dieselbe Übergangsanimation auf beiden Plattformen identisch aussehen.
Der Code wird vor dem Weg in den Store zu nativem Code kompiliert; es ist keine Webseite, die in einer Hülle läuft. Dieser Unterschied zählt, denn bei Performance und Store-Prüfung werden Flutter-Apps in derselben Kategorie wie native Apps bewertet.
Was eine Codebasis wirklich einspart
Der klarste Gewinn ist Zeit. Ein neues Feature wird einmal geschrieben und erscheint gemeinsam auf beiden Plattformen, statt zweimal nach getrennten Zeitplänen. Ein Fehler wird an einer Stelle behoben.
Der zweite Gewinn ist die Pflege. Sobald die App live ist, laufen Versionsverfolgung, Bibliotheks-Updates und Betriebssystem-Kompatibilität über eine einzige Codebasis, sodass ein kleines Team die App langfristig gesund halten kann, ohne zu wachsen.
Der Entscheidungstest ist einfach: Verhält sich die Geschäftslogik der App (Formulare, Listen, ein Bestellablauf, Benachrichtigungen) unabhängig von der Plattform gleich, oder muss sie sich auf jeder Plattform anders verhalten. Trifft ersteres zu, spart Flutter echte Zeit; trifft letzteres zu, schrumpft der Gewinn schnell.
Für welches Unternehmen es sich nicht eignet
Flutter ist nicht die Antwort auf jeden mobilen Bedarf. Wenn die App nur eine geringe Menge an Inhalten zeigen soll und der Nutzer sie ohnehin nur wenige Male am Tag öffnet, kann eine PWA denselben Job zu deutlich geringeren Kosten erledigen; eine separate Store-App zu bauen wäre dann eine unnötige Investition.
Hat ein Team bereits erfahrene native Entwickler und liegt der Schwerpunkt der App stark auf plattformspezifischer Hardware-Arbeit, bringt der Wechsel zu Flutter eine Lernkurve mit sich, während der Zeitgewinn begrenzt bleibt. In diesem Fall ist es meist sinnvoller, mit dem bestehenden nativen Team weiterzuarbeiten.
Häufige Fehler
Der häufigste Fehler ist, nach der Entscheidung für Flutter echte Gerätetests auf beiden Plattformen auszulassen. Derselbe Code läuft auf beiden, aber Tastaturverhalten, der Ablauf der Berechtigungsanfrage und Hardware-Feedback wie Vibration können sich je nach Plattform leicht unterscheiden, und diese Unterschiede zeigen sich nur auf einem echten Gerät.
Der zweite Fehler ist, Store-Anforderungen (App-Größe, Berechtigungstexte, Icon-Regeln) als Nachgedanken statt als Ausgangspunkt zu behandeln. Wie in unserem Beitrag zum Einreichungsprozess bei App Store und Google Play beschrieben, kann das selbst eine gut gebaute Flutter-App beim ersten Versuch zum Scheitern bringen.
- Veröffentlichung ohne echte Gerätetests auf beiden Plattformen
- Berechtigungstexte und Icon-Regeln bis zum Ende der Entwicklung aufschieben
- Ein Feature, das einen Plattform-Kanal braucht, ans Projektende schieben
Wo Flutter an Grenzen stößt
Es gibt sie. Setzt die App stark auf Augmented Reality, aufwendige Kameraverarbeitung oder plattformspezifischen Hardwarezugriff, braucht genau dieser Teil möglicherweise nativen Code über Plattform-Kanäle. Flutter unterstützt das, aber es ist nicht dasselbe wie natives Schreiben von Grund auf.
Es gibt auch die Frage, die Designsprache jeder Plattform pixelgenau nachzubilden. Für die meisten kommerziellen Apps bemerken Nutzer den Unterschied nicht; bei Marken mit sehr strengen visuellen Richtlinien lohnt sich ein direktes Gespräch vor Projektstart.
Ein Praxisbeispiel: eine Händler-App
Ein Bodenbelagshersteller wollte, dass sein Händlernetz Lagerbestände prüft und Bestellungen vom Telefon aus verfolgt. Statt zwei native Teams aufzubauen, entwickelten wir mit einem Flutter-Team; dieselbe Oberfläche, dieselbe Geschäftslogik, am selben Tag in beiden Stores veröffentlicht.
Jedes Feature, das Händler danach anfragten, wurde einmal geschrieben, einmal getestet. Zwei getrennte, im Gleichschritt arbeitende Teams hätten diesen Kreislauf erheblich verlangsamt.
Was sich bei Release und Wartung ändert
Eine Codebasis erzeugt weiterhin zwei getrennte Pakete für App Store und Google Play, aber die Quelle bleibt einheitlich. Erscheint ein Update, kann es am selben Tag mit derselben Versionsnummer in beide Stores gehen.
Über niedrigere Wartungskosten hinaus heißt das: Beide Plattformen bleiben gleichzeitig aktuell; keine Plattform hinkt einem Feature hinterher.
Flutter ist ein solider Weg für Unternehmen, die beide Stores ohne zwei native Teams abdecken wollen, sofern die Grenzen vorher klar sind; gut eingesetzt bringt es Geschwindigkeit und leichtere Pflege. Neigt Ihre App eher zu plattformspezifischer Arbeit oder ähnelt sie einem Standard-Geschäftstool, lohnt sich ein kurzes Gespräch vor der Planung.
Häufige Fragen
Laufen Flutter-Apps so schnell wie native Apps?
Für die meisten Business-Apps ja; Flutter nutzt eine eigene Rendering-Engine, und Nutzer bemerken keine spürbare Verzögerung.
Können Flutter-Apps native Funktionen wie Kamera, Standort oder Push-Benachrichtigungen nutzen?
Ja, über offizielle Pakete und bei Bedarf über Plattform-Kanäle für spezifischere Anforderungen.
Ist es sinnvoll, eine bestehende native App in Flutter neu zu schreiben?
Kommt darauf an; statt eine funktionierende App komplett neu zu schreiben, wägen wir neuen Feature-Bedarf gemeinsam gegen die laufende Wartungslast ab.
Wie lange dauert es, bis ein Team Flutter beherrscht?
Dart selbst ist recht schnell zu lernen, aber eine solide Architektur braucht Erfahrung, weshalb ein erfahrenes Team im ersten Projekt später Zeit spart.
