# google_ml_kit_flutter: Google's ML Kit vision APIs as separate Flutter plugins > This repository is a set of Flutter plugins that wrap Google's standalone ML Kit, one pub package per vision capability. It suits teams that want on-device vision features without writing native Android and iOS code, and it comes with uneven platform coverage and a good share of beta features. **flutter-ml/google_ml_kit_flutter** — A flutter plugin that implements Google's standalone ML Kit - Repository: https://github.com/flutter-ml/google_ml_kit_flutter - Stars: 1,289 · Forks: 886 - Language: Dart - License: MIT - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/flutter-ml-google-ml-kit-flutter ## The problem this solves sits between Dart and two native SDKs Google's standalone ML Kit provides on-device vision capabilities such as barcode scanning, face detection and text recognition. Those capabilities ship as native Android and iOS components, and a Flutter application cannot call them directly from Dart. Something has to bridge the gap, and this repository is that bridge: a set of Flutter plugins that enable Flutter apps to use Google's standalone ML Kit. The audience is specific. A team with an existing Flutter codebase and a product requirement like scan a receipt or read printed text has three options. Write the platform integration twice, once in Kotlin and once in Swift, then expose it over platform channels. Ship a server and call it. Or add a plugin. The third option trades a small amount of control for the ability to keep the feature in Dart, and it is the option this repository exists to serve. Note what the description does not say. This is not a machine learning framework, and it is not a place to train or host models. It is a binding layer for an existing set of Google vision APIs, and the value it adds is entirely in the packaging, the Dart surface, and the fact that the same call works from a single codebase on both mobile platforms. ## The repository is a monorepo of independent pub packages The layout explains how the project is consumed. The top level holds a packages/ directory, and every capability lives in its own package rather than in one large library. Barcode scanning is published as google_mlkit_barcode_scanning, face detection as google_mlkit_face_detection, text recognition as google_mlkit_text_recognition, image labeling as google_mlkit_image_labeling, object detection and tracking as google_mlkit_object_detection, and digital ink recognition as google_mlkit_digital_ink_recognition. That split is a design decision with real consequences. You take only the dependencies your app actually calls, so a scanning-only feature does not drag face and pose detection into your build. Each package also has its own pub.dev page and its own release cadence, which means a version constraint on one plugin does not block you from taking a newer version of another. Other top level entries support the plugin collection rather than the runtime. There is a scripts/ directory, a resources/ directory, a .swiftlint.yml file for the Swift side of the iOS implementations, and a .metadata file, which is the marker Flutter uses for a plugin project. The default branch is develop, while the source code links in the support table point at the master branch, so both names appear in the project's own documentation. ## Android and iOS support is not the same for every plugin The feature table in the project description carries two platform columns, and they are not uniform. Barcode scanning, face detection, text recognition v2, image labeling, object detection and tracking, digital ink recognition and pose detection are all marked as supported on both Android and iOS. Two entries break the pattern. Face Mesh Detection is marked as Android only, so an iOS build of that feature is not covered by the table at all. Separately, a group of plugins carry a Beta label in their names: face mesh detection, pose detection, selfie segmentation as google_mlkit_selfie_segmentation, and subject segmentation as google_mlkit_subject_segmentation. The pattern is clear enough to plan around: four of the listed capabilities are marked beta on the upstream ML Kit side. For a team shipping to both stores, this table is the first thing to read, not the package list. The right question is not whether ML Kit supports face mesh on iOS in the abstract, but whether the specific plugin row you depend on has a checkmark in the iOS column. ## Adding one capability to a Flutter app The project description does not give a command to paste, so the practical path is the one it points at: each plugin has a pub.dev page, and you depend on the package named in the support table for the feature you want. Taking barcode scanning as the example, the package identifier you need is the one below, and the README links it to its pub.dev page, where the version constraint and the platform requirements for that plugin live. ```yaml google_mlkit_barcode_scanning ``` The reason the upstream docs handle the rest is that the setup is not identical across plugins. Native dependencies, minimum OS versions and the Android build configuration differ per package, so the pub.dev page for your chosen plugin is the place where those requirements are stated. Add one package rather than the whole collection, and let the first plugin you wire up be a deliberate choice of exactly which capability you need on device. For the first real use, the shortest sensible loop is: take the package from pub.dev, add it to your pubspec, then call the plugin from Dart and confirm the result on a physical device for each platform you ship. Emulators are not a substitute here, because these APIs are backed by native on-device components, and camera input on a simulator is a different path than on a handset. ## No GitHub releases, and a changelog instead This repository has no GitHub releases. That is a factual gap that affects how you track versions, and it is worth thinking about before you depend on it. In a repository with tagged releases, the release page is the place to see what changed, and a dependabot or renovate configuration can point at it. Here, the version history lives in the CHANGELOG.md file at the top level, and the actual published versions are the pub.dev package versions, each of which is tracked per package rather than for the collection as a whole. The consequence is that there is no single upgrade unit for the whole set of plugins. Upgrading barcode scanning does not move you to a new face detection version, and the CHANGELOG is a per package changelog in practice. For a team that wants a predictable, single point upgrade, that is a difference in operating cost compared with a monolithic dependency. The project itself is not parked. The repository is not archived, and the last push was on 2026-09-14. The .github/ and .githooks/ directories at the top level point to an active commit and review workflow, and the AUTHORS file records contributions. ## Where a plugin from this collection is the wrong tool Three cases stand out. The first is any feature that needs a consistent API on iOS and Android right now, because the face mesh detection row shows a plugin that does not offer that. Shipping a scanner on Android and nothing on iOS changes the shape of your product, and this collection will not close that gap for you. The second is a feature still marked Beta upstream. Pose detection, selfie segmentation, subject segmentation and face mesh detection carry that label, and a beta label on the underlying ML Kit API means the behaviour or the interface can still shift between plugin versions. That is a poor match for a release train with contractual commitments, and it is a poor match for an app that needs stable camera permissions or input handling across upgrades. The third is a project that needs a capability outside the vision set listed here, or needs custom models. The collection exists to bind Google's standalone ML Kit vision APIs. A team that needs its own trained model, or an API that the table does not list, has to look elsewhere. The alternative worth weighing is the honest one: build the integration natively and bridge it yourself. That is more work, in two languages, and it buys you exact control over the native surface, the ability to use capabilities the plugins have not wrapped, and no dependency on the upstream plugin maintenance cycle. ## Conclusion Adopt these plugins when the feature you need is on the Android and iOS rows of the support table and you would rather not maintain native bridges. Do not adopt a plugin marked Beta or the face mesh package for a shipped iOS product, and do not expect tagged releases, since the repository has none. Before committing, check the pub.dev page of the exact package you plan to depend on, because the table above already shows at least one capability that Android supports and iOS does not. ## FAQ ### How do I add Google ML Kit barcode scanning to a Flutter app? Depend on the google_mlkit_barcode_scanning package from pub.dev and follow the setup notes on that package page, since native requirements differ per plugin. The project description links each plugin to its own pub.dev page rather than giving a single installation command. ### Which google_ml_kit_flutter plugins are supported on iOS? Barcode scanning, face detection, text recognition v2, image labeling, object detection and tracking, digital ink recognition and pose detection are marked for both Android and iOS. Face mesh detection is marked for Android only. ### Does the google_ml_kit_flutter repository publish tagged releases? No. The repository has no GitHub releases, so version history is in the CHANGELOG.md file and in the per package pub.dev versions instead of in a single release page. ### What license does google_ml_kit_flutter use? The repository is published under the MIT license, with the LICENSE file at the top level of the repository. ## Sources - [flutter-ml/google_ml_kit_flutter on GitHub](https://github.com/flutter-ml/google_ml_kit_flutter) - [Issues](https://github.com/flutter-ml/google_ml_kit_flutter/issues) - [License: MIT](https://github.com/flutter-ml/google_ml_kit_flutter/blob/develop/LICENSE) - [README](https://github.com/flutter-ml/google_ml_kit_flutter/blob/develop/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/flutter-ml-google-ml-kit-flutter