# flutter-geolocator is six packages pretending to be one dependency > The geolocator plugin is split across an app-facing package, a platform interface and one endorsed implementation per platform, which is how Flutter keeps a cross-platform API independent of any vendor's location stack. It also means upgrading the plugin means upgrading several packages, and the repository contains a Linux implementation the README never mentions. **Baseflow/flutter-geolocator** — Android and iOS Geolocation plugin for Flutter - Repository: https://github.com/Baseflow/flutter-geolocator - Website: https://baseflow.com/ - Stars: 1,337 · Forks: 819 - Language: Dart - License: MIT - Published: 2026-10-17 · Updated: 2026-10-17 · Language: en - Canonical page: https://hysenlabs.com/projects/baseflow-flutter-geolocator ## What the federated split actually buys you The geolocator plugin is built following the federated plugin architecture, and the README links to the Flutter documentation explaining the concept. The short version is that the user-facing package does not contain platform code. It talks to an interface, and separate packages supply implementations. The six packages described are: 1. `geolocator`, the app-facing package you depend on in your project. 2. `geolocator_android`, the endorsed Android implementation of `geolocator_platform_interface`. 3. `geolocator_apple`, the endorsed iOS and macOS implementation. 4. `geolocator_web`, the endorsed web implementation. 5. `geolocator_windows`, the endorsed Windows implementation. 6. `geolocator_platform_interface`, which declares the interface all platform packages must implement. The word endorsed is doing work in that list. In the federated model, an endorsed implementation is one maintained as part of the endorsed set rather than by a single vendor, which is why geolocation on Android, Apple, web and Windows can be maintained by people who work on those platforms without anyone owning a geolocation business. The cost is that the pieces version separately. A dependency bump on `geolocator` can pull new versions of the platform packages with it, and a conflict between your app and a transitive platform package is a class of problem that does not exist with a monolithic plugin. ## The interface is the extension point The README describes `geolocator_platform_interface` as declaring the interface which all platform packages must implement to support the app-facing package, and points to instructions on how to implement a platform package in that package's own README. That is the whole escape hatch. If your organisation needs a location stack the endorsed implementations do not provide, or you need to route location through a proprietary SDK, the supported path is to write a package that implements the platform interface and register it, rather than forking `geolocator_android` and maintaining the fork. This is also the cost of the architecture when your requirement is unusual. The interface defines what every platform can express, so any capability that only one platform can provide has to be modelled in the common subset or handled outside the plugin. A location feature that is fundamentally different on Android and on iOS will not fit this shape without compromise. The repository layout is the concrete evidence for how the packages relate. Each package has its own directory at the root, each with its own README, and the root README links to all of them rather than repeating their content. Nothing about permissions, accuracy settings or platform-specific behaviour appears at the top level. If you are evaluating this plugin, the per-package READMEs are the documentation, not the root one. ## A Linux implementation the README does not mention The top-level directory listing contains a `geolocator_linux/` directory. The README's list of packages does not include it. The numbered list covers Android, Apple covering iOS and macOS, web, Windows, and the platform interface. Linux is absent from that enumeration even though a Linux package directory is present in the tree. There are a few possible explanations and the README does not say which applies. The Linux implementation might be a community package rather than an endorsed one, which would explain its absence from a list of endorsed implementations. It might be new enough that the README has not caught up. Or it might be present but not yet wired into the app-facing package's endorsed set. What matters practically is that the answer is not in the root README. If Linux is a target for you, and it often is for desktop Flutter, then the questions to answer before adopting are whether `geolocator` resolves a Linux implementation at all in the version you install, and whether that implementation is endorsed or community maintained, because those carry different maintenance expectations. The same caution applies in the other direction. The README's list is a description of endorsed packages at the time it was written, and the directory listing is the state of the repository. When they disagree, the repository is the more current of the two. ## Permissions are where the real work is None of that is visible in the root README, which is why the per-package links matter so much. Location access on Android and on Apple platforms is a permission model, not an API call, and each platform expresses it differently. On Apple platforms the question is whether the app requests when in use, always, or has background location enabled, and each of those implies a different plist configuration and a different review situation. On Android the split between foreground and background location has its own permission entries and its own runtime request flow. On web, location is gated behind browser permission and the secure context requirement. None of that is uniform, and none of it is this repository's README. The federated architecture makes that divergence a documentation problem rather than a code problem, which is a better problem to have. Each platform package documents its own permissions because each platform package owns them. There is also a design consequence worth noting. Because the app-facing package exposes a common API, the options you can pass are the intersection of what the platforms support, and the intersection is narrower than any single platform's capability. Reading the app-facing package's README alongside the platform package you actually target is the way to find out where you are going to hit that. The other practical point: geolocation on a device is a battery and privacy cost, and the plugin's API will not decide for you when to ask. That judgement stays with the application. ## Project status and where to look The project is licensed MIT, with a LICENSE file at the repository root, and it carries the standard governance files: `CONTRIBUTING.md`, `CODE_OF_CONDUCT.md` and a `.github/` directory. The last push was on 2026-10-13 and the repository is not archived. There are no GitHub releases, which is the normal arrangement for a federated Flutter plugin: releases are published to the package registry per package rather than as repository tags, and the root repository has no single version to release. There is a `.metadata` file at the root, which is what marks a directory as a Flutter plugin project and records the Flutter and Dart versions the project was created against. That file matters when the packages are separated: each subpackage has its own metadata, and a plugin repository with several packages has several Flutter version constraints to reconcile. The primary language is Dart, and the homepage is baseflow.com rather than a documentation site, so the published documentation for this plugin lives on the Flutter package documentation sites referenced from the individual package READMEs. The repository topics cover the usual surfaces for a geolocation plugin: android, ios, location, geo, flutter, dart, plus `flutter-plugin` and `geolocator-plugin` for discovery. For an engineer evaluating this, the practical checklist is short. Read the app-facing README for the API, read the platform package README for the permissions on the platforms you ship, confirm your target platforms are covered, and if any are not, find out which implementation fills the gap before you commit to the dependency. ## Conclusion Adopt the geolocator plugin if you need location across Flutter's supported platforms and want the platform code maintained alongside the ecosystem rather than inside your own project. Do not adopt it if you need a capability the platform implementations do not expose, since the federated design means your only extension point is the interface. Verify first which packages your target platforms actually pull in, since the repository ships a geolocator_linux directory that the README does not list among the endorsed implementations, and read the geolocator_android README for the permission model, which is where this plugin's complexity lives. ## FAQ ### What packages make up the Flutter geolocator plugin? Six: the app-facing geolocator package, the geolocator_platform_interface that declares the contract, and endorsed implementations for Android, Apple covering iOS and macOS, web and Windows. The repository also contains a geolocator_linux directory that the README does not list among the endorsed packages. ### What does it mean that the platform implementations are endorsed? In the federated plugin model an endorsed implementation is maintained as part of the endorsed set for that platform rather than by a single vendor. The practical effect is that geolocation support for each platform is maintained alongside the Flutter ecosystem. ### How do I add support for a platform the plugin does not cover? Write a package that implements geolocator_platform_interface. The README of that package contains instructions for implementing a platform package, which is the supported route rather than forking one of the endorsed implementations. ### Where do I find the permission requirements for Android and iOS? In the READMEs of the individual platform packages, geolocator_android and geolocator_apple. The root README links to each package README and does not repeat their permission models, since each platform package owns its own. ## Sources - [Baseflow/flutter-geolocator on GitHub](https://github.com/Baseflow/flutter-geolocator) - [Issues](https://github.com/Baseflow/flutter-geolocator/issues) - [License: MIT](https://github.com/Baseflow/flutter-geolocator/blob/main/LICENSE) - [Project website](https://baseflow.com/) - [README](https://github.com/Baseflow/flutter-geolocator/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/baseflow-flutter-geolocator