# flutter_local_notifications: scheduling on-device notifications across five platforms

> MaikuB/flutter_local_notifications is a Flutter plugin for showing and scheduling local notifications on Android, iOS, macOS, Linux and Windows. It covers a lot of platform surface, and the platform-specific setup is where most integrations go wrong.

**MaikuB/flutter_local_notifications** — A Flutter plugin for displaying local notifications on Android, iOS, macOS, Linux and Windows

- Repository: https://github.com/MaikuB/flutter_local_notifications
- Stars: 2,666 · Forks: 1,560
- Language: Dart
- License: not declared
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/maikub-flutter-local-notifications

## What flutter_local_notifications actually solves

The plugin displays local notifications from a Flutter app. Local means the notification is created on the device by your own code, not delivered from a server. That distinction decides the whole use case: a medication reminder, a countdown timer that fires while the app is backgrounded, a daily digest you compute on the device, or an alert triggered by a background task all fit. A message pushed from your backend to a sleeping phone does not, because this plugin has no transport for that.

The intended audience is a Flutter developer who wants one Dart-facing API instead of writing notification code five times. The repository is a monorepo, and the README lists the packages it hosts: flutter_local_notifications for the cross-platform facing plugin, flutter_local_notifications_platform_interface for the common platform interface, plus flutter_local_notifications_linux, flutter_local_notifications_windows and flutter_local_notifications_web as the individual platform implementations. Most readers arrive for the first of those, and the README says as much: most developers are likely here as they are looking to use the flutter_local_notifications plugin. Each directory carries its own readme with more detail, which is where the platform setup lives.

## How the plugin is put together

The layout is a federated plugin. flutter_local_notifications is the app-facing package your Dart code imports. It delegates to flutter_local_notifications_platform_interface, which defines the contract every implementation must satisfy. The Linux, Windows and web implementations sit in their own packages so they can be versioned and released independently of the main plugin. Android, iOS and macOS are not listed as separate top-level directories, so their implementation code lives inside the main plugin package rather than beside it.

That structure explains a practical behaviour: a platform-specific fix can ship without forcing a release of every other platform, but it also means the app-facing API is only as complete as the weakest implementation. When a method behaves differently on Linux than on Android, the platform interface is the boundary where that difference is expressed. The repository uses melos.yaml, so the packages are managed and released together as a workspace even though they publish separately.

The practical consequence for you: read the readme of the platform you are actually shipping to, not just the top-level one. The top-level README is short and explicitly redirects you to the per-directory files and to the example app, which the README describes as providing detailed code samples for each supported feature.

## Installing flutter_local_notifications and showing a first notification

Add the plugin from pub.dev. The README points to the flutter_local_notifications package page, so the dependency name is the package name.

```bash
flutter pub add flutter_local_notifications
```

After that, the platform setup matters more than the Dart code. Android needs its own configuration, and iOS and macOS need permission handling before a notification can appear. The repository does not fold those steps into the top-level README; it sends you to the readme inside each package directory and to the example app. Treat those as required reading, not optional background.

The README gives no inline Dart snippet, so the honest first step is to open the example app rather than guess at the initialisation call. The README states that the example app provides detailed code samples for each supported feature, and that is the canonical reference for the API surface. Copying a snippet from a blog post instead is how people end up with a plugin that compiles but never shows anything.

If you want the platform pieces separately, they are published as their own packages. The Linux implementation is flutter_local_notifications_linux, the Windows implementation is flutter_local_notifications_windows, and the web implementation is flutter_local_notifications_web.

```bash
flutter pub add flutter_local_notifications_linux
```

You normally do not add those by hand. They are resolved as implementations of the platform interface, and adding them directly is only useful when you are pinning a specific implementation version.

## Where the plugin stops being the right tool

The first limitation is in the name. Local notifications are generated on the device. If your product needs a message to arrive when the app is not running and the content originates on your server, this plugin does not deliver it. You need a push service, and the plugin only becomes relevant again for the display side.

The second is coverage asymmetry. Android, iOS and macOS live in the main package, while Linux, Windows and web are separate packages with their own release cadence and their own readmes. A feature you rely on may be documented for one platform and absent or differently shaped on another. The top-level README does not claim feature parity across the five platforms, and the existence of separate implementation packages is a hint that parity is not automatic.

The third is that the repository is explicit about issue scope. The README asks that issues be limited to actual bugs or feature requests, and that you check the example app and the README before filing, particularly for platform-specific setup. That is a reasonable policy, but it also tells you the maintainer's time is the constraint. If your problem is a configuration mistake on your side, you will be redirected to the docs rather than walked through it.

Finally, the licence. The repository metadata gives no licence identifier, and the top-level README does not state one. Before shipping a commercial app, check the licence file in the package you depend on rather than assuming.

## flutter_local_notifications compared with a push service

The realistic alternative for many teams is a push notification service such as Firebase Cloud Messaging, which is also the pairing people search for. The difference is architectural, not cosmetic. A push service keeps a server-side channel to the device and delivers messages you send from your backend, which is what you need for chat, order updates or anything decided off-device. It also brings a dependency on that vendor, on device token management, and on the platform push infrastructure.

flutter_local_notifications has no server component at all. Nothing leaves the device to make a notification appear, which means no vendor account, no token lifecycle, and no network round trip. The trade-off is that the device must decide to notify, so anything that depends on fresh server data needs your app to fetch it first, typically through a background task.

If your app already uses a push service, the two are not competitors. The push service delivers the payload; this plugin is what you use when you want to present or schedule something locally. Teams that need both usually end up with the push SDK for transport and this plugin for the display and scheduling layer, and that combination is exactly what the related searches about pairing with Firebase messaging are reaching for.

## Maintenance, releases and upgrade cost

The repository is not archived, and the last push was on 2026-09-24. The most recent release listed is flutter_local_notifications-v23.0.0-dev.1, dated the same day, which is a pre-release. The last stable release before it is flutter_local_notifications-v22.3.1 from 2026-09-13, and before that flutter_local_notifications-v22.3.0 from 2026-08-08. The cadence is therefore steady, with patch releases between minor ones and a development line running ahead of stable.

For an adopter, the release pattern carries two costs. The first is that a dev tag exists in the release list, so if you pin loosely you can pull a pre-release you did not intend. Pin to a stable version in pubspec.yaml and upgrade deliberately. The second is the federated layout: the main plugin and the platform implementations version independently, so an upgrade can move the app-facing API and a platform package at the same time. Read the release notes for the version you are moving to before running flutter pub upgrade.

The licence question is unresolved in the metadata available. The repository metadata provides no licence identifier and the top-level README does not mention one. Check the licence file shipped with the package you depend on, and if you need legal certainty, ask someone qualified rather than inferring from the repository topics.

## Conclusion

Use flutter_local_notifications when notifications originate on the device itself: reminders, timers, scheduled alerts, or content you fetch yourself. Do not adopt it as a replacement for a push service, because it has no server transport and the README points to the example app and per-package readmes rather than to any delivery infrastructure. Before writing feature code, verify the Android channel and icon setup, the iOS and macOS permission request path, and the Linux and Windows implementations, since those ship as separate packages under this repository.

## FAQ

### How do I display notifications in Flutter with flutter_local_notifications?

Add the flutter_local_notifications package as a dependency, complete the platform-specific setup described in the readme for your target platform, then use the plugin's Dart API to show or schedule a notification. The README points to the example app for detailed code samples covering each supported feature.

### How do I use flutter_local_notifications?

Add the package to your Flutter project, follow the platform setup in the relevant readme, and refer to the example app in the repository for usage samples. The top-level README is deliberately short and directs developers to the per-package readmes and the example.

### What is a flutter_local_notifications alternative?

A push notification service is the usual alternative when notifications must originate from a server rather than the device. flutter_local_notifications has no server transport, so the two solve different problems and are often used together rather than swapped.

## Sources

- [Issues](https://github.com/MaikuB/flutter_local_notifications/issues)
- [MaikuB/flutter_local_notifications on GitHub](https://github.com/MaikuB/flutter_local_notifications)
- [README](https://github.com/MaikuB/flutter_local_notifications/blob/master/README.md)
- [Releases](https://github.com/MaikuB/flutter_local_notifications/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/maikub-flutter-local-notifications