--- title: "State machines and statecharts in Flutter, when they pay off and how they fit with Bloc" description: "From the Apollo software to David Harel to Flutter: when state machines and statecharts beat booleans and GestureDetector in complex UIs, and what that means for Bloc and Cubit." canonical_url: "https://robocitrus.com/en/blog/state-machines-statecharts-flutter-ui" last_updated: "2026-10-21T00:00:00.000Z" locale: en meta: "og:description": "From the Apollo software to David Harel to Flutter: when state machines and statecharts beat booleans and GestureDetector in complex UIs, and what that means for Bloc and Cubit." "og:image": "https://robocitrus.com/images/blog/state-machines-statecharts-flutter-ui.webp" "og:title": "State machines and statecharts in Flutter, when they pay off and how they fit with Bloc" --- > Index of every page on this site: [llms.txt](https://robocitrus.com/llms.txt) ![When your Flutter widget needs a state machine (AI-generated cover image)](https://robocitrus.com/cdn-cgi/image/w=2048,q=75/images/blog/state-machines-statecharts-flutter-ui.webp) # **When your Flutter widget needs a state machine** [![Maximilian Flechtner](https://robocitrus.com/cdn-cgi/image/q=75/images/about-me-maximilian-image.webp)**Maximilian Flechtner**](https://robocitrus.com/en/about) Published:October 21, 2026 1 min read [**Flutter**](https://robocitrus.com/en/blog/tags/flutter) [**Dart**](https://robocitrus.com/en/blog/tags/dart) [**State Management**](https://robocitrus.com/en/blog/tags/state%20management) [**UI**](https://robocitrus.com/en/blog/tags/ui) [**App-Development**](https://robocitrus.com/en/blog/tags/app-development) ## A talk that starts with fighter jets and the moon landing The talk was titled "From Fighter Jets to Flutter" and was really about state machines and statecharts in Flutter UI development. The speaker said right at the start that there would be no fighting today. Instead, we went to the moon. I liked the opening because it answers a question I ask myself a lot: why do my UIs get messy at some point, even though every single piece looks simple? ## The history, short version Margaret Hamilton was part of the team that wrote the software for the Apollo mission. When that software crashes, you don't get an error message, you get a catastrophe. No hot reload either. One anecdote from the talk: shortly before landing, the software noticed CPU usage climbing and stopped certain code from running. Otherwise it would have crashed. In 1977 Hamilton and colleagues founded a company called Higher Order Software. The idea was a new way to describe critical software, declaratively and with a strict syntax. If something can't be expressed in that syntax, it counts as wrong. They used function trees for this, graphs that show what the software does. David Harel was doing his PhD at MIT at the time and spent a summer with the team. He asked how you actually verify such software. He wasn't convinced by the "it's all in the syntax" answer. But he liked the graphical approach. Later he was approached for a confidential project in Israel. It was software for fighter jets. The engineers knew their own parts very well but couldn't describe the whole system. Questions were answered with pointers to hundreds of pages of manuals. While asking and listening, Harel noticed he had started drawing diagrams. And that people understood those diagrams better than a pile of text. That's how statecharts came about. A note on sources: my recording is unclear on the year of the fighter jet work, so I'm not naming one. ## State machine vs. statechart A state machine is simple. You have a state, an event comes in, and you end up in another state. That's it. For complex systems that isn't enough. Harel extended the concept into statecharts. The key point from the talk: states can contain other states. You nest them. That lets you describe much more complex behavior without the diagram blowing up. ## The example: cards on a board The speaker works on a tool that converts designs into Flutter code. There he ran into complex interactions: dragging handles, resizing, moving. At some point he couldn't describe them anymore. Then he found Harel. For the demo he built a small note-taking app. Cards sit on a board, you can drag them and resize them at the corners. The interesting part: while you resize a card at a corner, you press the spacebar. Now you move the whole card. Release the key and you're resizing again. Anyone who has used a design tool knows this behavior. The statechart for it consists of: - an `**idle**` state where nothing happens, - a `**changing**` state that contains the substates `**resizing**` and `**moving**`, - a `**canceled**` state for when the action is discarded. States and events can carry data. When resizing, the app needs to know which corner is being dragged, for example. The "resize" event brings that information along. This makes the description a lot simpler. The speaker implemented it with his own Dart package called Harel, named after David Harel. There's also a companion tool, the Harel Inspector. ## The inspector, and why it convinced me The inspector connects to the running app and shows the statechart as a diagram. You drag a corner, and the active state lights up. Press the spacebar and you see the switch from `**resizing**` to `**moving**` live. Two more things I find practical: - An event log that lists all events in order. You can read bugs off it. - Clicking a state jumps straight to the matching code in the IDE. In big codebases that saves search time. The speaker's point, roughly: without a framework like this you write `**print**` statements by hand. With a state machine you get observability for free. With a `**GestureDetector**` plus a few booleans, you'd have to build it again for every app. ## AI writes the code, you still have to understand it This part stuck with me most. The speaker asked the audience who reads the code an LLM writes. Who reads more than half? Who reads all of it? His point: we simply don't have the time to review every line. The demo app itself was written by an LLM. He gave it the package and a skill and told it to build the app with it. He still has to understand what's going on. A diagram you watch running next to the app is faster for that than reading logic. And since it's visible, your agent can look at it too. That matches what I wrote in [**When AI writes your Flutter app**](https://robocitrus.com/en/blog/wenn-ki-deine-flutter-app-schreibt) and [**Marionette MCP: AI agents testing Flutter apps**](https://robocitrus.com/en/blog/marionette-mcp-ki-agenten-flutter-apps-testen): the better you can see what the app does, the better you can control AI code. ## When does a state machine pay off? The speaker was clear: not for every piece of UI. His rule of thumb is a question: is my widget starting to look like an app? His examples: - A rich text editor with bold, italic, block types and drag and drop is no longer a widget, it's an app. - An Instagram-style story viewer: swipe up shows reactions, swipe down hides them, a short press discards them. You often don't plan for interactions like these at the start. But users expect them because they know Instagram or TikTok. And when you have to build them, that's the moment for a state machine. He also said you sometimes don't need all the overhead of states and events. Then normal architecture is enough. ## My take: state machines and Bloc From here on it's my own opinion, not the speaker's. He didn't compare [**Bloc**](https://bloclibrary.dev) or Cubit in the talk. I use Bloc and Cubit in most of my apps, the reasons are in [**Flutter State Management 2026**](https://robocitrus.com/en/blog/flutter-state-management-2026). For screens with data, loading, error and success it fits very well. A Cubit with a clean list of states is basically a small state machine already. What Bloc doesn't cover is the fine detail inside a widget. If a single card switches between resizing, moving and canceling, with a key press in the middle, I don't create a Bloc for that. There I'd now reach for a real state machine instead of stacking booleans in a `**StatefulWidget**`. The way I see it: Bloc or Cubit for app state, a state machine for complex interactions inside one widget. Whether I'll use the Harel package myself, I can't say yet. I haven't tried it. I do like the idea of getting observability for free. ## Conclusion The talk gave me a simple criterion: if your widget looks like an app, you need more than booleans. Statecharts have been proven for decades, from fighter jets to design tools. And in the age of AI-generated code, a diagram you can watch live is a pretty practical safety net. For most screens, architecture is enough. For the few interaction-heavy special cases, state machines are worth a look. More on my view of the framework is in [**Why I love Flutter**](https://robocitrus.com/en/blog/warum-ich-flutter-liebe). And how AI changes development overall is in [**AI in app development**](https://robocitrus.com/en/blog/ki-in-der-app-entwicklung). --- ## Frequently asked questions (FAQ) A state machine has states, events and transitions. A statechart adds nested states and can describe more complex behavior. Harel developed the concept because simple state machines weren't enough for systems like fighter jet software. The speaker uses a rule of thumb: when your widget starts to look like an app. Typical cases are editors with many modes or gesture-heavy interactions like a story viewer. For normal forms and lists, your existing architecture is usually enough. The talk didn't cover that. My take: no. Bloc or Cubit fit app state, a state machine fits complex interactions inside one widget. You can combine the two. A Dart package by the speaker, named after David Harel. You describe UI behavior as a statechart with it. There's also the Harel Inspector, which shows the diagram live next to the running app, provides an event log and jumps to the matching code. I haven't used it myself yet. According to the speaker, yes, because you can watch the behavior live as a diagram instead of reading logic. He had an LLM write the demo app with the package and a skill as context, then followed what it did through the inspector. --- *This article was inspired by the talk "State Machines, State Charts, and Flutter UI Development" (From Fighter Jets to Flutter) at FlutterCon 2026.* [**Social Login in Apps: Why You Should Offer Apple, Google & Co.** 50% of users abandon registration forms. With social login (Apple, Google, Facebook), you drastically reduce drop-off rates and improve UX.](https://robocitrus.com/en/blog/social-login-app) [**Why Your First App Without Perfect Architecture Is Better Than No App at All** If you work with Flutter, you know this: You finally want to build your own app, but first get lost for weeks in YouTube tutorials about the 'perfect architecture'. Clean Architecture here, SOLID principles there, and in the end you haven't written a single line of code.](https://robocitrus.com/en/blog/warum-erste-app-ohne-perfekte-architektur-besser-als-keine-app) ## **Let's Connect! 🚀** ### **Ready for your next project? **
** Let's get started!** ![Maximilian Flechtner - Gründer](https://robocitrus.com/cdn-cgi/image/w=3840,f=png,q=75/images/about-me-maximilian-image.webp) #### **Maximilian Flechtner ** [flechtner@robocitrus.com](mailto:flechtner@robocitrus.com) [ +49 0176 41766223](tel:+4917641766223) ### **Let's get started** Tell me about your vision – just drop me an email or use the contact form. Let's plan your digital success together! 💪 [Send me an email](mailto:flechtner@robocitrus.com) [Contact Form](https://robocitrus.com/en/kontakt) ```json {"@context":"https://schema.org","@graph":[{"@id":"https://robocitrus.com/en#website","@type":"WebSite","description":"App Entwickler & Full-Stack Experte aus Deutschland. Ich baue skalierbare Apps, Backends und komplette Startup-Systeme mit Flutter, Go und Kubernetes.","inLanguage":"en-US","name":"Maximilian Flechtner - App Entwickler","url":"https://robocitrus.com/en","publisher":{"@id":"https://robocitrus.com/#/schema/organization/1"},"translationOfWork":{"@id":"https://robocitrus.com/#website"}},{"@id":"https://robocitrus.com/en/blog/state-machines-statecharts-flutter-ui#webpage","@type":"WebPage","dateModified":"2026-10-21T00:00:00.000Z","datePublished":"2026-10-21","description":"From the Apollo software to David Harel to Flutter: when state machines and statecharts beat booleans and GestureDetector in complex UIs, and what that means for Bloc and Cubit.","name":"State machines and statecharts in Flutter, when they pay off and how they fit with Bloc","url":"https://robocitrus.com/en/blog/state-machines-statecharts-flutter-ui","breadcrumb":{"@id":"https://robocitrus.com/en/blog/state-machines-statecharts-flutter-ui#breadcrumb"},"isPartOf":{"@id":"https://robocitrus.com/en#website"},"potentialAction":[{"@type":"ReadAction","target":["https://robocitrus.com/en/blog/state-machines-statecharts-flutter-ui"]}],"primaryImageOfPage":{"@id":"https://robocitrus.com/#logo"}},{"@id":"https://robocitrus.com/#identity","@type":"Organization","alternateName":"Robocitrus","description":"App Entwickler & Full-Stack Experte aus Deutschland. Spezialisiert auf skalierbare Apps, Backend-Systeme und komplette Startup-Lösungen mit Flutter, GoLang und Kubernetes. Von der Idee bis zum Launch - alles aus einer Hand.","email":"flechtner@robocitrus.com","name":"Maximilian Flechtner - App Entwicklung","telephone":"0176 41766223","url":"https://robocitrus.com","address":{"@type":"PostalAddress","streetAddress":"Leppiner Dorfstraße 60","addressLocality":"Arendsee","addressRegion":"Sachsen-Anhalt","postalCode":"39619","addressCountry":"DE"},"contactPoint":{"@type":"ContactPoint","telephone":"0176 41766223","email":"flechtner@robocitrus.com"},"logo":{"@id":"https://robocitrus.com/#logo"}},{"@id":"https://robocitrus.com/en/blog/state-machines-statecharts-flutter-ui#article","dateModified":"2026-10-21T00:00:00.000Z","datePublished":"2026-10-21","description":"From the Apollo software to David Harel to Flutter: when state machines and statecharts beat booleans and GestureDetector in complex UIs, and what that means for Bloc and Cubit.","headline":"When your Flutter widget needs a state machine","inLanguage":"en-US","thumbnailUrl":"https://robocitrus.com/images/blog/state-machines-statecharts-flutter-ui.webp","wordCount":200,"@type":["Article","BlogPosting"],"author":{"@id":"https://robocitrus.com/#/schema/person/1"},"image":{"@id":"https://robocitrus.com/#/schema/image/1"},"isPartOf":{"@id":"https://robocitrus.com/en/blog/state-machines-statecharts-flutter-ui#webpage"},"keywords":["Flutter","Dart","State Management","UI","App-Development"],"mainEntityOfPage":{"@type":"WebPage","@id":"https://robocitrus.com/en/blog/state-machines-statecharts-flutter-ui"},"publisher":{"@id":"https://robocitrus.com/#/schema/organization/1"}},{"@id":"https://robocitrus.com/en/blog/state-machines-statecharts-flutter-ui#breadcrumb","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","name":"Blog","item":"https://robocitrus.com/blog","position":1},{"@type":"ListItem","name":"When your Flutter widget needs a state machine","position":2}]},{"@id":"https://robocitrus.com/#/schema/person/1","@type":"Person","name":"Maximilian Flechtner","url":"https://robocitrus.com/about","image":{"@id":"https://robocitrus.com/#/schema/image/2"}},{"@id":"https://robocitrus.com/#/schema/organization/1","@type":"Organization","name":"Maximilian Flechtner - App Entwicklung","url":"https://robocitrus.com/","logo":{"@type":"ImageObject","url":"https://robocitrus.com/images/large-logo.webp"}},{"@id":"https://robocitrus.com/#logo","@type":"ImageObject","caption":"Maximilian Flechtner - App Entwicklung","contentUrl":"https://robocitrus.com/images/large-logo.webp","inLanguage":"en-US","url":"https://robocitrus.com/images/large-logo.webp"},{"@id":"https://robocitrus.com/#/schema/image/1","@type":"ImageObject","contentUrl":"https://robocitrus.com/images/blog/state-machines-statecharts-flutter-ui.webp","inLanguage":"en-US","url":"https://robocitrus.com/images/blog/state-machines-statecharts-flutter-ui.webp"},{"@id":"https://robocitrus.com/#/schema/image/2","@type":"ImageObject","contentUrl":"https://robocitrus.com/images/about-me-maximilian-image.webp","inLanguage":"en-US","url":"https://robocitrus.com/images/about-me-maximilian-image.webp"}]} ``` ## Sitemap See the full [sitemap](https://robocitrus.com/sitemap.md) for all pages.