The YOLO Flutter plugin pins its model releases to v0.6.6 and v8.3.0

The model is not in your package, it is a pinned release asset

The plugin's central claim is metadata-first model loading, and the mechanism is worth understanding before you rely on it. Three model flows are supported: an official identifier that the plugin resolves, a custom model you supply, and a remote path. For the official route, the assets are not bundled. They live as release assets on two different repositories, with a pinned tag per platform, and the plugin downloads them on first use and caches them in app storage. The reason given is that the app package does not carry large model files, which is true and also means a first run needs network access. The tags are described as intentionally pinned so first-use downloads are reproducible, which is the right instinct and also creates the maintenance job: when the maintainers move a tag, your app is fetching a different artefact than the one the plugin was tested against unless you also move.

The Apple model line is versioned separately from the plugin

Look at the release table and the Android and Apple rows do not share a version. The Android runtime asset and the Android NPU asset both come from a plugin release tag in the six-series, while the Core ML asset comes from a separate iOS application repository at an eight-series tag. So the official models a Flutter app receives on Android and on iOS do not come from the same release, and neither of them comes from the current plugin tag, which is in the six-series. The plugin's own most recent releases are a bump to the six-series, a change reusing the label parser in the iOS model inspection path, and the addition of the opt-in Apple format. That means the model artefacts move on a different cadence from the code that loads them, which is fine for a vendor maintaining two products and is the thing to pin deliberately if you need identical behaviour across platforms.

Input resolution is fixed at 224 or 640, which is a real constraint

One sentence in the loading section does more to bound what you can build than any of the feature rows. Every mobile asset uses a fixed 224 by 224 classification input, or 640 by 640 for every other task. That is not a default you can override in the snippet you were shown; it describes what the shipped assets are exported at. So if your use case needs higher resolution for small distant objects, or a different aspect ratio handled natively, you are not choosing a model identifier, you are exporting your own and accepting that you now own the preprocessing as well. The seven supported tasks cover object detection, instance and semantic segmentation, monocular depth estimation, classification, pose, and oriented bounding boxes, and the feature table marks every one of them as supported on both platforms, which is the unusual part of this plugin rather than the resolution limit.

The Qualcomm NPU path is Android-only and opt-in

One row in the feature table breaks the pattern of dual-platform support. The Qualcomm NPU path is marked available on Android and not on iOS, and it is opt-in, applying to exported models with a specific naming pattern on Snapdragon hardware. Everything else in the table is a checkmark on both platforms, so the NPU row is the only place where the plugin is honest about a hardware gap. The rest of the accelerator story is handled by controls rather than by a separate API: the feature list mentions threshold controls, accelerator selection, and result streaming as the knobs, which means the same call site works whether you are on a neural accelerator, a graphics processor, or the CPU. The plugin ships no model conversion step of its own, so the export matrix in the model guide is the document that decides whether your model reaches the path you wanted.

The newest Apple format needs a future iOS and skips the simulator

The most recent feature is also the most constrained. An opt-in Apple format is supported, and it requires a future operating system version on the device. It is not available on earlier versions, and it is not available in the simulator. Three input shapes are accepted, a local path, a bundled asset, and a URL, and the opt-in is off by default, with the vendor's own iOS application exposing the same toggle. The documentation then does something worth imitating: it links to a performance record in the other repository for the trade-offs rather than asserting that the new path is better. For a Flutter developer this has a practical edge. If your team tests in the simulator, which most do, the newer format is code you will not exercise until you run on hardware, and the older format stays the default until you change it deliberately.

Task type comes from the model file rather than from your code

The design decision that makes this plugin pleasant to use is that you do not declare what a model does. You pass a path or an identifier, and the plugin resolves the task metadata from the model itself, which is what the metadata-first description means in practice. The result object is uniform across tasks, so the same result loop reads a class name and a confidence whether the model is doing detection, segmentation or pose. The consequence is a change in who owns a piece of information. In a typical pipeline the task type lives in your code, so swapping a detection model for a segmentation model is a code change. Here it lives in the artefact, so the swap is a string. That is the right default for a plugin whose selling point is dropping in an exported model, and it is also the thing to be careful with, because a model whose metadata does not match its graph will fail somewhere below the Dart layer.

Two entry points, and the difference is bytes versus a camera

The whole surface is two classes, and keeping them apart is what makes the package small. The single-image path takes bytes:

final yolo = YOLO(modelPath: 'yolo26n');
await yolo.loadModel();
final results = await yolo.predict(imageBytes);

That is the shape you want for a gallery pick, an upload, or a frame you already have. The other entry point is a widget that takes a model path and a result callback, and it owns the camera and the frame loop, which is the shape you want for a live view. The example uses the widget with a null-coalescing fallback to a named small model, which is a small thing that tells you the identifier lookup can return nothing and the plugin expects you to supply a default. Both platforms get the same result shape, and both are driven from the same Dart API, so a project that starts with single-image inference and adds a live view does not change its result handling.

Editorial conclusion

Use this plugin if you want YOLO on a phone without leaving Flutter, and plan for three things it does not hide. First, the model is not in your package. Every official identifier resolves to a download from a release asset, on a different repository and a different version line for each platform, so your app's first run needs the network and your build is not self-contained even though the plugin is. Second, the plugin is published under a copyleft licence, which matters more for a commercial mobile app than for most dependencies, so read it before you ship. Third, the newest Apple runtime format is gated on a future operating system version, is off by default, and does not run in the simulator, so if you are testing on the standard Apple development target the older format is the only one you will exercise. The most interesting design decision is the metadata-first loading, which means a task type is derived from the model file rather than declared in your code, so upgrading a model does not mean rewriting the call site. The last commit on the default branch main is dated 27 September 2026.

Frequently asked questions

Official sources

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