Flutter-Projekte starten ohne den üblichen Strukturkram

Neue App-Idee, frischer Kaffee, motiviert wie selten. Dann: flutter create my_awesome_app - und plötzlich vergehen die nächsten vier Stunden damit, Ordnerstrukturen zu diskutieren, Riverpod einzurichten, GoRouter zu konfigurieren und sich zu fragen, ob Clean Architecture oder MVVM jetzt eigentlich die bessere Wahl wäre. Die App selbst? Die wartet noch.

Genau da setzt FlutterInit an.

Was ist FlutterInit?

FlutterInit ist ein webbasierter Scaffold-Generator für Flutter-Projekte - auf die Seite gehen, Optionen wählen, fertig ist ein vollständig strukturiertes, production-ready Projekt. Kein Copy-Paste aus alten Projekten, kein verzweifeltes Suchen nach dem "perfekten Starter-Template" auf GitHub.

Die Auswahl ist konkret:

• Architektur: Clean Architecture, MVVM oder Feature-First
• State Management: Riverpod oder Bloc
• Routing: GoRouter oder AutoRoute
• Extras: Supabase, Firebase, Dio - alles bereits verdrahtet

Material 3 Design Tokens, Logging, Error Handling und Environment-Config sind direkt mit eingebaut - weil niemand auf Layer 1 anfangen will, wenn Layer 2 wartet.

Für wen ist das sinnvoll?

Ehrlich gesagt für ziemlich jeden, der Flutter entwickelt. Für Freelancer, die schnell einen neuen Client-Projekt-Boilerplate brauchen, ohne das letzte Projekt auseinanderzunehmen. Für Teams, die sich nicht auf eine Architektur einigen können - einfach eine wählen und starten. Und für alle, die beim fünften Mal go_router manuell in die pubspec.yaml schreiben langsam das Gefühl haben, etwas falsch zu machen im Leben.

Die Vorteile auf den Punkt

Das Projekt ist Open Source und kostenlos, was bedeutet: wenn etwas nicht passt, kann man es anpassen oder einen PR aufmachen. Die generierten Projekte folgen Best Practices für 60fps-Performance und sind auf Enterprise-Skala ausgelegt - kein Spielzeug-Setup also.

Was wirklich überzeugt: Es ist nicht "nur ein weiteres starres Template". Der entscheidende Unterschied zu statischen Boilerplates ist die Flexibilität - Riverpod gegen Bloc tauschen, Clean Architecture statt MVVM wählen, und trotzdem direkt ein sauberes dart analyze-Ergebnis bekommen. Das ist der Unterschied zwischen einem konfigurierbaren Werkzeug und einem GitHub-Repo, das man seit 2022 forkt und dann doch wieder manuell umbaut.

Moment - wo sind android/ und ios/?

Beim ersten Entpacken des ZIPs fällt auf: Es gibt keine Plattform-Ordner. Kein android/, kein ios/, kein web/. Das ist kein Bug, sondern bewusste Designentscheidung.

Das ZIP enthält ausschließlich das, was plattformunabhängig ist: lib/ mit der kompletten Dart-Struktur (Architektur, State Management, Routing), pubspec.yaml mit allen konfigurierten Dependencies, assets/, analysis_options.yaml und eine SETUP.md. Die nativen Plattform-Verzeichnisse werden lokal von Flutter selbst erzeugt:

unzip dein-projekt.zip -d mein_projekt
cd mein_projekt

# Standard-Plattformen (android + ios)
flutter create .

# Oder gezielt wählen
flutter create --platforms=android,ios,web,macos,windows,linux .

flutter pub get

Der Punkt hinter flutter create sagt Flutter: "erweitere das bestehende Projekt, überschreib nichts." Die vorhandenen lib/- und assets/-Dateien bleiben unangetastet, nur die fehlenden nativen Ordner kommen dazu - und zwar genau in der Version, die zur lokal installierten Flutter-SDK passt.

Warum der Umweg? Weil Plattform-Code lokal abhängig ist. iOS-Scaffolding auf einem Windows-Rechner auszuliefern wäre sinnlos, und ein fünf Jahre altes android/-Gerüst aus einem GitHub-Template bringt niemanden weiter. Das ZIP bleibt so klein, universell und aktuell - der native Boilerplate kommt immer frisch vom eigenen System.

Kein glamouröses Problem - aber das nervige

FlutterInit löst nicht das spannende Problem. Es löst das nervige - das, das jeden Montagmorgen vor dem eigentlichen Arbeiten kommt. Wer öfter neue Flutter-Projekte aufsetzt, sollte das mal ausprobieren. Und wer es nur einmal benutzt, hat trotzdem vier Stunden gewonnen.

Das ist genug für einen zweiten Kaffee und den ersten echten Feature-Commit.

Fehlt ein Feature? Selber beitragen

Und falls im Generator tatsächlich mal eine Option fehlt, die ihr gerne hättet: FlutterInit ist Open Source. Einfach das Repo auf GitHub forken, die gewünschte Architektur, das Package oder die Extra-Integration ergänzen und einen Pull Request aufmachen. So wächst das Tool genau in die Richtung, die die Community tatsächlich braucht - und der nächste Montagmorgen wird für alle ein bisschen weniger nervig.

flutterinit.com - Open Source auf GitHub