Sept 16, 2025

Flutter safe area is a mess

Flutter safe area is a mess

When I started as an engineer, I imagined I’d spend my days tracking down sneaky memory leaks, optimizing performance to the microsecond, or solving deep algorithmic puzzles. But in reality? Most of the time, I’m fixing the same logic bugs over and over again. Not because I don’t know how to code—but because of misunderstood APIs, hidden side effects, and legacy decisions that won’t go away.

One of the best examples of this in Flutter: the safe area.

MediaQuery: at the beginning it is simple

At the foundation of Flutter’s widget tree lies the InheritedWidget. It’s a mechanism that allows data to “flow down” the widget tree, so any descendant can pick it up without you having to pass it manually through constructors.

MediaQuery is one of those inherited widgets. It exposes information about the current screen, like size, orientation… and safe area values.

Safe area? Think about notches, rounded corners, or system UI overlays (status bar, keyboard, navigation bar). MediaQuery tells you exactly how much padding you need to avoid drawing under them.

Here’s how you’d use it manually:

@override
Widget build(BuildContext context) {
  final padding = MediaQuery.paddingOf(context);
  return Padding(
    padding: EdgeInsets.only(
      top: padding.top,     // status bar / notch
      bottom: padding.bottom, // navigation bar
    ),
    child: Column(
      children: [
        Text('Top'),
        Spacer(),
        Text('Bottom'),
      ]
    ),
  );
}

And when the keyboard shows up? That’s when viewInsets comes in:

@override
Widget build(BuildContext context) {
  final viewInsets = MediaQuery.viewInsetsOf(context);
  return Padding(
    padding: EdgeInsets.only(bottom: viewInsets.bottom),
    child: Column(
      children: [
        Spacer(),
        Text('Bottom'),
      ]
    ),
  );
}
  • padding → space reserved for system UI (status bar, navigation bar).
  • viewInsets → space taken by things like the on-screen keyboard.

It’s clean, predictable, and honestly… a pretty great API. So where’s the mess?

SafeArea and Scaffold: good will, bad ending

The Flutter team wanted to make our lives easier. Instead of writing MediaQuery.paddingOf(context) everywhere, they introduced helper widgets like SafeArea.

With a single widget, you could wrap your content and—voilà—the padding was handled automatically.

@override
Widget build(BuildContext context) {
  return SafeArea(
    child: Text("Hello world"),
  );
}

Amazing! No need to sprinkle padding calculations all over the codebase.

But here’s the catch: SafeArea doesn’t just add padding—it also overrides the MediaQuery for its descendants. It assumes: “I’ve taken care of the safe area. You don’t need to worry about it anymore.”

That assumption… is wrong more often than you’d think.

Take this example with a scrollable list:

@override
Widget build(BuildContext context) {
  return SafeArea(
    child: ListView.builder(
      itemCount: 50,
      itemBuilder: (context, index) => ListTile(
        title: Text("Item $index"),
        onPressed: (){
          final padding = MediaQuery.paddingOf(context);
          // is zero here, because SafeArea replaced it!
        }
      ),
    ),
  );
}

Now, if you open a bottom sheet, the child list will not access the original padding —because SafeArea already replaced the MediaQuery. Suddenly you’re dealing with weird overlaps or cut-off content.

And then comes the Scaffold. It tries to be the “one-stop shop” for screen layouts:

@override
Widget build(BuildContext context) {
  return Scaffold(
    appBar: AppBar(title: Text("Chat")),
    body: TextField(),
    resizeToAvoidBottomInset: true, // tries to auto-resize
  );
}

The idea is to shift your UI up when the keyboard appears. Nice in theory… but in practice, this introduces another abstraction layer. It hides a SafeArea under the hood and you end up debugging:

  • Why does my ListView jump when the keyboard appears?
  • Why do I have double padding at the bottom?
  • Why does disabling resizeToAvoidBottomInset break something else?

When you strip it all down, most of this complexity could just be handled with two values from MediaQuery.

And then insert them where you actually need them. Nothing more.

So?

Sometimes, the simpler path is better—even if it means a bit more manual padding here and there. With a simple API, you know exactly what’s happening. There are no hidden overrides or “smart” defaults that come back to bite you.

That’s really the art of engineering: balancing abstraction with clarity. Too low-level, and everything is repetitive boilerplate. Too high-level, and you’re stuck fighting invisible side effects.

And with safe areas in Flutter? Well… let’s just say I’ve learned to double-check what’s really going on under the hood.

← Back to all articles