AOT vs JIT #

We’re often faced with a dilemma where an app development framework has a very fast development process but produces a sluggish final app, or the opposite — a high-performance final app but a slow, tedious code compilation process. Flutter manages to solve this dilemma cleverly. The secret behind Flutter’s development efficiency (Hot Reload) as well as its high-performance release builds lies in the flexibility of the Dart programming language, which supports a Dual Compiler system: JIT (Just-In-Time) and AOT (Ahead-Of-Time). We’ll break down the fundamentals of compilation, how JIT and AOT work, and how Flutter uses both at just the right moments.

The Basics of Source Code Compilation #

Before diving into the technical differences between JIT and AOT, you need to understand what happens when a program is compiled. The code you write in Dart is a high-level programming language designed to be easy for humans to read and write. A device’s CPU doesn’t understand Dart code directly. The CPU only understands low-level instructions in the form of Machine Code (binary machine code — a sequence of 0s and 1s) that is specific to each processor architecture (like ARM for smartphones or x64/ARM64 for desktop computers).

This translation process is shown in the simple diagram below:

flowchart LR
    DartCode["Dart Source Code (High-Level)"] --> Compiler["Compiler (Translator)"]
    Compiler --> MachineCode["Machine Code (CPU Binary Instructions)"]

    style Compiler stroke:#0288d1,stroke-width:2px

A compiler is the software responsible for translating high-level code into binary machine code. The fundamental difference between the JIT and AOT compilation strategies lies in when (which execution phase) the translation process happens.

JIT (Just-In-Time) Compilation: Compiling at Runtime #

JIT (Just-In-Time) is a compilation strategy where the translation of source code into machine code happens while the app is running (during runtime) — not beforehand. Code is translated “just in time,” only when that portion of code is about to be executed by the CPU.

How JIT Works #

When you run an app in JIT mode, its code execution flow follows the chart below:

flowchart TD
    Source["New Dart Source Code"] --> VM["Dart VM (Virtual Machine)"]
    VM --> JITComp["JIT Compiler (In Runtime)"]
    JITComp --> Profiler["Profiler (Observes Hotspots)"]
    Profiler -->|Dynamic Compilation & Optimization| Bin["Native Machine Code"]
    Bin --> CPU["Executed by CPU"]

    style JITComp stroke:#0288d1,stroke-width:2px
    style Profiler stroke:#0288d1,stroke-width:2px

In the JIT scheme:

1. The Dart VM (Virtual Machine) is loaded into the device’s memory to act as the app’s host.
2. Dart source code (or an intermediate representation in the form of kernel bytecode) is sent to the Dart VM.
3. While the app runs, the JIT Compiler dynamically translates those code chunks into binary machine code.
4. The Profiler component observes the running app to detect hotspots (the most frequently executed code paths, like large loops or animation functions). The profiler then instructs the compiler to recompile those sections with more aggressive optimizations to dynamically speed up runtime performance.

JIT’s Advantages in Flutter #

• Enables Hot Reload: Because compilation happens dynamically while the app runs, the JIT compiler can take the delta of new code changes (incremental code changes) and inject them instantly into the memory of the running Dart VM. The Dart VM then triggers a rebuild of the widget tree without discarding the app’s current memory state (state preservation). This process takes less than a second.
• Rich Debugging Capabilities: JIT compilation preserves all of the original source code metadata, like original variable names, file structure, and complete stack traces. This makes it very easy for developers to set breakpoints and trace code execution flow when hunting for bugs.

JIT’s Disadvantages #

• Slow Startup Time (Cold Start Warm-Up): When the app is first opened, there’s no ready-made machine code. The CPU has to wait for the JIT Compiler to do the initial compilation, causing the app to take a few seconds to show its first screen (startup delay).
• Memory and File Size Overhead: The app has to bundle the Dart VM and the JIT compiler in the installation package. This causes device RAM usage to balloon and the initial app file size to be much larger.
• Fluctuating Performance: For the first few moments after the app opens, performance can feel slightly janky because the JIT compiler is busy working in the background, compiling and optimizing code periodically.

💡 A Practical JIT Analogy Imagine you’re at an international seminar using a simultaneous interpreter. The interpreter translates the speaker’s words sentence-by-sentence directly into your ear as the speaker talks. If the speaker suddenly changes topic, the interpreter adjusts the translation on the spot.

AOT (Ahead-Of-Time) Compilation: Compiling Before Runtime #

AOT (Ahead-Of-Time) is a compilation strategy where the translation of all source code into binary machine code is done before the app runs, specifically during the app build process (build time). By the time users download and open your app, the code is already 100% native machine code ready for the CPU to execute directly.

How AOT Works #

The AOT compilation process runs on the developer’s computer using Flutter’s static compiler chain:

flowchart TD
    Source["All Dart Source Code"] --> AOT["AOT Compiler (At Build Time)"]
    AOT --> TFA["Type Flow Analysis (TFA)"]
    TFA --> TreeShaking["Tree Shaking (Dead Code Elimination)"]
    TreeShaking --> NativeBin["Native Binary (.so / .dylib)"]
    NativeBin --> CPU["Direct CPU Execution (No VM)"]

    style AOT stroke:#388e3c,stroke-width:2px
    style TreeShaking stroke:#388e3c,stroke-width:2px

During the AOT compilation phase:

1. Type Flow Analysis (TFA) runs to thoroughly examine the entire static function call tree in order to validate type safety.
2. Tree Shaking (Dead Code Elimination) is performed by the compiler to discard all functions, libraries, or classes that are never called in the app’s code. This ensures the final binary is clean of junk code.
3. The compiler reduces the code to pure native ARM or x64 machine code packaged in the form of a shared library file.
4. When run on the user’s device, the CPU directly executes that native binary without needing a runtime VM.

AOT’s Advantages #

• Instant Boot Time: Because the app is already pure machine code, there’s no warm-up compilation phase when the app opens. The app renders its first screen immediately.
• Consistent, Stutter-Free Performance: All layout optimizations, memory allocations, and function arrangements are locked in at build time. There’s no performance fluctuation from background compilation activity while the app runs.
• Efficient File Size & RAM Usage: The app doesn’t need to bundle the Dart runtime VM and JIT compiler. Tree shaking also ensures the app file size stays as small as possible and device memory (RAM) consumption stays very low.
• Better Code Security: Because the source code has been turned into pure binary machine instructions, reverse engineering to read the original code logic becomes far more difficult for malicious parties compared to dynamically interpreted code.

AOT’s Disadvantages #

• Loses the Hot Reload Feature: Because every code change requires re-triggering the entire static AOT compilation chain (including TFA and binary generation), you can’t do dynamic code injection. Every small change requires a full rebuild cycle.
• Long Build Times: The AOT compilation process demands heavy computing power for global optimization, so app build wait times are longer than JIT compilation.

💡 A Practical AOT Analogy Imagine a foreign novel that has been fully translated by a professional translator, edited by an editor, then printed and published as a physical book. When readers buy the novel, they immediately read a neat, consistent final translation from start to finish without waiting for any further translation process.

Flutter’s Dual Compiler System: The Best of Both Worlds #

Flutter’s main advantage lies in its decision not to choose one compilation system, but to combine JIT and AOT, alternating between them at different development phases.

The Dual Compiler system is applied based on the developer’s workflow phase:

flowchart TD
    subgraph Dev["1. Development Phase"]
        CmdDev["Command: flutter run"] --> Debug["Build Mode: Debug"]
        Debug --> JIT["JIT Compiler (Dart VM)"]
        JIT --> HR["Active Features: Hot Reload & Full Debugging"]
    end

    subgraph Prod["2. Production Phase (Distribution)"]
        CmdProd["Command: flutter build"] --> Release["Build Mode: Release"]
        Release --> AOT["AOT Compiler (Native Machine Code)"]
        AOT --> Perf["Active Features: High Performance & Instant Boot"]
    end

    style JIT stroke:#0288d1,stroke-width:2px
    style AOT stroke:#388e3c,stroke-width:2px

Flutter’s Three Main Build Modes #

To support this dual compiler system, Flutter divides the build process into three specific modes:

Running Build Modes via CLI #

You can switch between these build modes by passing the appropriate CLI parameters in the terminal:

# Run the app in Debug Mode (JIT by default)
flutter run

# Run the app in Profile Mode (AOT with profiling port active)
flutter run --profile

# Run the app in Release Mode (pure AOT)
flutter run --release

# Build a release binary for distribution to the Google Play Store
flutter build apk --release

# Build a release binary for distribution to the Apple App Store
flutter build ios --release

Special Web Platform Compilation (Web Compilation Pipeline) #

Because the web platform runs on browsers that natively only understand JavaScript and WebAssembly, the Dart team designed a special compilation pipeline to align the JIT and AOT systems on the web:

flowchart TD
    subgraph WebDev["1. Web Development"]
        SourceDev["Dart Code"] --> Devc["dartdevc Compiler"]
        Devc --> JSModular["Modular JavaScript (Fast Build)"]
        JSModular --> WebHR["Hot Reload & Live Debugging"]
    end

    subgraph WebProd["2. Web Release (Production)"]
        SourceProd["Dart Code"] --> TargetSelect{Target Choice?}
        TargetSelect -->|JavaScript| D2js["dart2js Compiler"]
        TargetSelect -->|WebAssembly| D2wasm["dart2wasm Compiler"]
        
        D2js --> JSMin["Optimized & Minified JS (Small Size)"]
        D2wasm --> WasmGC["WebAssembly GC Binary (Native Speed)"]
    end

    style Devc stroke:#0288d1,stroke-width:2px
    style D2js stroke:#388e3c,stroke-width:2px
    style D2wasm stroke:#f57c00,stroke-width:2px

• Web Development Path (dartdevc): The dartdevc (Dart Development Compiler) translates Dart code into lightweight JavaScript modules. This path is optimized for fast UI updates so the Hot Reload feature remains available in the browser during development.
• Web Production JavaScript Path (dart2js): The dart2js compiler performs aggressive optimizations, discarding unused code (tree shaking), doing minification (reducing variable names to single characters), and packaging everything into one optimized JavaScript file.
• WebAssembly Production Path (dart2wasm): This is the future of Flutter Web. This compiler translates Dart code directly into WebAssembly binaries that leverage the browser’s built-in Garbage Collection system (Wasm GC). This path completely bypasses the JavaScript interpretation layer, producing browser graphics rendering on par with native desktop app performance.

💡 Wasm Recommendation for Web WebAssembly-based compilation (dart2wasm) is highly recommended if your web app has lots of heavy interactive animation rendering. However, make sure your end users’ browsers already support the latest Wasm GC standard (supported by default in modern versions of Chrome, Firefox, and Safari).

Complete Comparison: JIT vs AOT #

Here’s a summary comparison matrix between JIT and AOT to make evaluation easier:

Summary #

• Two Compilers in One Language — Dart’s main uniqueness lies in its support for a Dual Compiler system (JIT and AOT) that works harmoniously, alternating as needed.
• JIT for Development — Just-In-Time compilation translates code at runtime, powering the instant Hot Reload feature (under one second) in Debug Mode.
• AOT for Production — Ahead-Of-Time compilation translates code into pure ARM/x64 machine binaries before the app runs, delivering high performance in Release Mode.
• Three Work Modes — Flutter divides its workflow into three modes: Debug (JIT), Profile (AOT + performance metadata), and Release (pure optimized AOT).
• Automatic Tree Shaking — The AOT build process automatically discards unused dead code to minimize release file size.
• Modular Web Path — Uses the dartdevc compiler for fast web development, plus dart2js and the modern dart2wasm (WebAssembly) compiler for maximum web release performance.

← Previous: Flutter’s Position in the Industry   Next: UI Framework →