Most Flutter apps don't fail because of bad logic. They fail because of uncontrolled state. That's the finding baked into Flutter's own architectural documentation, which draws directly from React's core philosophy: UI equals f of state. Every single thing you see on screen is a pure output of the current state of your app. Change the state, the UI follows. No manual DOM manipulation, no imperative commands. The framework recalculates and redraws. That single idea reshuffles everything you thought you knew about building interfaces, Nikola. So what actually counts as state? Anything that can change and that the UI needs to reflect. A checkbox being ticked. A username fetched from a server. A counter incrementing on tap. Flutter splits this into two distinct categories, and getting this split right is where architecture begins. The first is ephemeral state, also called UI state. Flutter's own documentation defines it precisely: state that lives entirely inside a single widget, invisible to the rest of the app. Think of a BottomNavigationBar tracking which tab is selected, or an animation's current progress. Nothing outside that widget needs to know. That's ephemeral. The second category is app-wide state, sometimes called shared state. This crosses widget boundaries — a logged-in user's profile, a shopping cart, a theme preference. It needs to be accessible from multiple places simultaneously. The distinction isn't cosmetic, Nikola. It directly determines which tool you should reach for. For ephemeral state, Flutter gives you setState. When you call it, you're telling the framework one specific thing: the internal state of this object has changed, schedule a rebuild for this subtree. Not the whole tree. Just the relevant branch. That precision matters enormously because Flutter targets 60 frames per second, and 120 FPS on capable hardware. Unnecessary rebuilds eat into that budget fast. setState is not a shortcut or a beginner's crutch — it is the correct, documented tool for localized, single-widget state. Where setState breaks down is when state needs to travel. When a widget deep in your tree needs data owned by a widget far above it, passing that data manually through every layer becomes brittle and unscalable. That's the precise moment a state management library earns its place. Here's the synthesis, and it's the one idea worth carrying out of this lecture: grasping the line between ephemeral and app-wide state is not a detail — it is the fundamental prerequisite for choosing the right architectural pattern in Flutter. Get that distinction sharp, and every tool you pick up from here will make immediate sense.