Introduction

A Flutter app cannot run arbitrary Dart code forever after the user or the OS has killed it. What you can do depends on the platform: Android may allow scheduled or background work through platform services such as WorkManager, while iOS is much stricter and supports only limited system-approved background modes.

Core Sections

Start with the platform reality

The phrase “after the app is killed” hides an important distinction:

• app in background but process still alive
• app process terminated by the system
• app force-closed by the user

These cases are not equivalent. A technique that works while the app is backgrounded may stop working entirely once the process is gone.

Android: use WorkManager for deferrable work

For Android, scheduled background work is usually implemented with WorkManager. In Flutter, the workmanager plugin is a common bridge.

1import 'package:workmanager/workmanager.dart';
2
3void callbackDispatcher() {
4  Workmanager().executeTask((task, inputData) async {
5    print('background task running');
6    return Future.value(true);
7  });
8}
9
10Future<void> main() async {
11  WidgetsFlutterBinding.ensureInitialized();
12  Workmanager().initialize(callbackDispatcher, isInDebugMode: true);
13  Workmanager().registerOneOffTask('sync-task', 'syncData');
14  runApp(const MyApp());
15}

This is appropriate for deferred sync or cleanup work, not for guaranteeing instant execution at an exact second under all conditions.

iOS: background execution is restricted

On iOS, there is no general “keep running after killed” permission for ordinary apps. You only get narrow system-approved modes, such as background fetch, location, audio, or push-triggered processing, and each comes with platform rules.

That means a feature that works on Android through WorkManager may need a completely different design on iOS, or may not be possible at all in the same way. This is why product requirements around “run after kill” should always be validated per platform before you promise identical behavior in a cross-platform Flutter codebase.

Use the right tool for the actual job

Different tasks require different mechanisms:

• scheduled notifications should use local notification APIs, not a custom long-running background loop
• periodic sync should use WorkManager or platform scheduling APIs
• location tracking needs the correct platform background mode and user permissions
• one-off server-triggered refresh may need push notifications or platform background fetch hooks

If you ask Flutter to “just keep a Dart isolate running after kill,” you are usually asking the wrong layer to solve an OS policy problem.

Design for eventual execution, not constant execution

Background task APIs are cooperative. The system decides when to run them based on battery, network, and app state. So your task must be idempotent and resilient to delay.

Good background design usually means:

• save enough state before the app is suspended
• make background work retry-safe
• tolerate delayed execution
• avoid assuming the process will stay alive continuously

That design survives platform scheduling better than trying to outsmart the lifecycle. It also makes debugging easier, because failures become retriable state transitions instead of mysterious process-lifetime assumptions.

Common Pitfalls

• Assuming Flutter itself can bypass Android or iOS lifecycle rules and keep running arbitrary Dart code after the process is killed.
• Building one background-task design and expecting it to behave identically on Android and iOS.
• Using a periodic background worker for jobs that should really be notifications, push handling, or OS-specific background modes.
• Forgetting that force-closed apps often lose background execution opportunities until the user opens them again.
• Writing background tasks as if they will run immediately and continuously rather than eventually and under system control.

Summary

• Flutter cannot guarantee arbitrary code execution after an app is killed; platform services control that behavior.
• On Android, WorkManager is the normal solution for deferrable background tasks.
• On iOS, post-termination work is much more restricted and tied to specific approved background modes.
• Choose the mechanism based on the job, not on the hope of keeping Dart alive indefinitely.
• Reliable background features are designed around delayed, system-scheduled execution.