Flutter, Dart & Cross-Platform Development — Flutter Course

What you'll learn

Flutter is a cross-platform UI toolkit built around a declarative widget framework and the Dart language. This lesson gives you the runtime and product mental models needed to choose Flutter deliberately and understand every tool you will use next.

By the end of this lesson, you'll be able to:

Explain the roles of Dart, the Flutter framework, engine, and platform embedder
Compare hot reload, hot restart, JIT development, and AOT release builds
Decide when shared Flutter code is a strong fit and where platform-specific work remains
Read a minimal Flutter program as a transformation from state into a widget tree

Core mental model

Connect each API to the decision it supports. Flutter code stays maintainable when state, ownership, lifecycle, and platform boundaries are explicit.

Concept	What it means	Decision rule
Declarative UI	The widget tree describes the interface for the current state	Change state and let Flutter rebuild the affected description
Layered runtime	Dart code uses the framework, engine, and a platform embedder	Locate a problem in the correct layer before choosing a fix
Build mode	Debug, profile, and release modes optimize for different work	Develop in debug, measure in profile, and validate delivery in release

Professional workflow

Work in small vertical slices and keep behavior observable from the first iteration.

Define the cross-platform product boundary: user goal, inputs, visible states, ownership, and expected failures.
Build the smallest working vertical slice with typed data and explicit dependencies.
Represent loading, empty, success, and failure behavior where the feature can encounter them.
Verify logic away from the UI, then exercise the rendered behavior at its public boundary.
Inspect lifecycle, accessibility, performance, security, and platform behavior before widening the feature.
Refactor only after behavior is protected by repeatable evidence.

Protect the frame

Keep build methods predictable, move side effects to explicit owners, and measure before introducing caches, isolates, or architectural layers.

Guided Flutter lab

Read the smallest useful Flutter app

The widget tree is an immutable description. MaterialApp supplies application-level behavior; Scaffold supplies a page structure; text is the visible leaf.

lib/main.dart

import 'package:flutter/material.dart';

void main() => runApp(const CourseApp());

class CourseApp extends StatelessWidget {
  const CourseApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      debugShowCheckedModeBanner: false,
      home: Scaffold(
        appBar: AppBar(title: const Text('Flutter Foundations')),
        body: const Center(
          child: Text('UI is a function of state'),
        ),
      ),
    );
  }
}

Make platform intent explicit

Flutter shares product logic and most UI, but capability checks keep unsupported behavior honest instead of pretending every target is identical.

lib/platform_message.dart

import 'package:flutter/foundation.dart';

String deliveryTarget() {
  if (kIsWeb) return 'Browser deployment';

  return switch (defaultTargetPlatform) {
    TargetPlatform.android || TargetPlatform.iOS => 'Mobile deployment',
    TargetPlatform.windows ||
    TargetPlatform.macOS ||
    TargetPlatform.linux => 'Desktop deployment',
    _ => 'Unsupported target',
  };
}

Production practice

Contract

Record target platforms, required native capabilities, expected input methods, and the minimum supported OS/browser versions.

Verification

Run one representative screen on every promised platform and keep device-specific behavior behind explicit adapters.

Operations

Use debug for iteration, profile for measurements, and release for final startup, size, signing, and distribution checks.

Common failure mode

“Write once” does not mean “ignore each platform.” A shared Dart codebase still needs platform-aware UX, manifests, permissions, signing, testing, and sometimes native integrations.

Independent workshop

Create a one-screen product brief and minimal Flutter shell for an app that should run on at least two target platforms.

Your finished workshop must include:

A target-platform matrix
A minimal const widget tree
One documented platform difference
A debug/profile/release verification checklist

Definition of done

Demonstrate the happy path, an empty or unavailable state, and at least one failure path. Add an automated check and a short note explaining one design decision.

Recap & quick check

Key takeaways

Declarative UI: Change state and let Flutter rebuild the affected description
Layered runtime: Locate a problem in the correct layer before choosing a fix
Build mode: Develop in debug, measure in profile, and validate delivery in release

Quick check

1. Which rule best applies to Declarative UI?

2. Which rule best applies to Layered runtime?

3. Which rule best applies to Build mode?

Next: Install Flutter, validate every dependency with flutter doctor, and run this shell on a real target.