Flutter-Entwicklung was das Framework kann, wo es Grenzen hat und wann ich es empfehle.

Diese Seite erklärt das Werkzeug. Was ich damit für euch tue, steht auf der Startseite unter Leistungen. Ihr sitzt im Raum Karlsruhe und wollt euch treffen? App entwickeln lassen in Karlsruhe und Ettlingen.

Was Flutter ist, in drei Sätzen

Flutter ist ein Open-Source-Framework von Google, mit dem aus einer Codebasis Apps für iOS und Android entstehen, auf Wunsch auch für Web und Desktop. Anders als bei Web-Containern wird die App nativ kompiliert und zeichnet ihre Oberfläche selbst, sie fühlt sich deshalb auf beiden Plattformen flüssig und gleich an. Programmiert wird in Dart, einer Sprache, die für genau diesen Zweck entworfen wurde und sich für Entwickler mit Java-, Kotlin- oder TypeScript-Hintergrund schnell erschließt.

Wann Flutter die richtige Wahl ist

• Ihr braucht iOS und Android gleichzeitig. Eine Codebasis, ein Team, ein Release-Termin. Das ist der Hauptgrund und er trägt bei den meisten Unternehmens-Apps.
• Eure Oberfläche soll eigenständig aussehen. Flutter zeichnet jedes Pixel selbst, ein eigenes Design wird dadurch einfacher als mit nativen Bausteinen, die sich pro Plattform unterscheiden.
• Ihr wollt schnell Zwischenstände sehen. Änderungen erscheinen beim Entwickeln sofort auf dem Gerät, Feedback-Runden werden kurz.
• Die App soll lange leben. Flutter wird von Google und einer großen Community getragen, die Toolchain ist stabil, und ein sauber strukturiertes Projekt lässt sich auch nach Jahren noch von anderen Entwicklern übernehmen.
• Ihr liefert oft aus. Mit Shorebird gehen Korrekturen als Over-the-Air-Update an die Nutzer, ohne auf die Store-Prüfung zu warten.

Wo Flutter an Grenzen stößt

Ich empfehle Flutter nicht reflexhaft. Es gibt Fälle, in denen ich zu nativ oder zu einer anderen Lösung rate:

• Tiefe Plattform-Funktionen. Widgets auf dem Homescreen, App Clips, CarPlay, Wear OS oder komplexe Hintergrunddienste sind nativ einfacher. In Flutter geht vieles davon auch, aber über eine selbst gebaute Brücke zu Swift oder Kotlin, und die kostet Zeit.
• Sehr große native Bestandsapps. Wer eine ausgereifte native App mit eigenem Team hat, gewinnt durch einen Wechsel wenig. Dann ergänze ich lieber einzelne Flutter-Module, als alles neu zu schreiben.
• Web als Hauptziel. Flutter Web funktioniert, aber für inhaltslastige Websites mit Suchmaschinen-Anspruch ist eine klassische Web-Technik die bessere Wahl.
• App-Größe und Startzeit. Eine Flutter-App ist etwas größer als eine minimale native App. Für die allermeisten Anwendungen ist das unerheblich, bei strengen Vorgaben spreche ich es vorher an.

Wie ich Flutter-Projekte baue

Architektur

Trennung in Schichten (UI, Anwendungslogik, Datenzugriff), State-Management mit Riverpod oder BLoC je nach Teamgewohnheit, Feature-Ordner statt Typ-Ordner, damit ein neues Feature an einer Stelle entsteht. Tests dort, wo sie Fehler verhindern: Logik und Datenzugriff immer, UI gezielt.

Backend und Daten

Firebase oder Supabase, wenn schnell ein Backend gebraucht wird, REST oder GraphQL gegen bestehende Systeme, SQLite und Offline-First, wenn die App auch ohne Netz funktionieren muss, etwa bei Fahrer- oder Außendienst-Apps.

Native Brücken

Bluetooth Low Energy, NFC, In-App-Käufe, Payment-SDKs und Kamera-Funktionen habe ich mehrfach über Platform Channels angebunden. Wo ein gepflegtes Paket existiert, nutze ich es, wo nicht, schreibe ich die Brücke in Swift und Kotlin selbst.

Auslieferung

CI/CD mit Codemagic oder GitHub Actions, automatisierte Builds für TestFlight und Google Play, Over-the-Air-Updates mit Shorebird. Ihr seht jede Version, bevor sie in den Store geht.

Was ich für Flutter-Teams tue

• Neue Flutter-App von der Architektur bis zum Store, allein oder mit eurem Team.
• Code-Review und Bestandsaufnahme einer bestehenden Flutter-App mit ehrlicher Einschätzung: Was ist gut, was muss weg, was kostet die Übernahme.
• Refactoring und Migration, etwa von setState auf Riverpod, auf aktuelle Flutter-Versionen oder von nativ zu Flutter, schrittweise und ohne Auslieferungsstopp.
• Technical Lead auf Zeit: Architekturentscheidungen, Reviews, Onboarding neuer Entwickler, Abstimmung mit Backend und Design.
• Flutter-Einführung in Teams, die bisher nativ oder gar nicht mobil entwickelt haben: Setup, Konventionen, erste Features gemeinsam.

Ablauf, Kundenstimmen und alle Projekte: zur Startseite.