Flutter Interview Questions (2026): Most Asked, With Answers

In Flutter, layout, styling, animation, and even structural concerns like padding or alignment are all expressed as widgets, immutable configuration objects that describe what a piece of UI should look like at a point in time. Padding isn't a property you set on a container, it's its own widget that wraps another widget. That uniformity means the framework only needs one mental model, compose widgets, to build anything from a single button to an entire screen, instead of a separate API for layout versus styling versus animation.

The tradeoff is that a real screen ends up as a deep tree of small, single-purpose widgets. That's intentional. Flutter's diffing and rebuild logic is built to handle wide, shallow trees of cheap objects, not a few widgets carrying a lot of internal state.

A StatelessWidget describes UI that depends only on the configuration passed into it and never changes on its own, given the same constructor arguments, it always builds the same output. A StatefulWidget owns a separate State object that can hold mutable data across rebuilds and call setState to schedule a new build when that data changes.

class Greeting extends StatelessWidget {
 final String name;
 const Greeting({super.key, required this.name});

 @override
 Widget build(BuildContext context) => Text('Hello, $name');
}

class Counter extends StatefulWidget {
 const Counter({super.key});
 @override
 State<Counter> createState() => _CounterState();
}

class _CounterState extends State<Counter> {
 int count = 0;
 @override
 Widget build(BuildContext context) => Text('$count');
}

build can run far more often than you'd expect, on every frame that touches that widget's subtree, on theme or MediaQuery changes, on parent rebuilds that don't even change this widget's own data. Anything with a side effect, a network call, writing to a stream, calling setState, needs to run once per meaningful event, not once per build call, or you'll fire it dozens of times a second during something as simple as a scroll or a keyboard opening.

@override
Widget build(BuildContext context) {
 // wrong: this fires on every rebuild
 // api.fetchData();

 return FutureBuilder(...);
}

@override
void initState() {
 super.initState();
 api.fetchData(); // right: runs exactly once, when the State is created
}

Provider is a thin, well-tested wrapper around InheritedWidget that solves the boilerplate and lifecycle problems of writing one by hand. It gives you automatic disposal of ChangeNotifiers when the Provider is removed from the tree, a Consumer widget that scopes rebuilds to just the part of the tree that reads a value, and a family of provider types (ChangeNotifierProvider, FutureProvider, StreamProvider) instead of writing a custom InheritedWidget for each data type.

ChangeNotifierProvider(
 create: (_) => CartModel(),
 child: const MyApp(),
);

// anywhere below:
final cart = context.watch<CartModel>(); // rebuilds this widget on notifyListeners
context.read<CartModel>().addItem(item); // no rebuild, just calls a method

A Future represents a single value (or error) that will be available at some point in the future, and it completes exactly once. A Stream represents a sequence of values delivered over time, zero, one, or many, and it can keep emitting until it's explicitly closed.

Future<int> fetchOnce() async => 42; // resolves once

Stream<int> fetchTicks() async* {
 for (var i = 0; i < 5; i++) {
  await Future.delayed(const Duration(seconds: 1));
  yield i; // emits repeatedly
 }
}

A one-time network request is a Future. A websocket connection, a location update listener, or a text field's onChanged events are all naturally a Stream, because more than one value can legitimately arrive.

FutureBuilder rebuilds a widget once, when a single Future completes, moving through waiting, then done or error states. StreamBuilder does the same thing but keeps rebuilding every time the underlying Stream emits a new value, and stays subscribed until the widget is disposed or the stream closes.

FutureBuilder<User>(
 future: api.fetchUser(id),
 builder: (context, snapshot) {
  if (snapshot.connectionState == ConnectionState.waiting) return const CircularProgressIndicator();
  if (snapshot.hasError) return Text('Error: ${snapshot.error}');
  return Text(snapshot.data!.name);
 },
)

A one-shot API call is a FutureBuilder. A live chat message feed or a websocket price ticker is a StreamBuilder. Using FutureBuilder with a stream-shaped data source (a firestore document listener, say) means the UI only ever reflects the first value it ever received.

Individual widgets are cheap to allocate, but each one still becomes an Element that Flutter has to walk during build, and in many cases a RenderObject that participates in layout. A tree that's ten widgets deep where two would do means ten Elements to diff and, depending on which widgets they are, ten RenderObjects doing layout math on every frame that subtree rebuilds.

// deeper than it needs to be
Container(
 padding: const EdgeInsets.all(8),
 child: Align(
  alignment: Alignment.center,
  child: Container(
   child: Text('hi'),
  ),
 ),
)

// same result, fewer layers
Padding(
 padding: const EdgeInsets.all(8),
 child: Center(child: Text('hi')),
)

On a single screen this is invisible. Inside a ListView.builder item that gets instantiated dozens of times on screen at once, unnecessary nesting compounds fast, and it's usually the first thing to trim when a scrolling list starts dropping frames.

Named routes register a string-to-widget-builder mapping up front in MaterialApp.routes, and you navigate by string, Navigator.pushNamed(context, '/detail'). Pushing a MaterialPageRoute directly builds the widget inline at the call site.

MaterialApp(
 routes: {
  '/': (context) => const HomeScreen(),
  '/detail': (context) => const DetailScreen(),
 },
);
Navigator.pushNamed(context, '/detail');

// versus, no route table needed:
Navigator.push(context, MaterialPageRoute(builder: (_) => const DetailScreen()));

Named routes read nicely for simple apps with a shallow, static set of screens. They get awkward once a route needs typed arguments, since arguments passed through pushNamed arrive as an untyped Object, which is exactly the kind of thing go_router's typed path parameters were built to fix.

Forward, just pass it as a constructor argument to the widget you're navigating to, there's no need for anything more elaborate for simple cases. Backward, Navigator.pop accepts a return value, and the original push call's Future resolves with whatever was passed to pop.

final result = await Navigator.push<String>(
 context,
 MaterialPageRoute(builder: (_) => const PickerScreen()),
);
// result holds whatever PickerScreen passed to Navigator.pop(context, value)

For data that more than two screens need, a selected filter that affects both a list screen and a detail screen, passing it through constructors everywhere gets unwieldy fast, and that's when it's worth lifting the value into Provider or Riverpod instead of threading it through every route.

A Flutter plugin is a package with a Dart API on top, usually a platform channel underneath, plus separate native implementations for each platform it supports, an android/ folder with Kotlin or Java, an ios/ folder with Swift or Objective-C. The Dart side is shared, but each native implementation is written and maintained independently.

That independence is exactly why a plugin can fully support Android and only partially support iOS, or vice versa, someone implemented and tested one platform and never got around to the other, or a platform-specific native API the plugin depends on genuinely doesn't have an equivalent on the other OS. Checking a plugin's pub.dev page for its platform support table before depending on it for something platform-specific is a basic but frequently skipped step.

Flutter ships two parallel widget libraries, Material for Android's design language and Cupertino for iOS's, and both are pure Dart implementations of each platform's look, not wrappers around real native UIKit or Android View components. That's a deliberate tradeoff: Cupertino widgets on Flutter always look like iOS regardless of platform, even running on Android, because Flutter is painting them itself rather than delegating to the OS.

Widget build(BuildContext context) {
 return Platform.isIOS
   ? const CupertinoButton(child: Text('Continue'), onPressed: null)
   : const ElevatedButton(onPressed: null, child: Text('Continue'));
}

Most teams don't fully branch every widget like this, it's a lot of duplicated logic for a small visual difference. A common middle ground is Material everywhere with a handful of intentional Cupertino touches (an iOS-style modal sheet, a switch) where a platform's users would genuinely notice the difference.

Plain ListView with a children list builds every single item up front when the widget is constructed, whether or not it's currently visible on screen. ListView.builder lazily builds only the items near the visible viewport, calling the itemBuilder callback on demand as the user scrolls, and disposes items that scroll far enough off screen.

// builds all 10,000 items immediately, even if only 8 are visible
ListView(children: List.generate(10000, (i) => Text('Item $i')));

// builds only what's near the viewport
ListView.builder(
 itemCount: 10000,
 itemBuilder: (context, i) => Text('Item $i'),
);

For anything more than a handful of items, ListView.builder isn't a minor optimization, it's the difference between an app that opens instantly and one that visibly hangs building ten thousand widgets before the first frame ever shows.

Unit tests exercise plain Dart logic, no Flutter framework involved at all, a repository method, a formatting function, a Bloc's state transitions. Widget tests mount a widget in an in-memory test binding and can pump frames, tap, and scroll, without a real device or simulator, verifying that a widget builds and responds correctly on its own. Integration tests run the full app on a real device or emulator, exercising real platform channels, real navigation, and genuine end-to-end user flows.

testWidgets('tapping increments the counter', (tester) async {
 await tester.pumpWidget(const MaterialApp(home: Counter()));
 expect(find.text('0'), findsOneWidget);
 await tester.tap(find.byIcon(Icons.add));
 await tester.pump();
 expect(find.text('1'), findsOneWidget);
});

The practical tradeoff is speed versus fidelity. Unit and widget tests run in seconds without a device and make up the bulk of a healthy test suite. Integration tests are slow and need a real device or emulator, so they're usually reserved for a handful of critical end-to-end flows, checkout, login, not every feature.

BuildContext is a handle to a widget's location in the Element tree. It's how a widget looks things up from its ancestors, Theme.of(context), Navigator.of(context), MediaQuery.of(context), all of them walk up the Element tree from the context you pass in. It isn't a general-purpose object you can stash and use later, it's tied to a specific Element instance.

Future<void> _submit(BuildContext context) async {
 await api.save();
 // if the widget was removed from the tree during the await,
 // this context now points at a disposed Element
 Navigator.of(context).pop(); // can throw or silently do nothing
}

The fix is checking context.mounted (or the widget's own mounted property inside State) right after the await, before touching context again. This is one of the most common runtime exceptions in production Flutter apps, and it's exactly the kind of thing that only shows up once real users start navigating away mid-request.

Calling setState runs the callback you passed it synchronously, updating whatever fields it touched, and then marks that State's Element as dirty and schedules a new frame. It doesn't rebuild the whole app, it schedules Flutter to call build again on that specific Element (and by extension, its subtree) during the next frame.

void _increment() {
 setState(() {
  count++; // runs immediately
 });
 // build() gets called again on the next frame, not instantly here
}

Calling setState outside a State object, or after the widget has been disposed, throws. That's why every async callback that eventually calls setState needs a mounted check first, the widget might legitimately be gone by the time the callback fires.

A widget built with const is created once at compile time and reused across every rebuild that would otherwise recreate it identically. Flutter's rebuild logic checks widget equality when deciding whether an Element needs updating, and a const widget compares equal to itself trivially, which lets Flutter skip rebuilding that whole subtree entirely instead of walking into it and finding nothing changed.

@override
Widget build(BuildContext context) {
 return Column(
  children: [
   const Icon(Icons.star), // never rebuilt, same instance every time
   Text('$counter'),    // rebuilt every time counter changes
  ],
 );
}

On a screen with a handful of widgets this is invisible. On a list with hundreds of rows re-rendering on every scroll frame, skipping const-eligible subtrees is a real, measurable difference in dropped frames.

InheritedWidget is the primitive almost every state management library in Flutter is built on top of. It sits above a subtree in the widget tree and exposes its data through a static of(context) lookup, which walks up the Element tree from the calling context until it finds the nearest matching InheritedWidget. Any widget that calls that lookup during build registers as a dependent, and gets rebuilt automatically whenever the InheritedWidget above it updates and its updateShouldNotify returns true.

class CartInherited extends InheritedWidget {
 final int itemCount;
 const CartInherited({super.key, required this.itemCount, required super.child});

 static CartInherited of(BuildContext context) =>
   context.dependOnInheritedWidgetOfElementType<CartInherited>()!;

 @override
 bool updateShouldNotify(CartInherited old) => old.itemCount != itemCount;
}

Provider, Riverpod, and even parts of Bloc's Flutter bindings all lean on this same mechanism underneath their own APIs. Knowing this is the foundation is a good signal a candidate understands the framework, not just a library on top of it.

Bloc structures state changes as an explicit pipeline: a UI event goes in, the Bloc maps it to zero or more new states, and the UI listens to the stream of states coming out. The event and state are both typed, usually as sealed classes, which makes every possible transition visible and testable without touching a widget at all.

sealed class CounterEvent {}
class Increment extends CounterEvent {}

class CounterBloc extends Bloc<CounterEvent, int> {
 CounterBloc() : super(0) {
  on<Increment>((event, emit) => emit(state + 1));
 }
}

// in the UI:
BlocBuilder<CounterBloc, int>(
 builder: (context, state) => Text('$state'),
)

The tradeoff versus a ChangeNotifier is ceremony. Bloc forces every state change through an explicit event class, which is genuinely valuable on a team of eight engineers touching the same feature, and mostly overhead on a solo project with three screens.

My honest rule: setState for anything local to one widget that no sibling or ancestor needs to know about, a toggle, an expanded/collapsed flag. Provider or Riverpod once two or more widgets in different parts of the tree need the same piece of state, a logged-in user, a shopping cart. Bloc once the state transitions themselves get complicated enough that you want them unit-tested independent of any widget, a multi-step checkout flow with several failure states.

I've seen teams over-apply Bloc to a screen with one boolean flag, which buries a two-line problem under three files of boilerplate. I've also seen teams try to run an entire app's business logic through setState calls scattered across a dozen StatefulWidgets, which turns into an untestable mess the moment two screens need to agree on the same data. Neither extreme is really about the library, it's about matching the tool to how many places actually need to read the same state.

context.watch subscribes the calling widget to future changes, it should only be called inside build, and it causes a rebuild every time the provider notifies listeners. context.read grabs the current value once without subscribing to future changes, it's meant for one-off actions like a button's onPressed callback, not for values you display.

@override
Widget build(BuildContext context) {
 final cart = context.watch<CartModel>(); // correct: rebuilds when cart changes
 return ElevatedButton(
  onPressed: () => context.read<CartModel>().clear(), // correct: no subscription needed
  child: Text('${cart.items.length} items'),
 );
}

Calling context.watch inside a callback like onPressed instead of build throws at runtime, since watch relies on being called during a build phase to register the dependency correctly. Calling context.read where you meant watch compiles fine and just silently never rebuilds when the value changes, which is the sneakier of the two mistakes.

No thread blocks. Dart is single-threaded within an isolate, and async/await is syntax sugar over the event loop. When you hit an await, the function's execution is suspended and control returns to the event loop, which keeps processing other work, other events, other microtasks, until the awaited Future completes, at which point the rest of the function resumes as a scheduled microtask.

void main() async {
 print('1');
 await Future.delayed(Duration.zero);
 print('3'); // this line runs after other synchronous code gets a turn
}

void other() => print('2');

This is why a genuinely CPU-heavy synchronous loop, parsing a huge JSON payload with a plain for loop, still freezes the UI even inside an async function. Awaiting doesn't create parallelism by itself, it just yields control at points where there's actually something to wait on.

compute() (and its newer replacement, Isolate.run) is for work that's synchronous and CPU-bound, something that would block the UI isolate's event loop if run directly, not for something that's already async, like a network request. Awaiting a network call doesn't block anything, the wait itself is handled by the OS and Dart's event loop. Running a heavy synchronous computation directly on the main isolate does block, since nothing else on that isolate can run until it finishes.

// wrong: this is already non-blocking, compute adds isolate overhead for nothing
final data = await compute(_uselessWrap, url);

// right: genuinely CPU-bound synchronous work moved off the UI isolate
final parsed = await compute(jsonDecodeLarge, hugeJsonString);

A common interview trap: candidates reach for compute() around every network call out of habit, without noticing the actual bottleneck was JSON parsing a multi-megabyte response after the network call already returned, not the network call itself.

A widget kicks off an async call in initState or a button handler, the user navigates away before it resolves, the widget gets disposed, and then the callback fires and calls setState on a State object that no longer has a mounted Element. Flutter throws, since setState explicitly asserts the widget is still mounted before doing anything.

Future<void> _load() async {
 final data = await api.fetchData();
 if (!mounted) return; // guard before touching state after an async gap
 setState(() => _data = data);
}

The fix is always the same shape: check mounted immediately after the await, before touching setState, context, or anything else tied to this widget's lifecycle. Skipping this check is one of the most common crash reports in a production Flutter app that otherwise looks bug-free in manual testing, because it only reproduces when a user genuinely navigates away mid-request.

A parent passes a BoxConstraints object down to each child, a minimum and maximum width and height. Each child, using only those constraints and its own logic, decides its own size within that range and reports it back up to the parent. The parent then positions its children based on the sizes it got back. A child never gets to ask its parent how big it should be, and a parent can't dictate an exact size to a child that has its own sizing logic (like text needing to size itself to its content), only a range.

// Container passes down constraints to its child.
// Text ignores width up to a point and reports back its own intrinsic size
// based on the string and font, within whatever constraints it received.
Container(
 constraints: const BoxConstraints(maxWidth: 200),
 child: const Text('some text that might wrap'),
)

This one-directional flow is why a widget can't size itself based on its parent's size directly (a common beginner mistake trying to make a child "fill 50% of whatever space is available" without something like Expanded or a LayoutBuilder to actually get that information passed down explicitly).

RepaintBoundary creates a separate compositing layer for its subtree, so that when something inside it needs to repaint, Flutter only re-paints that isolated layer instead of walking back up and repainting everything above it in the same layer. It's the mechanism behind a lot of "why is my whole screen repainting when only one small widget animates" performance issues.

RepaintBoundary(
 child: AnimatedIcon(
  icon: AnimatedIcons.play_pause,
  progress: _controller,
 ),
)

Each RepaintBoundary is a real cost, a separate layer means more memory and more compositing work for the GPU. Wrapping every single widget in one is a net loss. It's worth reaching for around something that repaints frequently and independently of its neighbors, an animation, a video player surface, not sprinkled defensively across a static screen.

CustomPainter gives direct access to a Canvas, letting you draw arbitrary shapes, paths, gradients, and text directly with low-level drawing calls, instead of composing pre-built widgets. It's the right tool once what you're drawing genuinely can't be expressed by combining existing widgets, a custom chart, an unusual progress indicator shape, a signature pad.

class CirclePainter extends CustomPainter {
 @override
 void paint(Canvas canvas, Size size) {
  final paint = Paint()..color = Colors.blue;
  canvas.drawCircle(size.center(Offset.zero), size.width / 2, paint);
 }

 @override
 bool shouldRepaint(CirclePainter oldDelegate) => false;
}

The tradeoff is that you're now responsible for the details Flutter's built-in widgets normally handle for you, hit testing, accessibility semantics, correct repaint scheduling through shouldRepaint. It's a real tool, but it's usually the last resort after checking whether an existing widget or a combination of ShaderMask, ClipPath, or Container decoration already gets you there.

go_router maps URL-shaped paths directly to screens, which means a deep link or a web URL is parsed into the exact same navigation state the app produces internally by tapping through the UI, instead of needing separate logic to reconstruct a stack from a cold-start URL. It also integrates with the browser's back button and address bar correctly on Flutter web, since it's built on Navigator 2.0's declarative model rather than an imperative push/pop stack.

final router = GoRouter(routes: [
 GoRoute(path: '/', builder: (context, state) => const HomeScreen()),
 GoRoute(
  path: '/product/:id',
  builder: (context, state) => ProductScreen(id: state.pathParameters['id']!),
 ),
]);

context.go('/product/42'); // also matches a real incoming deep link to /product/42

On Android, deep links need an intent-filter declared in AndroidManifest.xml for the scheme or a verified App Link domain. On iOS, it's a Universal Link association through an apple-app-site-association file hosted on your domain, plus an entitlement in the app. Flutter itself, through a router package like go_router, then just needs the incoming URI parsed into the right route once the OS hands it to the app.

<!-- AndroidManifest.xml, inside the launch activity -->
<intent-filter android:autoVerify="true">
 <action android:name="android.intent.action.VIEW" />
 <category android:name="android.intent.category.DEFAULT" />
 <category android:name="android.intent.category.BROWSABLE" />
 <data android:scheme="https" android:host="example.com" android:pathPrefix="/product" />
</intent-filter>

The Flutter-side routing logic is usually the easy part. Getting the platform-level verification right, especially Universal Links needing a correctly served, unsigned, exact-format JSON file at a well-known path, is where most deep linking setups actually go wrong the first time.

A platform channel is Flutter's mechanism for asynchronous message passing between Dart code and the host platform's native code (Kotlin/Java on Android, Swift/Objective-C on iOS). Dart invokes a method by name with arguments, those get serialized (using a standard binary codec by default) and sent across the channel, native code on the other side receives the call, does whatever platform-specific work is needed, and sends a result back the same way.

static const platform = MethodChannel('com.example.app/battery');

Future<int> getBatteryLevel() async {
 final result = await platform.invokeMethod<int>('getBatteryLevel');
 return result ?? -1;
}

Every call crosses this boundary asynchronously, even if the native implementation itself is synchronous, because the message has to be serialized, sent across the engine's binary messenger, and deserialized on the other side. That round trip is why platform channel calls, however trivial, always return a Future, never a plain synchronous value.

MethodChannel is for one request, one response, call a native method, get a result back once. EventChannel is for a native side that needs to push a continuous stream of values to Dart over time without Dart asking again for each one, sensor readings, connectivity status changes, a native SDK's callback-based event stream.

static const EventChannel _channel = EventChannel('com.example.app/battery_stream');

Stream<int> get batteryLevelStream => _channel.receiveBroadcastStream().cast<int>();

Using MethodChannel to poll for something that's naturally a continuous stream, calling getBatteryLevel every second in a Timer, works but wastes battery and adds latency versus letting native code push updates the moment they happen through an EventChannel.

Jank is a dropped or delayed frame, visible as stutter, and it comes down to the total work for build, layout, paint, and compositing not finishing inside the time budget for one frame. At 60Hz that budget is roughly 16 milliseconds, at 120Hz, common on newer phones, it's roughly 8 milliseconds. Anything that pushes total frame work past that budget, an expensive build method, a huge synchronous computation on the UI isolate, an unnecessarily large repaint, causes the engine to miss showing a new frame in time, which reads to the user as a stutter or skipped frame.

// a classic UI-isolate-blocking mistake inside build:
final sorted = hugeList..sort((a, b) => expensiveCompare(a, b)); // runs every build

Watching a provider or a ChangeNotifier at a scope that's too broad. A widget high up in the tree calling context.watch on a value that only one small child actually displays causes that entire subtree to rebuild on every change, even the parts that never touch the changed data. Pushing the watch call down into the smallest widget that actually needs it, or wrapping just that piece in a Consumer or Selector, scopes the rebuild to only what changed.

// whole ProfileScreen rebuilds every time cart changes, even the unrelated avatar
Widget build(BuildContext context) {
 final cart = context.watch<CartModel>();
 return Column(children: [const Avatar(), Text('${cart.items.length}')]);
}

// only CartBadge rebuilds
Widget build(BuildContext context) {
 return Column(children: [const Avatar(), const CartBadge()]);
}
class CartBadge extends StatelessWidget {
 const CartBadge({super.key});
 @override
 Widget build(BuildContext context) {
  final cart = context.watch<CartModel>();
  return Text('${cart.items.length}');
 }
}

Flutter's ImageCache keeps decoded images in memory, keyed by their provider, so scrolling the same image back into view doesn't re-decode it from bytes every time. By default that cache holds up to 1000 images or 100MB of decoded (uncompressed) image data, whichever limit hits first, evicting least-recently-used entries past that.

The realistic failure mode is a screen that loads full-resolution photos, say 4000x3000 pixels each, into small thumbnail-sized widgets. The cache stores the fully decoded image at its full pixel dimensions regardless of the widget size it's displayed at, unless you explicitly pass cacheWidth or cacheHeight to tell the image provider to decode at a smaller size. A grid of thumbnails built this way can chew through hundreds of megabytes of memory for images that only ever render at 100x100 logical pixels on screen.

Depend on an abstract interface (an ApiClient or Repository class) rather than a concrete HTTP client directly, then swap in a fake or mocked implementation for tests, usually generated with the mockito or mocktail package. The Bloc or ViewModel under test never knows the difference between the real implementation and the mock, it just calls the interface's methods.

class MockUserRepository extends Mock implements UserRepository {}

test('emits loaded state on successful fetch', () {
 final repo = MockUserRepository();
 when(() => repo.fetchUser(any())).thenAnswer((_) async => testUser);

 final bloc = UserBloc(repo);
 bloc.add(LoadUser('1'));

 expectLater(bloc.stream, emits(UserLoaded(testUser)));
});

This only works cleanly if the dependency was designed as an injectable interface from the start. Retrofitting mockability onto a class that directly constructs and calls http.get inline usually means a refactor first, which is exactly the argument for structuring dependencies this way from day one instead of after the first flaky test appears.

In practice it's three layers with a strict dependency direction: a presentation layer (widgets, Blocs or ViewModels) that only knows about domain-layer interfaces, a domain layer (use cases, entities, repository interfaces) that has zero dependency on Flutter itself or on any specific data source, and a data layer (repository implementations, API clients, local database code) that implements the domain layer's interfaces.

// domain layer: no Flutter import, no http import
abstract class UserRepository {
 Future<User> fetchUser(String id);
}

// data layer: implements the interface, owns the actual API details
class UserRepositoryImpl implements UserRepository {
 final ApiClient client;
 UserRepositoryImpl(this.client);
 @override
 Future<User> fetchUser(String id) => client.get('/users/$id').then(User.fromJson);
}

The payoff is testability and swappability, the domain layer can be unit tested with zero mocking of Flutter or HTTP at all, and swapping a REST API client for GraphQL, or adding an offline cache, only touches the data layer. The honest cost is real boilerplate for a small app, which is why plenty of small, short-lived Flutter projects skip the full layering and just accept the tighter coupling.

get_it is a plain service locator, a global registry you look up dependencies from by type, independent of the widget tree entirely. Riverpod (or Provider) ties dependency lifetime to the widget tree, a provider is created and disposed as its position in the tree comes and goes.

// get_it: registered once at startup, looked up from anywhere, no BuildContext needed
final sl = GetIt.instance;
sl.registerLazySingleton<ApiClient>(() => ApiClient());
final client = sl<ApiClient>();

// Riverpod: tied to provider scope and the widget tree's lifecycle
final apiClientProvider = Provider((ref) => ApiClient());
final client = ref.watch(apiClientProvider);

get_it is convenient for singletons that genuinely live for the whole app's lifetime, an ApiClient, a logging service, and for code that needs a dependency outside the widget tree entirely, a background service, a plain Dart class. Riverpod earns its keep once you need a dependency's lifetime and rebuilds to actually track a specific part of the widget tree, or you want compile-time-safe overriding of a dependency in tests, which get_it's runtime registration doesn't give you as cleanly.

Sound null safety, the default since Dart 2.12, makes every type non-nullable unless explicitly marked otherwise, and the compiler enforces it statically, not just at runtime. A String can never be null, a String? can. The three operators handle three different situations: ? marks a type as nullable, ! asserts to the compiler that a nullable value is definitely non-null at this point (and throws at runtime if you're wrong), and late defers a non-nullable variable's initialization, promising the compiler it'll be set before first use even though it isn't set at declaration.

String? name; // nullable, can be null
String greeting = 'Hello, ${name!}'; // asserts name isn't null here, throws if it is

late String description; // not initialized yet, but will be non-null when read
void init() {
 description = fetchDescription(); // must run before description is ever read
}

Sound, as opposed to some languages' optional or "best effort" null checking, means the compiler can actually rely on the guarantee everywhere, which is what eliminated an entire category of NullPointerException-style crashes that used to be common in pre-null-safety Dart and Flutter code (Dart documentation, sound null safety).

Start with the Performance view in Flutter DevTools, running a profile build (not debug, debug mode has extra overhead that skews the numbers) and recording a timeline while reproducing the janky interaction. The timeline breaks down each frame into UI thread work versus raster thread work, which tells you immediately whether the bottleneck is Dart code (build/layout taking too long) or the GPU work (paint/compositing taking too long), since the fix for each is completely different.

From there, the widget rebuild tracking in DevTools shows exactly which widgets rebuilt on a given frame and how many times, which usually surfaces the actual culprit, a widget rebuilding on every frame of an unrelated animation because it wasn't wrapped in a const constructor or scoped with a Selector/Consumer correctly. Guessing at the fix before actually looking at the timeline is the single most common wasted hour in performance debugging.

These are the three trees Flutter maintains simultaneously, and confusing them is the single most common gap in intermediate candidates. A Widget is an immutable, lightweight configuration object, it describes what you want, it doesn't do any drawing itself and gets thrown away and recreated constantly. An Element is the actual instance that lives in the tree across frames, it holds the widget's current configuration and a reference to its RenderObject, and it's what Flutter diffs when a rebuild happens. A RenderObject is the thing that actually performs layout and painting, computing sizes, positions, and painting pixels.

// Widget: cheap, immutable, recreated every build
Text('hello');

// Element: persists across frames, holds state and links widget <-> render tree
// (you rarely touch this directly, but it's what setState triggers work against)

// RenderObject: does layout math and painting
// e.g. RenderParagraph actually lays out and paints the text glyphs

The reason this split exists: widgets are cheap to throw away every build, but Elements and RenderObjects are expensive to recreate, so Flutter reuses them whenever the widget type and key at a given tree position match. That's also the entire reason keys exist, they're the hint Flutter uses to decide whether an Element should be reused or torn down (Flutter architectural overview, docs.flutter.dev).

Keys tell Flutter's reconciliation algorithm whether to treat a widget at a given position as the same logical thing across rebuilds, or as something new that should get a fresh Element and RenderObject. Without a key, Flutter matches widgets to Elements purely by type and position in the list of children. That breaks the moment the order of a list changes, reordering, inserting, or removing an item can cause Flutter to reuse the wrong Element's State for a different logical item.

// without keys, deleting item at index 1 causes every widget after it
// to shift position, and each one gets matched to the wrong old State
ListView(
 children: items.map((item) => Dismissible(
  key: ValueKey(item.id), // ties the Element to the data, not the position
  onDismissed: (_) => remove(item),
  child: ItemTile(item: item),
 )).toList(),
)

The classic symptom is a stateful widget inside a reorderable or dismissible list, a TextField holding text, a checkbox holding checked state, showing the wrong data after an item above it is removed. A ValueKey tied to stable data (an id, not the index) fixes it.

Riverpod, from the same author as Provider, was built to remove Provider's dependency on BuildContext. Provider's context.watch and context.read only work inside the widget tree, which means you can't easily read or test a provider's value from outside a widget, and provider lookups can fail at runtime if you call them from the wrong context (above the provider in the tree, or during the wrong build phase) with an error that only surfaces when that code path runs.

final counterProvider = StateProvider<int>((ref) => 0);

class CounterText extends ConsumerWidget {
 @override
 Widget build(BuildContext context, WidgetRef ref) {
  final count = ref.watch(counterProvider); // compile-time safe, no context needed
  return Text('$count');
 }
}

Riverpod moves those lookups to compile time, ref.watch(counterProvider) fails to compile if counterProvider doesn't exist, instead of Provider's runtime "could not find provider above this widget" exception. It also makes providers trivially testable outside the widget tree entirely, since they're plain Dart objects, not tied to a BuildContext.

An isolate is Dart's unit of concurrency, its own independent worker with its own memory heap and its own event loop, that cannot access another isolate's memory directly. Communication between isolates happens only by passing messages through ports, values get copied (or, for some types, transferred) across the boundary rather than shared. That's fundamentally different from an OS thread, where multiple threads share the same heap and can read and write the same objects, which is exactly the source of data races.

Future<List<int>> heavyWork(List<int> input) async {
 return Isolate.run(() {
  return input.map((n) => n * n).toList(); // runs on a separate isolate
 });
}

The upside is that Dart code never needs locks or mutexes for isolate-to-isolate communication, since nothing is actually shared. The cost is that spinning up a new isolate and copying data across it isn't free, so it's the wrong tool for something quick, and the right tool for something genuinely CPU-bound (parsing a large file, image processing) that would otherwise stall the UI isolate's event loop (Dart documentation, concurrency in Dart).

Dart's event loop drains the microtask queue completely before moving on to the next event queue item. Futures created with then, and code resuming after an await, get scheduled as microtasks. Timer callbacks, I/O callbacks, and UI events go on the event queue, which is checked only once the microtask queue is empty.

void main() {
 Future(() => print('event queue'));    // scheduled via event queue
 Future.microtask(() => print('microtask')); // scheduled via microtask queue
 print('sync');
}
// output: sync, microtask, event queue

This matters in practice when you're debugging why one async callback consistently fires before another that looks like it should run first. The rule of thumb: everything chained off then or await on an already-created Future tends to resolve before anything scheduled with Timer or Future.delayed, even Duration.zero, because the former lives on the microtask queue and the latter doesn't.

Each frame, Flutter runs three phases in a strict order across the whole dirty tree before doing any of the next phase. Build runs first for every dirty Element, calling build() and updating the Element tree and, where needed, creating or reconfiguring RenderObjects. Layout runs second, walking the render tree depth-first, passing constraints down and sizes back up, for every RenderObject marked as needing layout. Paint runs last, walking the render tree again to record drawing instructions into layers, which then get composited by the engine and handed to the GPU.

// conceptually, one frame:
// 1. build()  -> Element tree updated
// 2. layout() -> RenderObject sizes and positions computed
// 3. paint()  -> drawing instructions recorded into layers, composited

The reason this ordering matters for debugging: calling something that needs a size (reading a RenderBox's size, say) during build, before layout has actually run for this frame, gets you stale or null data. That's why patterns needing post-layout information use addPostFrameCallback, to run code after all three phases finish for the current frame, not during build.

Navigator 1.0's imperative API, Navigator.push and Navigator.pop, works well for simple stack navigation but has no way to represent the navigation stack as a piece of state you can inspect, serialize, or restore, which becomes a real problem for deep linking and browser back-button behavior on Flutter web. Navigator 2.0 introduced a declarative model, the navigation stack is expressed as a list of Page objects derived from application state, and the Navigator diffs that list against its current stack rather than being told to push or pop imperatively.

// 1.0: imperative
Navigator.of(context).push(MaterialPageRoute(builder: (_) => DetailScreen(id)));

// 2.0-style: the page list is derived from state, Navigator reconciles it
Navigator(
 pages: [
  const MaterialPage(child: HomeScreen()),
  if (selectedId != null) MaterialPage(child: DetailScreen(selectedId!)),
 ],
 onPopPage: (route, result) => route.didPop(result),
)

Navigator 2.0's raw API is verbose enough that most teams don't hand-roll it, which is exactly why go_router exists, it's a declarative routing package built on top of Navigator 2.0's Pages API that gives you back a simpler surface for the common cases.

dart:ffi lets Dart call directly into a native C-compatible shared library (a.so,.dylib, or.dll) in the same process, without the serialization and async round trip a platform channel requires. It's the right tool when you need to call into an existing native library, a C or C++ codec, a cryptography library, and don't want the overhead of writing a full platform channel wrapper around every function, or when you need something genuinely synchronous and low-latency that a platform channel's async messaging model can't give you.

import 'dart:ffi';

typedef NativeAdd = Int32 Function(Int32 a, Int32 b);
typedef DartAdd = int Function(int a, int b);

final lib = DynamicLibrary.open('libmath.so');
final add = lib.lookupFunction<NativeAdd, DartAdd>('add');

print(add(2, 3)); // calls directly into native code, no channel round trip

The tradeoff is real complexity, you're now managing memory layout and pointer lifetimes across the Dart/native boundary by hand, and a mistake there is a native crash, not a caught Dart exception. Platform channels stay the right default for anything that's really about talking to a platform API (camera, notifications, native UI) rather than raw computation in an existing native library.

The Flutter engine is the C++ layer beneath the Dart framework that actually handles rendering, text layout, and platform embedding, it's what takes the layer tree produced by the paint phase and turns it into actual pixels on the GPU. For most of Flutter's history that renderer was Skia, a general-purpose 2D graphics library that compiles shaders lazily, the first time a given draw operation is encountered at runtime, which is the root cause of the visible frame hitch known as shader compilation jank.

Impeller is Flutter's newer rendering engine, built specifically to precompile shaders ahead of time instead of at runtime, eliminating that first-encounter jank. It became the default renderer on iOS starting with Flutter 3.10 and later became the default on Android as well as it matured (Flutter documentation, Impeller rendering engine). A candidate who's dealt with a real shader-jank bug on an older Skia-based release, usually the first time a particular blur or shadow effect appears on screen, tends to explain this one from actual scar tissue rather than reciting docs.

Opacity, unless the value is exactly 0 or 1, forces its child to render into an offscreen buffer first so the whole subtree can be composited with the transparency applied uniformly, rather than each individual widget inside it just being drawn semi-transparent directly. Animating an Opacity value on a complex subtree every frame means re-rendering that entire subtree to an offscreen buffer sixty (or more) times a second.

// expensive if child is complex and this animates every frame
Opacity(opacity: _controller.value, child: const ComplexCard());

// cheaper: paints directly with a pre-multiplied fade, no offscreen buffer per frame
FadeTransition(opacity: _controller, child: const ComplexCard());

FadeTransition achieves the same visual fade but applies it during compositing without forcing that offscreen render step, which is why Flutter's own animation widgets (FadeTransition, not raw AnimatedOpacity wrapping a heavy subtree) are usually the better default for anything that animates continuously rather than sitting at a fixed opacity.

Hot reload injects updated source code into the already-running Dart VM without restarting the app or losing its current state, then Flutter reassembles the widget tree using the new code, calling build again everywhere, but existing State objects and their fields survive. Hot restart destroys the current app state entirely and reruns main() from scratch on the still-running VM, faster than a full stop-and-relaunch since the VM and its compiled code stay warm, but state is gone just like a real cold start.

Hot reload can't handle every kind of change. New or changed static field initializers, changes to global variables that were already initialized, added or removed enum values, and changes to a State object's field type or generic type parameter often need a full restart to take effect, since reload only makes sense for the parts of the code the VM can safely patch into an already-running heap. That's exactly why "I changed the code but nothing happened" during a demo is usually a hot-reload limitation the candidate should recognize on sight, not a broken toolchain.