Flutter developers often hear that Dart is single-threaded and that Flutter uses isolates for concurrency. But that explanation leaves an important question unanswered: if Dart code runs in an isolate, where do Flutter's UI, raster, platform, and I/O workloads actually run? In this session, we'll go beyond async/await, Futures, and compute() to understand how Dart's runtime and Flutter's engine work together to execute an application. We'll explore the Dart event loop, microtask and event queues, isolates, message passing, and memory isolation, then connect these concepts to Flutter's engine threads and frame rendering pipeline. You'll learn: How Dart's event loop, microtask queue, and event queue actually schedule asynchronous work. What an isolate is, how it differs from a thread, and why isolates don't share mutable memory. What really happens when work is moved using Isolate.run() or compute(). How Dart isolates interact with Flutter's UI, raster, platform, and I/O work. Why CPU-heavy Dart code can cause jank even when using async/await. By the end, you'll have a clear mental model of Flutter's concurrency architecture and be able to reason about where work is executed, when it blocks the UI, and when moving work to another isolate actually improves performance