Wann dein Flutter-Widget eine State Machine braucht

Ein Talk, der mit Kampfjets und Mondlandung anfängt

Der Talk hieß "From Fighter Jets to Flutter" und ging eigentlich um State Machines und Statecharts in der Flutter-UI-Entwicklung. Der Speaker hat gleich zu Beginn gesagt: Es wird heute keinen Kampf geben. Stattdessen ging es zum Mond.

Ich fand den Einstieg stark, weil er eine Frage beantwortet, die ich mir selbst oft stelle: Warum werden meine UIs irgendwann unübersichtlich, obwohl jeder einzelne Teil simpel aussieht?

Die Geschichte in kurz

Margaret Hamilton war Teil des Teams, das die Software für die Apollo-Mission geschrieben hat. Wenn dort Software abstürzt, ist das keine Fehlermeldung, sondern eine Katastrophe. Hot Reload gab es auch nicht. Eine Anekdote aus dem Talk: Kurz vor der Landung hat die Software gemerkt, dass die CPU-Auslastung hochgeht, und hat verhindert, dass bestimmter Code läuft. Sonst wäre die Software abgestürzt.

Danach gründete Hamilton 1977 mit Kollegen die Firma Higher Order Software. Die Idee: eine neue Art, kritische Software zu beschreiben, deklarativ und mit strenger Syntax. Was sich in dieser Syntax nicht ausdrücken lässt, gilt als falsch. Dabei nutzten sie Funktionsbäume, also Graphen, die zeigen, was die Software tut.

David Harel promovierte damals am MIT und arbeitete einen Sommer mit dem Team. Er fragte, wie man solche Software eigentlich verifiziert. Von der "alles steckt in der Syntax"-Antwort war er nicht überzeugt. Die grafische Darstellung hat ihm aber gefallen.

Später wurde er für ein vertrauliches Projekt in Israel angefragt. Es ging um Software für Kampfjets. Die Ingenieure kannten ihre Teile sehr gut, konnten aber das Gesamtsystem nicht beschreiben. Auf Fragen gab es Verweise auf hunderte Seiten Handbücher. Harel merkte beim Fragen und Zuhören, dass er anfing, Diagramme zu zeichnen. Und dass die Leute diese Diagramme besser verstanden als einen Stapel Text. So entstanden die Statecharts.

Eine Randnotiz zur Quellenlage: Beim Jahr der Kampfjet-Arbeit ist die Mitschrift unklar, deshalb nenne ich hier keins.

State Machine vs. Statechart

Eine State Machine ist simpel. Du hast einen Zustand, es kommt ein Event, du landest in einem anderen Zustand. Mehr ist es nicht.

Für komplexe Systeme reicht das nicht. Harel hat das Konzept deshalb zu Statecharts erweitert. Der wichtigste Punkt aus dem Talk: Zustände können andere Zustände enthalten. Du verschachtelst sie. Damit lässt sich viel komplexeres Verhalten beschreiben, ohne dass das Diagramm explodiert.

Das Beispiel: Karten auf einem Board

Der Speaker arbeitet an einem Tool, das Designs in Flutter-Code übersetzt. Dort wurde er mit komplexen Interaktionen konfrontiert: Ziehen von Anfassern, Größe ändern, verschieben. Irgendwann kam er nicht mehr weiter, die Interaktionen zu beschreiben. Dann stieß er auf Harel.

Für die Demo hat er eine kleine Notiz-App gebaut. Karten liegen auf einem Board, du kannst sie ziehen und an den Ecken skalieren. Der spannende Teil: Während du eine Karte an der Ecke skalierst, drückst du die Leertaste. Jetzt verschiebst du die ganze Karte. Lässt du die Taste los, skalierst du wieder. Wer ein Design-Tool kennt, kennt dieses Verhalten.

Das Statechart dazu besteht aus:

• einem idle-Zustand, in dem nichts passiert,
• einem changing-Zustand, der die Unterzustände resizing und moving enthält,
• einem canceled-Zustand, wenn die Aktion verworfen wird.

Zustände und Events können Daten tragen. Beim Skalieren muss die App zum Beispiel wissen, welche Ecke gezogen wird. Das Event "resize" bringt diese Information mit. Das macht die Beschreibung deutlich einfacher.

Umgesetzt hat der Speaker das mit einem eigenen Dart-Package namens Harel, benannt nach David Harel. Dazu gibt es ein Tool, den Harel Inspector.

Der Inspector und warum er mich überzeugt hat

Der Inspector verbindet sich mit der laufenden App und zeigt das Statechart als Diagramm. Du ziehst an einer Ecke, und der aktive Zustand leuchtet auf. Drückst du die Leertaste, siehst du live den Wechsel von resizing zu moving.

Dazu kommen zwei Dinge, die ich praktisch finde:

• Ein Event-Log, das alle Events in der Reihenfolge zeigt. Daran kannst du Bugs ablesen.
• Ein Klick auf einen Zustand springt direkt zum passenden Code in der IDE. In großen Codebasen spart das Suchzeit.

Der Speaker sagte dazu sinngemäß: Ohne so ein Framework schreibst du print-Ausgaben von Hand. Mit einer State Machine bekommst du Observability geschenkt. Und mit einem GestureDetector plus ein paar Booleans musst du sie für jede App neu bauen.

KI schreibt den Code, du musst ihn trotzdem verstehen

Der Teil hat mich am meisten beschäftigt. Der Speaker hat das Publikum gefragt, wer den Code liest, den ein LLM schreibt. Wer mehr als die Hälfte liest? Wer alles? Seine Aussage: Wir haben schlicht nicht die Zeit, jede Zeile zu prüfen.

Die Demo-App selbst hat ein LLM geschrieben. Er hat ihm das Package und einen Skill gegeben und gesagt, es soll die App damit bauen. Trotzdem muss er verstehen, was da passiert. Ein Diagramm, das du live neben der App laufen siehst, geht dafür schneller als Logik lesen. Und weil es sichtbar ist, kann auch dein Agent es sich ansehen.

Das deckt sich mit dem, was ich in Wenn KI deine Flutter-App schreibt und Marionette MCP: KI-Agenten testen Flutter-Apps schon beschrieben habe: Je besser du sehen kannst, was die App tut, desto besser kannst du KI-Code kontrollieren.

Wann lohnt sich eine State Machine?

Der Speaker war klar: Nicht für jedes UI-Stück. Seine Faustregel ist eine Frage: Fängt mein Widget an, wie eine App auszusehen?

Seine Beispiele:

• Ein Rich-Text-Editor mit fett, kursiv, Blocktypen und Drag-and-drop ist kein Widget mehr, sondern eine App.
• Ein Story-Viewer im Instagram-Stil: Hochwischen zeigt Reaktionen, Runterwischen blendet sie aus, kurz drücken verwirft sie.

Solche Interaktionen plant man am Anfang oft nicht mit. Aber Nutzer erwarten sie, weil sie Instagram oder TikTok kennen. Und wenn du sie bauen musst, ist das der Moment für eine State Machine.

Er sagte auch, dass man den ganzen Aufwand mit States und Events manchmal gar nicht braucht. Dann reicht normale Architektur.

Meine Einordnung: State Machine und Bloc

Ab hier meine eigene Meinung, nicht die des Speakers. Er hat im Talk weder Bloc noch Cubit verglichen.

Ich nutze Bloc und Cubit in den meisten meiner Apps, die Gründe stehen in Flutter State Management 2026. Für Screens mit Daten, Laden, Fehler und Erfolg passt das sehr gut. Ein Cubit mit einer sauberen Liste von States ist im Grunde schon eine kleine State Machine.

Was Bloc nicht abdeckt, ist die Feinheit im Widget selbst. Wenn eine einzelne Karte zwischen Skalieren, Verschieben und Abbrechen wechselt, mit Tastendruck mittendrin, lege ich dafür keinen Bloc an. Dort würde ich heute zu einer echten State Machine greifen, statt Booleans in einem StatefulWidget zu stapeln.

Ich sehe das so: Bloc oder Cubit für den App-Zustand, State Machine für komplexe Interaktionen in einem Widget. Ob ich das Harel-Package selbst einsetze, kann ich noch nicht sagen. Ich habe es nicht ausprobiert. Die Idee, Observability geschenkt zu bekommen, finde ich aber gut.

Fazit

Der Talk hat mir ein einfaches Kriterium mitgegeben: Wenn dein Widget wie eine App aussieht, brauchst du mehr als Booleans. Statecharts sind dafür seit Jahrzehnten bewährt, von Kampfjets bis zum Design-Tool. Und in Zeiten von KI-generiertem Code ist ein Diagramm, das du live beobachten kannst, ein ziemlich praktisches Sicherheitsnetz.

Für die meisten Screens reicht Architektur. Für die wenigen interaktiven Spezialfälle lohnt sich der Blick auf State Machines.

Mehr zur Sicht auf das Framework findest du in Warum ich Flutter liebe. Und wie KI das Entwickeln insgesamt verändert, steht in KI in der App-Entwicklung.

Häufig gestellte Fragen (FAQ)

Dieser Artikel wurde inspiriert vom Talk "State Machines, State Charts, and Flutter UI Development" (From Fighter Jets to Flutter) auf der FlutterCon 2026.