Ultralytics YOLO Flutter: running YOLO models in a Flutter app on Android and iOS

What ultralytics_yolo solves, and who ends up using it

Flutter has no shared tensor runtime. A camera-based detector that works on both Android and iOS normally means a LiteRT path on Android, a Core ML path on iOS, and platform channel code to keep the two behaving the same. The plugin exists to remove that work. The README describes it as "the official plugin for running YOLO models in Flutter apps on iOS and Android", and exposes two entry points: YOLO for single-image inference and YOLOView for real-time camera inference. The intended audience is a Flutter developer who wants bounding boxes, masks, keypoints or depth values in Dart and does not want to own the native layer.

The task list is broad for a mobile plugin: detection, instance segmentation, semantic segmentation, monocular depth estimation, classification, pose and oriented bounding boxes. The README's feature table marks every one of those as supported on both platforms, with the single exception of Qualcomm NPU inference, which is Android only. If your app already routes camera frames through a custom native pipeline, the plugin's value drops sharply, because you would be replacing working code with a dependency that constrains how models are loaded.

Two APIs, metadata-first loading, and where the models actually live

The design splits cleanly. YOLOView owns the camera and streams results through an onResult callback. YOLO is the offline path: you construct it with a model path, call loadModel(), then predict(imageBytes). Both accept the same kind of model reference, which is the interesting part.

Model loading has three flows. The first is official model IDs: you pass a packaged identifier such as yolo26n and the plugin downloads the asset on first use and caches it in app storage, so the app package does not carry large model files. YOLO.officialModels() reports which official IDs are available on the current platform, and YOLO.defaultOfficialModel() returns a default. The second is custom models: LiteRT (TFLite) on Android, Core ML on iOS. The third is the Qualcomm path, described as opt-in Hexagon NPU inference for models named with a *_qnn.onnx suffix on Snapdragon devices.

The phrase the README repeats is metadata-first. Rather than you declaring the task, the plugin reads task metadata from the model and resolves it. That is why custom models are described as "metadata-first tasks". It is a real convenience and also a real constraint: an exported model without the expected metadata has nothing for the resolver to read. The README does not document what happens in that case, and it does not document rollback or fallback behaviour when a download fails. Official assets are published as GitHub release assets, with Android LiteRT w8a32 .tflite files tied to a specific release tag, which means the model set is versioned separately from the Dart package.

Installing ultralytics_yolo and running a first inference

The package is published on pub.dev. Add it to pubspec.yaml at the version the README shows, then resolve dependencies.

dependencies:
  ultralytics_yolo: ^0.6.14

flutter pub get

The quickest working path is the live camera view. The README's example resolves a default official model, falls back to the string 'yolo26n' if none is reported, and prints each result's class name and confidence.

import 'package:ultralytics_yolo/ultralytics_yolo.dart';

final modelId = YOLO.defaultOfficialModel() ?? 'yolo26n';

YOLOView(
  modelPath: modelId,
  onResult: (results) {
    for (final r in results) {
      debugPrint('${r.className}: ${r.confidence}');
    }
  },
)

On first run the model is fetched and cached, so expect a delay before results appear. For a still image, the README gives a three-step sequence: construct YOLO with a model path, await loadModel(), then await predict(imageBytes) and read the returned results. The repository points to doc/install.md and doc/quickstart.md for the fuller setup, and to the example/ directory for a complete app, which is the right place to look when the two snippets above are not enough.

The AGPL-3.0 licence is the first decision, not the last

The repository is licensed AGPL-3.0, and the LICENSE file sits at the top level. For a mobile app this is not a formality. AGPL-3.0 is a strong copyleft licence with a network-interaction clause, which is unusual territory for a client-side library, and it is a different licence from the permissive terms many Flutter packages use. If your organisation has a policy against AGPL dependencies, the evaluation ends here regardless of how well the API fits.

This is not legal advice; read LICENSE and your own distribution model together, and get counsel involved if the app is commercial. The practical point is that the licence question should be answered before you spend a sprint integrating the plugin, not after. Note also that the plugin is a wrapper around Ultralytics models rather than a general-purpose inference runtime, so the licence travels with the models you load as well as the Dart code.

Where the plugin stops: platforms, models, and NPU coverage

The support matrix is Android and iOS. The README lists no desktop, web or macOS target, and the repository layout reflects that: android/ and ios/ directories, an example app with example/android/ and example/ios/, and no desktop runner. If your Flutter project ships to Windows or the web, this plugin does not cover it.

Qualcomm NPU inference is Android only, and it is opt-in rather than automatic. You supply a model whose filename ends in *_qnn.onnx and you are on a Snapdragon device. On any other Android hardware, or on iOS, that path is not available, and the README does not describe what the plugin does when the accelerator is requested but absent. The README also does not document rollback for a failed model download, offline first-run behaviour, or the exact metadata keys a custom export must carry. Those are the questions to raise before you depend on a custom model in production.

One more boundary: this is an inference plugin, not a training or export tool. You still need a model produced elsewhere, whether an official ID or your own export in LiteRT or Core ML form.

Alternatives, and the difference that matters

The obvious alternative is tflite_flutter, which binds Flutter to the TensorFlow Lite (now LiteRT) interpreter rather than to YOLO. The difference is scope. tflite_flutter gives you tensors in and tensors out: you own preprocessing, letterboxing, decoding the output tensor into boxes, non-maximum suppression, and the label mapping. The Ultralytics plugin does that work for you and returns structured results with className and confidence fields, and it adds a Core ML path on iOS instead of pushing LiteRT onto both platforms.

The trade-off runs the other way too. tflite_flutter is not tied to one model family or one vendor's licence, so a non-YOLO model or a permissive-licence requirement is easier to satisfy. If your team already has a decoding pipeline it trusts, replacing it with the plugin's metadata-first resolver is a downgrade in control. If your team has never written that pipeline, the plugin removes weeks of work. Choose on which of those two sentences describes you.

Maintenance cadence and what upgrading costs you

The last push to the repository was on 2026-09-11, and the most recent release in the list is v0.6.14 from 2026-08-27, which reuses the UltralyticsYOLO label parser in iOS inspectModel. The two releases before it are close together: v0.6.13 on 2026-08-11 and v0.6.12 on 2026-08-11, the latter enabling multi-threaded LiteRT CPU inference. On that evidence the project is being changed regularly, and the changes are not cosmetic. A label parser fix on the iOS side and a threading change on the LiteRT side both touch inference behaviour, which is exactly the kind of release that can shift your output without an API change.

The upgrade cost has a second component the version number does not capture. Official model assets are published as GitHub release assets, and the README ties the Android LiteRT w8a32 .tflite files to a specific tag. So a plugin bump and a model asset bump are separate events, and a cached model on a user's device may outlive the plugin version that downloaded it. Pin the package version, and when you upgrade, re-check YOLO.officialModels() rather than assuming the previous ID set still applies.

Editorial conclusion

Adopt it if you ship a Flutter app on Android and iOS, want on-device inference with a single Dart API, and can live with AGPL-3.0. Do not adopt it if you need a permissive licence, a desktop or web target, or Qualcomm NPU inference on iOS, which the feature table marks as Android only. Before committing, check YOLO.officialModels() on both platforms, confirm your own exported model carries the metadata the plugin reads, and read LICENSE against your distribution model.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. ultralytics/yolo-flutter-app on GitHub