flutterlocation, one location API across six Flutter platforms

The one-line case, and what it actually covers

The pitch is that one simple API gives you GPS coordinates, live location streams and background tracking, and that the same code runs on Android, iOS, macOS, the web, Windows and Linux with no per-platform branching. The headline call is await location.getLocation(), and the live version is a subscription to onLocationChanged.

The permission dance in front of it is the part worth copying, because the order matters. You first check that the service is on, and if it is not you request it, and you bail out if either check fails. Then you request the permission and compare the result to PermissionStatus.granted, and bail out if it is not granted. Only then do you ask for a location.

import 'package:location/location.dart';

final location = Location();

// Make sure the service is on and permission is granted.
if (!await location.serviceEnabled() && !await location.requestService()) return;
if (await location.requestPermission() != PermissionStatus.granted) return;

// One-time fix…
final current = await location.getLocation();
print('${current.latitude}, ${current.longitude}');

// …or a live stream.
location.onLocationChanged.listen((loc) {
  print('Moved to ${loc.latitude}, ${loc.longitude}');
});

The data you get back is richer than a coordinate pair. The README lists latitude, longitude, altitude, speed, heading, accuracy and mock detection among the fields, and mock detection in particular is worth noting, because an app that trusts a mocked position for something important needs a way to know.

The tunability is the other half. You pick the accuracy, the update interval and the distance filter to balance precision against battery, and there is full control over the Android foreground service notification, which matters because that notification is what the user sees while your app is tracking them in the background, and an app that gets that wrong gets uninstalled.

The README claims the plugin is one of the most-used location plugins in the Flutter ecosystem, maintained since 2017. The licence is MIT with a 2017 copyright for Guillaume Bernos, who is listed as the original creator, with Bartek Pacia as a maintainer.

The support table, and the one row that is not full width

The platform support table is the most useful thing in the README, and one row is shorter than the others.

One-time location is supported on all six platforms. The location stream is supported on all six. Permission handling is supported on all six. Background updates are supported on Android and iOS, and the macOS, web, Windows and Linux cells are empty.

That is the honest boundary, and it follows from how the operating systems work rather than from a gap in the plugin. A background location stream needs a mechanism to keep the process alive and to be permitted to do so, and the mobile operating systems provide one with a user-visible indicator, while the desktop platforms and the browser do not offer an equivalent that a plugin could simply use.

The desktop implementations also have their own system requirements, and the README states them. Windows uses Windows.Devices.Geolocation, and Linux talks to GeoClue2 over D-Bus, and both require the system location service to be enabled. That is a real operational detail for a Linux desktop app, since GeoClue2 is a separate daemon that is often not running on a minimal distribution.

The web is handled by a separate published package, location_web, which is at version 7.0.0 while the main plugin is at 10.0.2. The version gap is worth noting because it tells you the web implementation is released on its own cycle, and the plugin's own releases are tagged per package: location-v10.0.2 from 2026-07-23 and location-v10.0.1 from 2026-07-22, with location_web-v7.0.0 on 2026-07-18.

The last push was on 2026-08-07 and the default branch is master.

Three packages, and why the interface is separate

The repository publishes three packages, and the split is the standard Flutter federated plugin arrangement rather than an arbitrary division.

The location package is the plugin you use in your app. The location_platform_interface package is the shared platform interface, which is the contract that the app-facing package talks to. The location_web package is the web implementation.

The reason for the platform interface is that it lets a third party provide their own implementation for a platform the maintainers do not cover, and it keeps the app-facing API stable while the underlying implementations change. The public API of the plugin is a Dart surface, and the platform interface is what the platform code implements, so a new platform can be added without the app-facing package changing.

The web implementation being its own package is a consequence of the web target working differently. The web has no native location service to bind to, it goes through the browser's geolocation API, and it is subject to the browser's own permission and context rules, which is why the browser implementation is versioned separately and why the web cell in the support table is narrower for background work.

The repository root shows the tooling that ties this together. There is a melos.yaml, which is the tool that manages a multi-package Dart repository, a root pubspec.yaml, a packages/ directory holding the three packages, a docs.json and a docs/ directory for the documentation site, and a .github/ directory for the workflows. There is a codecov badge in the README header, so the test coverage of the packages is tracked.

The documentation is split in a sensible way, with platform setup for permissions, background mode and sandbox entitlements in the package README at packages/location/README.md, and the full API on the documentation website at docs.page/Lyokone/flutterlocation, plus a live web demo hosted at lyokone.github.io/flutterlocation.

Getting the package in, and what the first run costs you

The dependency is added the standard way, with the location package at a caret on the 10.0 line:

dependencies:
  location: ^10.0.0

What the README calls the platform setup is the part that actually costs time on each platform, and the README is upfront that it is covered in the package README and the documentation site rather than in the quick start. Permissions are the obvious part, but the list also includes background mode and sandbox entitlements, which are the two that catch people.

Background mode is a configuration change per platform, and it is the change that makes the background row of the support table work. On Android it also means a foreground service, and therefore the notification that the plugin gives you control over. On iOS the sandbox entitlements matter, because a background location capability has to be declared and, in some cases, justified to the reviewer.

The web needs a secure context, which the browser requires for geolocation, so a web build served over plain HTTP will not get a position. The desktop platforms need the system service enabled, as the README notes for Windows and Linux.

The recommendation to check the settings before the first session is worth repeating in a different form here. On this plugin the analogue is to request the permission and the service explicitly before you call getLocation, rather than calling it and handling the failure afterwards, because the failure modes on the six platforms are different enough that a uniform error path is a lot of guesswork.

The project is community-maintained, and the README asks for help with issues and pull requests, pointing people at the open issues list to get started. For a plugin this old and this widely used, that is a healthy sign rather than a worrying one, since the alternative would be a plugin nobody maintains and everybody depends on.

Editorial conclusion

flutterlocation suits a Flutter team that wants geolocation without writing platform channels, since the same code runs on all six targets and the plugin has been maintained since 2017. It is the wrong choice if you need background tracking outside Android and iOS, because the support table shows that feature is unavailable on macOS, the web, Windows and Linux, and it is the wrong choice if you need a fused location provider with hardware-level guarantees, since this is a plugin that wraps the platform APIs rather than a full indoor positioning stack. Before adopting it, read the platform support table rather than the feature list, because the difference between a stream and a background stream is the difference this plugin most often gets asked about.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Lyokone/flutterlocation on GitHub
4. README
5. Releases