Theory
The rebuild begins
Unit 1 perfected FestConnect Mobile: for Android alone. The secretary's iPhone still shows nothing.
The classic answer was a second team writing the app AGAIN in Apple's toolkit: double cost, drifting features.
Flutter is Google's refusal of that: ONE Dart codebase, compiled natively for both phones (and web and desktop). You learned Dart for this moment. First question worth real marks: how can one codebase possibly look right on 2 very different operating systems?
Theory
The answer: Flutter draws everything itself
Most cross-platform tools WRAP the native widgets: ask Android for its button, iOS for its own: and inherit every platform difference as a bug.
Flutter does something more radical: it does not use native widgets at all. The screen is a blank canvas, and Flutter's engine paints every pixel of every button, list and letter itself, via the Skia graphics engine.
Consequence: the app is IDENTICAL on both phones: same pixels, same behaviour: because the platform was never asked to draw anything.
At a glance
Flutter's 3-layer architecture
| Layer | Written in | Job |
|---|---|---|
| Framework | Dart | Widgets, Material/Cupertino libraries, layout and rendering logic: the layer YOU code against |
| Engine | C++ | Skia graphics (paints every pixel) + the Dart runtime |
| Embedder | Per platform | The native shell that hosts the engine on Android, iOS, etc. |
Theory
Features, and the project ritual
The feature list exams want: single codebase (Android + iOS + web + desktop), hot reload (a saved change appears in the RUNNING app in under a second: Dart's JIT, cashing its cheque), expressive widget-based UI (everything composed from widgets), and native performance (release builds are AOT machine code: the other half of the Dart bargain).
Project creation: install the Flutter SDK, run flutter doctor (it audits your setup and says what is missing), then Android Studio: New Flutter Project: or on the command line, flutter create fest_app.
Practical
lib/main.dart: the smallest FestConnect Flutter
import 'package:flutter/material.dart';
void main() {
runApp(const MaterialApp( // the app widget
home: Scaffold( // one screen's skeleton
body: Center( // an invisible arranger
child: Text('FestConnect Flutter'), // a visible widget
),
),
));
}
// flutter run (or the IDE's play button)
// Same pixels on Android AND on the secretary's iPhone.
Follow along
From nothing to running app
- Install the Flutter SDK Download from flutter.dev, extract, add its bin folder to PATH. Dart arrives bundled inside.
- Run: flutter doctor The setup auditor: it checks SDK, Android Studio, plugins, devices, and lists exactly what to fix.
- Android Studio: New Flutter Project Point it at the SDK path; it generates the project with lib/main.dart as the entry file.
- Run it: flutter run or the play button On an emulator or a cable-connected phone. Then edit the Text, save, and watch hot reload repaint in under a second.
Quiz
Why does a Flutter app look and behave IDENTICALLY on Android and iOS?
- Flutter translates your Dart into each platform's native Java and Swift widgets
- Flutter's engine paints every pixel itself via Skia, never using the platform's native widgets
- Google and Apple agreed on a shared widget standard
- It does not: Flutter apps look different per platform by design
Show the answer
Flutter's engine paints every pixel itself via Skia, never using the platform's native widgets
The engine-paints-everything design is Flutter's foundational bet: the OS supplies a blank surface and input events; Skia draws every button and letter, so there is nothing platform-specific to differ. Option A describes the wrapper approach of OTHER cross-platform tools: the strategy Flutter explicitly rejected, and the exam's favourite contrast. Option C invents diplomacy that never happened. Option D has a grain of nuance (Cupertino widgets EXIST for iOS-styled looks, opt-in) but as stated is false: identical rendering is the default and the point.
Think first
Hot reload: cash the Dart cheque
Unit 2 promised Dart's JIT would matter. Explain what happens between saving a change and seeing it in the running app, and why release builds do NOT carry this machinery, before tapping.
Show the answer
During development the app runs on Dart's JIT: on save, only the changed code is recompiled and injected into the RUNNING app, which rebuilds its widgets: state preserved, under a second: that is hot reload, and it transforms UI work into live sculpting. Release builds instead use AOT: everything pre-compiled to native ARM, no JIT machinery shipped: full speed, instant startup. One language, 2 compilers, each serving its moment: the exact story the Dart overview told, now visible on your own screen.
Watch out
Setup and concept traps
Skipping flutter doctor: half of all first-week Flutter agony is a missing plugin or licence the doctor would have named in line 1: run it first, obey it fully.
"Flutter compiles to native widgets": it compiles to native CODE but paints its OWN widgets: keep the 2 halves straight.
Editing outside lib/: your app lives in lib/main.dart and friends; the android/ and ios/ folders are the embedder's territory: generated, rarely touched.
Theory
One word will rule everything: widget
Look back at the listing: MaterialApp holds a Scaffold holds a Center holds a Text: a TREE of widgets, each configured through named parameters (Unit 2's passport, already paying). In Flutter, screens, layouts, padding, even the app itself: all widgets. The next lesson maps their family: visible vs invisible, stateless vs stateful, single-child vs multi-child: the classification the whole rest of the subject stands on.
Summary
Key takeaways
- Flutter: Google's open-source UI toolkit: one Dart codebase, natively compiled for Android, iOS, web, desktop.
- Architecture: Dart Framework (widgets, your layer) over C++ Engine (Skia + Dart runtime) over per-platform Embedder.
- Flutter paints every pixel itself: no native widgets wrapped: identical UI everywhere.
- Features: single codebase, hot reload (JIT), expressive widget UI, native AOT performance.
- Ritual: install SDK, flutter doctor, New Flutter Project, lib/main.dart, flutter run.
- main() calls runApp() with the root widget; the UI is a widget tree.
- Memory hook: one codebase, its own paintbrush, three layers deep.