Flutter applications usually run Dart code on a single main isolate. For normal UI work, API calls, navigation, state management, and small calculations, this works perfectly well.

Problems begin when your application performs expensive CPU-bound work on the main isolate.

For example:

final result = performHeavyCalculation();

If performHeavyCalculation() takes hundreds of milliseconds, the main isolate cannot process UI work normally during that time.

The result can be:

• Frozen animations
• Delayed button interactions
• Janky scrolling
• Dropped frames
• Temporarily unresponsive UI

Dart solves this problem using isolates.

An isolate allows Dart code to perform work independently without blocking another isolate’s event loop.

In this guide, we will understand Dart isolates from the basics and then use them in practical Flutter examples.

---

What Is an Isolate in Dart?

An isolate is an independent Dart execution context with its own memory and event loop.

A typical Flutter application starts with a main isolate:

Flutter App
     ↓
Main Isolate
     ↓
UI + Dart Code

The main isolate handles work such as:

Widget builds
State updates
User interactions
Dart callbacks
Application logic

If you execute expensive synchronous work there, other Dart work on that isolate has to wait.

For CPU-intensive operations, you can move the work to another isolate:

Main Isolate
     │
     ├── UI
     ├── User Input
     └── Animations

Worker Isolate
     │
     └── Heavy Calculation

The UI can remain responsive while the worker performs the expensive computation.

---

Why Are Dart Isolates Needed?

Imagine your Flutter application calculates prime numbers.

int countPrimes(int max) {
  var count = 0;

  for (var number = 2; number <= max; number++) {
    var isPrime = true;

    for (var divisor = 2;
        divisor * divisor <= number;
        divisor++) {
      if (number % divisor == 0) {
        isPrime = false;
        break;
      }
    }

    if (isPrime) {
      count++;
    }
  }

  return count;
}

Now execute:

final result = countPrimes(500000);

This calculation may take noticeable CPU time depending on the device.

If executed directly from the main isolate:

Main Isolate
     ↓
Heavy Calculation
     ↓
UI work waits
     ↓
Possible jank

Instead, we can perform the calculation in another isolate:

Main Isolate               Worker Isolate

UI ──────────────────────► Heavy Calculation
│                                │
│                                │
Animations continue              │
│                                │
User interactions                │
│                                ↓
◄────────────────────────── Result

This is the primary reason isolates matter in Flutter performance work.

---

Isolates Are Not Threads

Developers coming from Java, Kotlin, C++, or other languages often compare isolates with threads.

They solve some similar concurrency problems, but they are not the same abstraction.

Traditional threads can share memory:

Thread A ─────┐
              ├── Shared Memory
Thread B ─────┘

That creates challenges such as:

Race conditions
Locks
Mutexes
Synchronization
Shared-state bugs

Dart isolates instead have separate memory:

Isolate A
   │
Own Memory


Isolate B
   │
Own Memory

They communicate by sending messages.

Conceptually:

Isolate A
   │
   │ Message
   ↓
Isolate B

This isolation significantly reduces the kinds of shared-memory concurrency bugs developers have to manage.

---

Every Isolate Has Its Own Memory

Suppose the main isolate has:

int counter = 10;

A worker isolate does not simply access and mutate that same variable.

Instead, information is transferred through isolate communication.

Think of it as:

Main Isolate

counter = 10

      │
      │ Send message
      ▼

Worker Isolate

Receives data

The worker performs its work independently and can send a result back.

---

Every Isolate Has Its Own Event Loop

Dart uses an event-driven execution model.

Each isolate has its own event loop.

Conceptually:

Isolate
   │
   ├── Event Queue
   │
   ├── Microtask Queue
   │
   └── Event Loop

Therefore, if the main isolate is performing a long synchronous CPU operation, its event loop cannot move on to other work until that operation finishes.

A worker isolate has a separate event loop, so it can perform independent computation.

---

Isolates vs async/await

This is one of the most important distinctions.

Many beginners assume:

async

automatically means:

Run this code on another thread or isolate.

It does not.

Consider:

Future<void> calculate() async {
  final result = heavyCalculation();

  print(result);
}

Even though the function is marked async, heavyCalculation() is still synchronous work.

If called on the main isolate, it executes there.

Therefore:

async/await
≠
New Isolate

---

What async/await Actually Helps With

async and await are especially useful for asynchronous operations where Dart can wait without continuously occupying the CPU.

Examples include:

await http.get(...);

await file.readAsString();

await database.query(...);

await Future.delayed(...);

Conceptually:

Start async operation
       ↓
Wait without blocking synchronous execution
       ↓
Other events can run
       ↓
Operation completes
       ↓
Continue

This is different from:

calculateMillionNumbers();

where the CPU is continuously executing Dart code.

---

CPU-Bound vs I/O-Bound Work

Understanding this distinction helps determine whether you need an isolate.

I/O-Bound Work

Examples:

HTTP requests
Database operations
Reading files asynchronously
Network communication
Waiting for timers

Usually:

async / await

is sufficient.

For example:

final response = await http.get(
  Uri.parse(apiUrl),
);

You normally do not create an isolate simply because you are making an HTTP request.

---

CPU-Bound Work

Examples include:

Large JSON parsing
Image processing
Data transformation
Encryption
Compression
Large sorting operations
Audio processing
Complex calculations
Large file parsing
Algorithm execution

These are stronger candidates for isolates.

Think of it as:

Waiting for something?
→ async/await

Heavy CPU calculation?
→ Consider an isolate

---

The Simplest Modern Approach: Isolate.run()

For one-off background computations, Isolate.run() is one of the easiest APIs to use.

Import:

import 'dart:isolate';

Then:

final result = await Isolate.run(() {
  return heavyCalculation();
});

Example:

int calculateSum() {
  var total = 0;

  for (var i = 0; i < 100000000; i++) {
    total += i;
  }

  return total;
}

Run it using:

final result = await Isolate.run(calculateSum);

print(result);

Conceptually:

Main Isolate
     │
     │ Start
     ▼
Worker Isolate
     │
     │ calculateSum()
     │
     ▼
   Result
     │
     ▼
Main Isolate

The heavy computation does not need to run on the main isolate.

---

Real Example: Heavy Calculation

Consider this Flutter screen:

class CalculationScreen extends StatefulWidget {
  const CalculationScreen({super.key});

  @override
  State<CalculationScreen> createState() =>
      _CalculationScreenState();
}

class _CalculationScreenState
    extends State<CalculationScreen> {
  int? result;
  bool loading = false;

  Future<void> calculate() async {
    setState(() {
      loading = true;
    });

    final value = await Isolate.run(() {
      var total = 0;

      for (var i = 0; i < 100000000; i++) {
        total += i;
      }

      return total;
    });

    if (!mounted) return;

    setState(() {
      result = value;
      loading = false;
    });
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: const Text('Isolate Example'),
      ),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: [
            if (loading)
              const CircularProgressIndicator(),

            if (result != null)
              Text(
                'Result: $result',
              ),

            const SizedBox(height: 20),

            ElevatedButton(
              onPressed: loading ? null : calculate,
              child: const Text('Calculate'),
            ),
          ],
        ),
      ),
    );
  }
}

The important part is:

final value = await Isolate.run(() {
  // Heavy CPU work
});

The main isolate can continue processing UI work while the calculation happens elsewhere.

---

Flutter compute()

Flutter also provides the convenient compute() helper.

Import:

import 'package:flutter/foundation.dart';

Then:

final result = await compute(
  heavyCalculation,
  input,
);

Example:

int calculateSquare(int value) {
  return value * value;
}

Use:

final result = await compute(
  calculateSquare,
  20,
);

print(result);

Output:

400

compute() is useful when you have a function that receives input, performs expensive work, and returns a result.

---

Isolate.run() vs compute()

Both can make one-off expensive work easier to move away from the main isolate on supported Flutter platforms.

For example:

final result = await Isolate.run(() {
  return processData(data);
});

Compared with:

final result = await compute(
  processData,
  data,
);

A simple mental model is:

Pure Dart code
→ Isolate.run()

Flutter application helper
→ compute()

For many Flutter applications, either can be appropriate for one-time computational tasks.

---

Real Example: Parsing Large JSON

Large JSON parsing is one of the most practical isolate use cases.

Imagine an API returns thousands of records.

final response = await http.get(url);

final data = jsonDecode(response.body);

The HTTP request itself is asynchronous.

However:

jsonDecode(response.body)

performs parsing work.

If the JSON payload is very large, parsing can consume enough CPU time to affect smooth UI performance.

---

Parsing JSON with compute()

Create a parsing function:

List<User> parseUsers(String jsonString) {
  final List<dynamic> decoded =
      jsonDecode(jsonString);

  return decoded
      .map(
        (json) => User.fromJson(json),
      )
      .toList();
}

Then:

final response = await http.get(url);

final users = await compute(
  parseUsers,
  response.body,
);

Now the flow becomes:

Main Isolate
     │
     │ HTTP Request
     ▼
Response
     │
     │ JSON String
     ▼
Worker Isolate
     │
     │ Decode JSON
     │ Create Models
     ▼
List<User>
     │
     ▼
Main Isolate

This can be valuable when parsing genuinely large payloads.

For small JSON responses, creating isolate work may add unnecessary overhead.

---

Complete JSON Parsing Example

Model:

class User {
  final int id;
  final String name;
  final String email;

  const User({
    required this.id,
    required this.name,
    required this.email,
  });

  factory User.fromJson(
    Map<String, dynamic> json,
  ) {
    return User(
      id: json['id'],
      name: json['name'],
      email: json['email'],
    );
  }
}

Parser:

List<User> parseUsers(String responseBody) {
  final decoded =
      jsonDecode(responseBody) as List<dynamic>;

  return decoded
      .map(
        (item) => User.fromJson(
          item as Map<String, dynamic>,
        ),
      )
      .toList();
}

API:

Future<List<User>> getUsers() async {
  final response = await http.get(
    Uri.parse(
      'https://example.com/users',
    ),
  );

  if (response.statusCode != 200) {
    throw Exception(
      'Failed to load users',
    );
  }

  return compute(
    parseUsers,
    response.body,
  );
}

This pattern keeps network waiting asynchronous while moving potentially expensive parsing work away from the UI isolate.

---

Real Example: Processing a Large List

Suppose you receive:

final numbers = List.generate(
  5000000,
  (index) => index,
);

Now you need to perform expensive processing.

List<int> processNumbers(
  List<int> numbers,
) {
  return numbers
      .where(
        (number) => number % 2 == 0,
      )
      .map(
        (number) => number * number,
      )
      .toList();
}

Instead of:

final result =
    processNumbers(numbers);

you could use:

final result = await Isolate.run(
  () => processNumbers(numbers),
);

For genuinely large CPU-intensive transformations, this can keep the UI responsive.

Remember that transferring large amounts of data between isolates also has a cost, so profiling is important.

---

Real Example: Searching a Large Dataset

Imagine an offline application containing hundreds of thousands of records.

A computationally expensive search could look like:

List<String> searchItems(
  List<String> items,
  String query,
) {
  final normalizedQuery =
      query.toLowerCase();

  return items.where((item) {
    return item
        .toLowerCase()
        .contains(normalizedQuery);
  }).toList();
}

You could execute it with:

final results = await Isolate.run(
  () => searchItems(
    items,
    query,
  ),
);

This becomes more valuable as processing complexity and dataset size increase.

For a list containing only a few dozen items, an isolate would usually be unnecessary.

---

When Isolate.run() Is Not Enough

Isolate.run() is excellent for:

Input
  ↓
Heavy Task
  ↓
Result

But some applications need a worker that stays alive.

For example:

Main Isolate
     │
     ├── Task 1 ──►
     ├── Task 2 ──► Worker
     ├── Task 3 ──►
     └── Task 4 ──►

Creating a new isolate for every operation can introduce overhead.

For long-running worker scenarios, you can use:

Isolate.spawn()

with ports for communication.

---

Isolate.spawn()

Basic syntax:

Isolate.spawn(
  workerFunction,
  message,
);

Example:

void worker(String message) {
  print(message);
}

Spawn:

await Isolate.spawn(
  worker,
  'Hello from main isolate',
);

The worker executes in another isolate.

However, real applications usually need communication in both directions.

For that, Dart provides:

SendPort
ReceivePort

---

What Is ReceivePort?

ReceivePort allows an isolate to receive messages.

Create one:

final receivePort = ReceivePort();

Listen:

receivePort.listen((message) {
  print(message);
});

---

What Is SendPort?

A SendPort allows another isolate to send messages to a corresponding receiving port.

Conceptually:

Isolate A
   │
SendPort
   │
   ▼
ReceivePort
   │
Isolate B

This message-based model is the foundation of communication between isolates.

---

Real Example Using Isolate.spawn()

Let’s calculate a large sum in another isolate.

Worker:

void calculateSum(SendPort sendPort) {
  var total = 0;

  for (var i = 0; i < 100000000; i++) {
    total += i;
  }

  sendPort.send(total);
}

Main isolate:

Future<void> startCalculation() async {
  final receivePort = ReceivePort();

  await Isolate.spawn(
    calculateSum,
    receivePort.sendPort,
  );

  final result = await receivePort.first;

  print('Result: $result');

  receivePort.close();
}

The communication looks like:

Main Isolate
      │
      │ SendPort
      ▼
Worker Isolate
      │
      │ Heavy Calculation
      ▼
    Result
      │
      │ send()
      ▼
Main ReceivePort

---

Two-Way Communication Between Isolates

Long-running workers often need two-way communication.

Conceptually:

Main Isolate                    Worker Isolate

ReceivePort                     ReceivePort
     ▲                               ▲
     │                               │
     │                               │
 SendPort ───────────────────────► SendPort
     ◄────────────────────────────

The main isolate sends tasks.

The worker processes them.

Then the worker sends results back.

---

Long-Running Worker Example

First define the worker:

void worker(SendPort mainSendPort) {
  final workerReceivePort =
      ReceivePort();

  mainSendPort.send(
    workerReceivePort.sendPort,
  );

  workerReceivePort.listen(
    (message) {
      if (message is Map<String, dynamic>) {
        final number =
            message['number'] as int;

        final replyPort =
            message['replyPort']
                as SendPort;

        final result =
            number * number;

        replyPort.send(result);
      }
    },
  );
}

Start it:

final mainReceivePort =
    ReceivePort();

await Isolate.spawn(
  worker,
  mainReceivePort.sendPort,
);

Receive the worker’s port:

final workerSendPort =
    await mainReceivePort.first
        as SendPort;

Now send a task:

final resultPort =
    ReceivePort();

workerSendPort.send({
  'number': 25,
  'replyPort':
      resultPort.sendPort,
});

Receive the result:

final result =
    await resultPort.first;

print(result);

Output:

625

This worker can remain alive and process additional tasks.

---

One-Off vs Long-Running Isolates

For one expensive task:

Isolate.run()
or
compute()

is usually simpler.

For repeated communication:

Isolate.spawn()
+
SendPort
+
ReceivePort

may be more appropriate.

Think of it as:

One heavy operation
→ Isolate.run() / compute()

Persistent worker
→ Isolate.spawn()

---

When Should You Use Dart Isolates?

Good candidates include computationally expensive operations such as:

Large JSON Parsing

jsonDecode(veryLargeResponse);

Image Processing

Examples:

Resize
Filters
Pixel manipulation
Encoding
Decoding-related CPU work

depending on the APIs being used.

Encryption and Cryptographic Computation

CPU-heavy encryption, hashing, or data transformations may be appropriate isolate workloads.

Compression

Large compression/decompression tasks can consume significant CPU resources.

Large Data Processing

For example:

500,000+ records
     ↓
Filter
     ↓
Transform
     ↓
Sort
     ↓
Aggregate

Complex Algorithms

Examples include:

Pathfinding
Large mathematical calculations
Data analysis
Simulation
Search algorithms

File Parsing

Reading a file asynchronously is I/O.

However, parsing a huge file after it has been read may be CPU-intensive.

For example:

Read File
→ async I/O

Parse 100 MB data
→ CPU work
→ possible isolate candidate

This distinction is important.

---

When You Should NOT Use Isolates

Isolates are not a universal performance solution.

Do not create an isolate for every function.

For example:

int add(int a, int b) {
  return a + b;
}

Running this in an isolate would be unnecessary.

The isolate setup and message-transfer overhead would likely cost far more than the calculation itself.

---

Do You Need an Isolate for API Calls?

Usually, no.

This:

final response =
    await http.get(url);

already uses asynchronous I/O.

Creating an isolate just for:

HTTP request

usually provides no meaningful benefit.

However:

HTTP request
      ↓
Huge JSON response
      ↓
Expensive parsing

is different.

The request can use normal async/await, while the expensive parsing may be moved to an isolate.

---

Do You Need an Isolate for Firebase?

Usually not for ordinary Firebase operations.

For example:

await FirebaseFirestore.instance
    .collection('users')
    .get();

is asynchronous.

Likewise, many Firebase SDK operations already handle their underlying platform/network work appropriately.

If you receive a very large amount of data and then perform expensive Dart-side processing, that processing may become an isolate candidate.

---

Isolates Have Overhead

Creating an isolate is not free.

Potential costs include:

Isolate startup
Message communication
Data transfer
Memory usage
Result transfer
Worker management

Therefore:

Small task
+
Isolate overhead
=
Potentially slower

while:

Large CPU task
+
Worker isolate
=
Potentially smoother UI

The goal is not necessarily to make the computation itself magically faster.

The main benefit is often keeping expensive CPU work away from the UI isolate.

---

Data Transfer Between Isolates

Because isolates do not share ordinary mutable memory, data must be communicated between them.

Simple data types are easy to send.

Examples include:

int
double
String
bool
null
Lists
Maps
SendPort

subject to Dart’s isolate message rules.

For large binary data, copying can become expensive.

Dart provides TransferableTypedData for efficiently transferring typed binary data between isolates.

---

TransferableTypedData

Suppose you have a large byte buffer.

Instead of repeatedly copying large binary structures, you can use:

TransferableTypedData.fromList([
  bytes,
]);

Then send it:

sendPort.send(
  TransferableTypedData.fromList([
    bytes,
  ]),
);

The receiving isolate can materialize it:

final byteData =
    transferableTypedData.materialize();

This is particularly useful for large binary workloads.

Potential scenarios include:

Image data
Audio data
Large binary files
Binary processing

---

Can an Isolate Directly Update Flutter UI?

No.

Your worker isolate should not directly manipulate the Flutter widget tree.

The typical pattern is:

Worker Isolate
      ↓
Calculate result
      ↓
Send result
      ↓
Main Isolate
      ↓
Update state
      ↓
Flutter rebuilds UI

For example:

final result = await Isolate.run(
  heavyCalculation,
);

if (!mounted) return;

setState(() {
  value = result;
});

The expensive computation occurs away from the main isolate.

The UI update happens back on the main isolate.

---

Error Handling with Isolate.run()

One advantage of high-level APIs is simpler error handling.

For example:

try {
  final result = await Isolate.run(() {
    return heavyCalculation();
  });

  print(result);
} catch (error) {
  print(
    'Calculation failed: $error',
  );
}

For manually spawned isolates, lifecycle and error handling can require additional work.

That is another reason to prefer higher-level APIs when you only need one-off computation.

---

Killing an Isolate

When using Isolate.spawn(), you may keep a reference to the isolate.

final isolate = await Isolate.spawn(
  worker,
  receivePort.sendPort,
);

Later:

isolate.kill(
  priority: Isolate.immediate,
);

This is useful when a long-running worker is no longer required.

For example:

Screen opened
    ↓
Start worker
    ↓
Process continuous tasks
    ↓
Screen destroyed
    ↓
Stop worker

Proper lifecycle management prevents unnecessary resource usage.

---

Closing ReceivePorts

When a ReceivePort is no longer needed, close it:

receivePort.close();

Forgetting to clean up long-running ports and workers can leave unnecessary resources alive.

Therefore, manage:

Isolate
ReceivePort
Subscriptions
Worker lifecycle

carefully.

---

Practical Flutter Architecture

Suppose your application has:

lib/
├── features/
│   └── products/
│       ├── controller/
│       │   └── product_controller.dart
│       ├── model/
│       │   └── product_model.dart
│       ├── screens/
│       │   └── product_screen.dart
│       ├── services/
│       │   └── product_service.dart
│       └── workers/
│           └── product_parser.dart
│
└── utils/

You can keep CPU-heavy parsing separate from UI code.

For example:

product_service.dart
→ Fetch API response

product_parser.dart
→ Parse/process large data

product_controller.dart
→ Manage application state

product_screen.dart
→ Display UI

This keeps isolate-related logic away from the screen itself.

---

Example Product Parser

List<Product> parseProducts(
  String responseBody,
) {
  final decoded =
      jsonDecode(responseBody)
          as List<dynamic>;

  return decoded
      .map(
        (item) =>
            Product.fromJson(item),
      )
      .toList();
}

Service:

Future<List<Product>>
    fetchProducts() async {
  final response =
      await http.get(
    Uri.parse(productsUrl),
  );

  if (response.statusCode != 200) {
    throw Exception(
      'Failed to fetch products',
    );
  }

  return compute(
    parseProducts,
    response.body,
  );
}

This separation keeps the architecture easier to maintain.

---

Isolates and Flutter Web

There is an important platform consideration.

Flutter’s isolate behavior is not identical across every target.

On native platforms, isolates can execute Dart code independently.

Flutter Web runs within browser constraints, and APIs such as compute() can have different execution characteristics compared with native platforms.

Therefore, if you are building performance-critical cross-platform functionality, test the actual behavior on every platform you support.

Do not assume:

Android performance
=
iOS performance
=
Web performance

---

Common Dart Isolate Mistakes

Mistake 1: Using an Isolate for Tiny Tasks

Bad:

await Isolate.run(() {
  return 10 + 20;
});

The operation is far too small to justify isolate overhead.

---

Mistake 2: Assuming async Means Background Execution

This:

Future<void> process() async {
  heavyCalculation();
}

does not automatically move heavyCalculation() away from the current isolate.

---

Mistake 3: Creating Too Many Isolates

Suppose you process 1,000 records.

Do not automatically create:

1 record
→ 1 isolate

1000 records
→ 1000 isolates

That can introduce significant startup, memory, scheduling, and communication overhead.

Batch work or use a persistent worker strategy when appropriate.

---

Mistake 4: Sending Huge Data Repeatedly

Communication between isolates has a cost.

This pattern:

Main
→ Huge data
→ Worker
→ Huge result
→ Main

may reduce the benefit of parallel execution if the task itself is relatively small.

---

Mistake 5: Forgetting Worker Lifecycle

When using manually managed isolates:

Isolate.spawn()

remember to manage:

ReceivePorts
Subscriptions
Errors
Shutdown
Isolate lifetime

---

Isolate.run() vs compute() vs Isolate.spawn()

API	Best Use Case	Complexity
Isolate.run()	One-off CPU-heavy Dart work	Low
compute()	One-off computation in Flutter	Low
Isolate.spawn()	Long-running or custom worker	Higher
SendPort / ReceivePort	Message communication	Higher
TransferableTypedData	Large binary transfers	Specialized

For most developers, start with the simplest solution that fits the problem.

---

How to Decide Whether You Need an Isolate

Ask the following questions.

Is the operation asynchronous I/O?

Examples:

API request
Database request
Network request
Async file read

Use:

async / await

An isolate is usually unnecessary.

Is the operation CPU-intensive?

Examples:

Huge JSON parsing
Image processing
Compression
Encryption
Large calculations
Large transformations

Consider:

Isolate.run()

or:

compute()

Does the worker need to stay alive?

Consider:

Isolate.spawn()

with ports.

A useful decision flow is:

Expensive operation
       ↓
Is it mostly waiting?
       │
   Yes ─────► async/await
       │
       No
       ↓
CPU intensive?
       │
   Yes ─────► Isolate
       │
       ↓
One-off task?
   │         │
  Yes        No
   │         │
   ▼         ▼
Isolate.run  Isolate.spawn
/ compute    + Ports

---

Do Isolates Make Everything Faster?

No.

This is an important misconception.

Suppose a calculation takes:

300 ms

on the main isolate.

Moving it to another isolate does not guarantee:

300 ms → 50 ms

The calculation may still require a similar amount of CPU time.

You may also introduce isolate setup and communication overhead.

The major advantage is:

Before

Main Isolate
     ↓
300 ms CPU task
     ↓
UI blocked


After

Main Isolate        Worker Isolate
     │                    │
UI continues          300 ms task
     │                    │
     ◄──── Result ────────┘

So the application’s responsiveness can improve even if the raw calculation itself is not dramatically faster.

---

Isolate Performance Best Practices

Use isolates for sufficiently expensive CPU work, not tiny functions.

Prefer:

Isolate.run()

for straightforward one-time computations.

Use:

compute()

when its Flutter-oriented convenience fits your use case.

Choose:

Isolate.spawn()

when you genuinely need a persistent worker or custom communication.

Keep messages reasonably small.

For large binary transfers, investigate:

TransferableTypedData

Most importantly, profile the application before and after adding isolate complexity.

---

Frequently Asked Questions

What is an isolate in Dart?

An isolate is an independent Dart execution context with its own memory and event loop. Isolates communicate through messages rather than sharing ordinary mutable state.

Does Flutter use isolates?

Flutter applications run Dart code in an isolate, commonly referred to as the main or UI isolate. Developers can create additional isolates for suitable workloads.

Does async/await create an isolate?

No.

async and await do not automatically create another isolate.

When should I use isolates?

Use them when CPU-intensive Dart work is blocking or likely to block the main isolate enough to affect application responsiveness.

Should API calls run in isolates?

Usually not. Network requests are normally handled using asynchronous I/O.

However, CPU-heavy processing of the returned data may be moved to another isolate.

Should JSON parsing use an isolate?

Small JSON responses generally do not need one.

Very large responses that cause measurable UI jank can benefit from background parsing.

What is the difference between compute() and Isolate.run()?

Both simplify one-off computation away from the main isolate in appropriate Flutter/Dart environments. compute() is a Flutter utility, while Isolate.run() comes from Dart’s isolate API.

What is Isolate.spawn() used for?

Isolate.spawn() gives you lower-level control and is useful when creating workers that need to stay alive or exchange multiple messages.

Can isolates share variables?

Isolates do not share ordinary mutable memory in the same way traditional threads do. They primarily communicate using messages.

Can a worker isolate update Flutter widgets?

No. Worker isolates should perform their computation and return results. UI state changes should happen through the Flutter application’s main UI execution context.

---

Final Thoughts

Dart isolates are powerful, but they should solve a specific problem: expensive synchronous CPU work blocking your application’s main isolate.

The easiest way to remember the difference is:

API / Network / Database
        ↓
    async/await


Heavy CPU Work
        ↓
 Isolate.run()
    or compute()


Persistent CPU Worker
        ↓
 Isolate.spawn()
        +
 SendPort / ReceivePort

For example, an API request itself usually does not need another isolate:

final response =
    await http.get(url);

However, if that response contains a huge JSON payload, expensive parsing may be moved away from the main isolate:

final users = await compute(
  parseUsers,
  response.body,
);

Likewise, heavy calculations can use:

final result = await Isolate.run(
  heavyCalculation,
);

For persistent processing, you can move to:

Isolate.spawn()

and communicate through:

SendPort
↕
ReceivePort

The key is not to use isolates everywhere.

First identify whether the work is I/O-bound or CPU-bound. If it is normal asynchronous I/O, use async/await. If expensive synchronous CPU work is causing measurable jank, consider moving that work to an isolate.

Then profile the application again.

Used this way, Dart isolates can help you build Flutter applications that remain responsive even while performing demanding data processing and calculations.