DEV Community: Gichira

Flutter Architecture Explained: What Every Beginner Needs to Know

Gichira — Tue, 16 Jun 2026 21:10:49 +0000

If you're just getting started with Flutter, you'll write your first widget within minutes. But somewhere around day three, you'll hit a wall — why does context crash here? Why did my whole screen rebuild when I changed one variable? Why does Flutter feel so different from React Native or SwiftUI?

The answer is architecture. Once you understand how Flutter actually works under the hood, everything else clicks into place. This is Part 1 of the Flutter From Zero series, and we're covering the foundations.

What Is Flutter — and Why Does It Exist?

Flutter is an open-source UI toolkit from Google that lets you build natively compiled apps for six platforms from a single Dart codebase: Android, iOS, Web, Windows, macOS, and Linux.

But here's what makes it different from every other cross-platform tool:

Flutter doesn't use native UI components. It draws its own UI using a custom rendering engine.

That's a big deal. Tools like React Native translate your code into native components — so a <Button> becomes an Android Button or an iOS UIButton. Flutter skips that entirely and paints pixels directly to the screen using its own engine (Skia or the newer Impeller). The result: pixel-perfect UI that looks identical on every platform, and no JavaScript bridge slowing things down.

Problem	Flutter's Solution
Separate iOS/Android codebases	One Dart codebase for all platforms
Bridge overhead (React Native)	No bridge — renders directly
Inconsistent UI per platform	Flutter draws its own widgets
Slow cross-platform performance	Compiles to native ARM machine code

Flutter 1.0 shipped in December 2018. By Flutter 3.x, it targets six platforms stably.

The 3 Layers of Flutter

Flutter's architecture is a three-layer sandwich. Each layer depends on the one below it. You work in the top layer and rarely touch the others — but knowing what they do changes how you debug and optimize.

┌──────────────────────────────────────────┐
│        FRAMEWORK LAYER  (Dart)           │
│  Material / Cupertino / Widgets / ...    │
├──────────────────────────────────────────┤
│          ENGINE LAYER  (C++)             │
│    Skia / Impeller / Dart Runtime        │
├──────────────────────────────────────────┤
│        EMBEDDER LAYER  (Platform)        │
│  Android / iOS / Windows / macOS ...     │
└──────────────────────────────────────────┘

1. Framework Layer (Dart)

This is where you spend 95% of your time. It's written entirely in Dart and contains everything you interact with: widgets, routing, theming, gestures, and animations.

The sub-layers stack like this, bottom to top:

Material / Cupertino    ← Design-system widgets (buttons, dialogs, etc.)
Widgets                 ← Core primitives (StatelessWidget, StatefulWidget)
Rendering               ← RenderObjects, layout, paint
Animation / Painting    ← Curves, tweens, Canvas API
Foundation              ← Utilities, diagnostics, change notifiers

2. Engine Layer (C++)

The engine is Flutter's heart. You never write C++, but this layer is doing the heavy lifting:

Skia / Impeller — renders pixels to the screen
Dart Runtime — runs your Dart code (AOT in release builds, JIT in debug)
Platform Channels — lets Dart talk to native code
Text Layout — handles fonts and text shaping

Quick note on Impeller: it's Flutter's newer renderer, designed to eliminate shader-compilation jank (that stutter you feel the first time a new animation runs). It's now the default on iOS and rolling out on Android.

3. Embedder Layer (Platform-specific)

The embedder is what makes Flutter runnable on a given OS. It's written in the host platform's language (Kotlin for Android, Swift for iOS, C++ for Desktop).

Its job: create a Flutter Engine instance, give it a surface to draw on, and feed it input events (touch, keyboard, mouse). Because this layer is separated out, Flutter can run on custom hardware — anyone can write a custom embedder.

The 3 Trees and the Rendering Pipeline

This is the part that trips up most beginners. Flutter manages three parallel trees to render your UI efficiently.

Your Code
    │
    ▼
┌─────────────┐
│ Widget Tree │  ← Immutable blueprints (cheap to create)
└──────┬──────┘
       │ inflate
       ▼
┌─────────────┐
│ Element Tree│  ← Mutable, long-lived (lifecycle manager)
└──────┬──────┘
       │ creates
       ▼
┌─────────────┐
│ Render Tree │  ← Does the actual layout and painting (expensive)
└─────────────┘

Widget Tree — Widgets are immutable Dart objects. Think of them as configuration blueprints. Every time build() runs, new widgets are created. This sounds wasteful, but widgets are intentionally cheap and lightweight.

Element Tree — Elements are long-lived and mutable. When Flutter first renders a widget, it creates an Element for it. That Element persists across rebuilds — it holds the connection between the widget (config) and the render object (output).

When you call setState(), Flutter marks the Element dirty and schedules a rebuild. It does NOT recreate the Element or RenderObject from scratch unless the widget type changes.

Render Tree — RenderObjects do the real work: computing sizes, calculating positions, and painting pixels. This tree is expensive to create, so Flutter reuses RenderObjects as aggressively as possible.

The Render Pipeline

Each frame goes through five stages:

Build → Layout → Paint → Composite → Rasterize

Build — build() is called on dirty widgets; new widget nodes are produced
Layout — RenderObjects compute sizes and positions using constraints
Paint — RenderObjects draw onto a Canvas
Composite — Layers are assembled into a scene
Rasterize — The GPU converts the scene to pixels on screen

Flutter targets 60fps (16.6ms per frame) or 120fps on capable hardware. The three-tree model is what makes that possible — only dirty parts of the tree get rebuilt, not the entire UI.

Project Structure

Running flutter create my_app produces this layout:

my_app/
├── lib/              ← Your Dart code lives here
│   └── main.dart     ← Entry point
├── android/          ← Android embedder + native code
├── ios/              ← iOS embedder + native code
├── web/              ← Web embedder
├── windows/
├── macos/
├── linux/
├── assets/           ← Images, fonts, JSON, etc.
├── test/             ← Unit and widget tests
└── pubspec.yaml      ← Project manifest

A recommended structure for real apps inside lib/:

lib/
├── main.dart
├── app.dart               ← Root widget + routing
├── features/              ← Feature-based folders
│   ├── home/
│   └── auth/
├── shared/                ← Reusable widgets, utils
└── data/                  ← Models, APIs, repositories

pubspec.yaml

This is your project's manifest — it declares dependencies, assets, and fonts:

name: my_app
version: 1.0.0+1

environment:
  sdk: ">=3.0.0 <4.0.0"

dependencies:
  flutter:
    sdk: flutter
  http: ^1.2.0

flutter:
  assets:
    - assets/images/
  fonts:
    - family: Poppins
      fonts:
        - asset: assets/fonts/Poppins-Regular.ttf
        - asset: assets/fonts/Poppins-Bold.ttf
          weight: 700

After any edit to pubspec.yaml, run:

flutter pub get

App Lifecycle

Flutter exposes lifecycle events via WidgetsBindingObserver. Understanding this is critical when you work with cameras, audio, network connections, or local storage.

The States

detached → inactive → resumed ↔ hidden / paused → detached

resumed — app is fully active in the foreground ✅
inactive — visible but not receiving input (e.g., incoming call overlay)
hidden — not visible but not suspended (added in Flutter 3.13)
paused — fully backgrounded / suspended
detached — engine alive, no view attached (startup or shutdown)

Listening to Lifecycle Events

class _MyScreenState extends State<MyScreen> with WidgetsBindingObserver {

  @override
  void initState() {
    super.initState();
    WidgetsBinding.instance.addObserver(this);
  }

  @override
  void dispose() {
    WidgetsBinding.instance.removeObserver(this); // ALWAYS unregister
    super.dispose();
  }

  @override
  void didChangeAppLifecycleState(AppLifecycleState state) {
    switch (state) {
      case AppLifecycleState.resumed:
        // Resume camera, refresh data
        break;
      case AppLifecycleState.paused:
        // Save state, release resources
        break;
      default:
        break;
    }
  }
}

BuildContext — The Part That Confuses Everyone

BuildContext is a handle to your widget's location in the Widget Tree. Under the hood, it's the Element itself.

@override
Widget build(BuildContext context) {
  final theme = Theme.of(context);          // walks UP the tree to find ThemeData
  final size = MediaQuery.of(context).size;
  return Container(color: theme.colorScheme.primary);
}

When you call Theme.of(context), Flutter walks up the Element Tree to find the nearest Theme ancestor. Your widget then subscribes to that theme — it rebuilds automatically when the theme changes.

The 4 Mistakes to Avoid

❌ Using context across an async gap

// WRONG
onPressed: () async {
  await Future.delayed(Duration(seconds: 2));
  Navigator.of(context).pop(); // context may be stale!
}

// CORRECT
onPressed: () async {
  await Future.delayed(Duration(seconds: 2));
  if (!mounted) return;          // guard check first
  Navigator.of(context).pop();
}

❌ Using context in initState()

// WRONG — widget isn't in the tree yet
@override
void initState() {
  super.initState();
  final theme = Theme.of(context); // CRASH
}

// CORRECT — use didChangeDependencies() instead
@override
void didChangeDependencies() {
  super.didChangeDependencies();
  final theme = Theme.of(context); // ✅
}

❌ Wrong context level for Scaffold

// CORRECT — use Builder to get a context below the Scaffold
return Scaffold(
  body: Builder(
    builder: (innerContext) {
      return ElevatedButton(
        onPressed: () {
          ScaffoldMessenger.of(innerContext).showSnackBar(...); // ✅
        },
      );
    },
  ),
);

❌ Storing context as a field

// WRONG — stored context goes stale after rebuilds or navigation
BuildContext? savedContext;

Quick Cheat Sheet

Flutter Architecture
│
├── 3 Layers
│   ├── Framework (Dart)   — what you write
│   ├── Engine (C++)       — renders, runs Dart
│   └── Embedder (Native)  — platform window/surface
│
├── 3 Trees
│   ├── Widget Tree        — immutable blueprints
│   ├── Element Tree       — mutable, manages lifecycle
│   └── Render Tree        — layout + paint (expensive)
│
├── Render Pipeline
│   Build → Layout → Paint → Composite → Rasterize
│
├── Lifecycle
│   detached → inactive → resumed ↔ paused/hidden
│
└── BuildContext Rules
    ✅ Use in build(), didChangeDependencies()
    ✅ Check mounted after async gaps
    ❌ Never in initState() directly
    ❌ Never store long-term

What's Next?

In Part 2, we'll dive into StatelessWidget vs StatefulWidget, when to use each, and how state actually flows through a Flutter app.

If this helped you, drop a ❤️ or leave a comment with questions — I read every one. Follow the Flutter From Zero series so you don't miss the next post.

Written for Flutter 3.x | Dart SDK 3.0+

`npm fund`

Gichira — Mon, 11 May 2026 23:06:37 +0000

166 packages are looking for funding
run `npm fund` for details

I remember when I first saw this message in my terminal, I completely misunderstood it.

I thought “packages looking for funding” was just another weird developer phrase that meant something highly technical underneath. Surely it couldn’t literally mean funding... right?

Turns out, it did.

It simply meant that the maintainers behind some of the open-source packages I was using had added sponsorship links so developers could support their work financially.

That’s it.

Now every time I see this message appear after an install, I quietly laugh to myself. It reminds me how easy it is, especially in tech, to overcomplicate simple things just because we assume everything has some deeper technical meaning behind it.

Sometimes the message really is just the message.

Automatic Windows Resync time after reboot: Auto Clock Sync with Dead CMOS and Battery.

Gichira — Wed, 12 Jun 2024 09:38:42 +0000

OPTION 1. Most viable solution 💯.

1. Open Task Scheduler:

Press Win + R to open the Run dialog.

Type taskschd.msc and press Enter.

2. Create a new task:

Click on "Actions" tab then click either "Create Basic Task..." or "Create Task".

3. Set up the task:

Name it something like "Time Sync on Startup".

Under the Triggers tab, click New then select when to begin the task as "At startup", and click OK.

For Action under the action tab, select "Start a program".

4. Specify program/script:

In the Program/script field, type w32tm. In Add arguments (optional), type /resync.

The final setup should look something like this:

Program/script: w32tmAdd arguments (optional): /resync

This tells Windows to use its built-in time synchronization command (w32tm /resync) whenever your laptop starts.

Click Finish or Ok depending on whether you selected to create a Basic task or a Task.

OPTION 2

Not a fully viable solution due to some access level restrictions.

Step 1: Create a PowerShell Script

Open Notepad or any text editor.
Copy and paste the following PowerShell script into the text editor:

# PowerShell script to sync system time with an internet time server
Try {
    Write-Output "Updating system time from time.windows.com..."

    # Start the Windows Time service if it is not running
    $service = Get-Service -Name w32time
    If ($service.Status -ne 'Running') {
        Start-Service -Name w32time
        Start-Sleep -Seconds 5  # Give the service time to start
    }

    # Update time using W32tm (Windows Time Service)
    w32tm /config /manualpeerlist:"time.windows.com" /syncfromflags:manual /reliable:YES /update
    Start-Sleep -Seconds 5  # Wait for a few seconds to ensure the configuration is updated
    w32tm /resync
    Write-Output "System time updated successfully."
} Catch {
    Write-Output "Failed to update system time."
    $_.Exception.Message
}

Save the file with a .ps1 extension, for example, UpdateTime.ps1.

Step 2: Create a Scheduled Task

Open Task Scheduler: Press Windows + R, type taskschd.msc, and press Enter.
Create a New Task: In the Task Scheduler, click Create Task in the Actions pane on the right.
General Tab:

Name your task, e.g., "Update System Time on Startup".
Choose "Run whether the user is logged on or not".
Check "Run with highest privileges".

Triggers Tab:
Click New to create a new trigger.
From the Begin the task dropdown menu, select "At startup".
Click OK to save the trigger.
Actions Tab:
Click _New _to create a new action.

From the Action dropdown menu, select "Start a program".

In the Program/script box, type powershell.exe.

In the Add arguments (optional) box, type the following (replace the path with the path to your script):

powershell
-File "C:\autoTimebyEd\UpdateTime.ps1"
Click OK to save the action.

Conditions Tab:
Uncheck "Start the task only if the computer is on AC power" if you want the task to run on battery power as well.
Settings Tab:
Check "Allow task to be run on demand".
Optionally, you can adjust other settings as needed.
Save the Task:
Click OK to save the task.
You may be prompted to enter your user account password.
Testing the Task
Run the Task Manually from the Task Scheduler:

In Task Scheduler, locate the task you created.
Right-click the task and select "Run".
Check if the system time updates correctly.

Restart Your Laptop:

Restart your laptop to ensure the script runs at startup and updates the time. Following these steps, your laptop should automatically fetch and update the system time from time.windows.com each time it powers on. This setup ensures your system clock is always accurate without requiring manual intervention.