The Ultralytics YOLO iOS app and Swift package run seven vision tasks on device

Two deliverables in one repository

The repository holds two components for running YOLO models on Apple platforms, and they serve different purposes.

The first is the Ultralytics YOLO iOS App, the primary application, which allows easy real-time YOLO inference using the device camera or the image library. The shipped app bundles all seven official nano Core ML models, larger variants download on demand, and you can also test your own Core ML models, or the opt-in Core AI models on iOS 27 and later, by adding them to the app project.

The second is the Swift package, a lightweight library designed for iOS and iPadOS. It handles model loading, inference and postprocessing for YOLO models like YOLO26, and the README shows how small the surface is, a single call on a UIImage:

// Perform inference on a UIImage
let result = model(uiImage)

For a real-time camera case the package provides a camera view you drop into a SwiftUI body:

// Use the built-in camera view for real-time inference with a model bundled in your app
var body: some View {
    YOLOCamera(
        modelPathOrName: "yolo26n-seg",
        task: .segment,
        cameraPosition: .back
    )
    .ignoresSafeArea()
}

That is the difference between the two components in a sentence. The app is something you can install and try; the package is something you link into your own app.

Seven tasks, and what each one returns

The supported task list is given as a table, and the detail column tells you what you actually get back for each one.

Object detection returns bounding boxes, labels and confidence scores. Instance segmentation returns instance masks along with boxes and classes. Semantic segmentation returns dense per-pixel class maps, and depth estimation returns dense metric depth maps. Image classification returns top class predictions and scores. Pose estimation returns keypoints with boxes and confidence scores. Oriented bounding box detection returns rotated boxes and polygon corners, which is what you need for things like aerial imagery where a horizontal rectangle does not fit the object.

Seven tasks across one package is a lot of surface, and the reason it is feasible is that the underlying architecture is the same for all of them. A model is loaded, run on an image, and the raw output is postprocessed into the task's representation. The difference is in the head and in the postprocessing, and the package hides both behind the same call.

The models are YOLO11 and YOLO26. The README is specific about the difference between them: YOLO11 comes with Core ML NMS, while the YOLO26 models ship with nms=False for NMS-free inference, which means the model itself handles the suppression and the app does not need to. That distinction matters for latency and for the shape of the output you get back.

Core ML, the Neural Engine, and the Core AI option

The implementation is Swift and Core ML throughout, running on the Apple Neural Engine and the GPU, and the feature list states that there are no third-party dependencies, pure Swift on Apple first-party frameworks. For a package that ends up in an app binary, that is a meaningful property, because every dependency is one more thing to audit and one more thing to keep in step with the platform.

There is a second path now, and it is opt-in. Apple Core AI models, the .aimodel format, are supported on iOS 27 and later devices, while Core ML .mlpackage models remain the default. The release notes for version 8.9.15 describe it as an opt-in Apple Core AI backend for iOS 27 and later, so the default behaviour for an existing integration does not change, and the new backend is something you select.

The performance claim is camera-rate, around 30 frames per second on recent iPhones, and the README points to a performance document for on-device profiling rather than presenting the number as a general guarantee. That is the right way to treat such a figure, since the achievable rate depends on the model, the task and the device.

The user interface is native and follows Apple interface guidelines, which is a detail worth knowing if you plan to reuse the app's screens in your own project.

How the models get onto the device

The model distribution is the part of the project most likely to surprise you, and the README is unusually explicit about it.

Official models are GitHub release assets, not large files committed to the repositories. The main iOS app downloads the seven nano Core ML assets at build time and bundles them into the app, while the larger app models, the Swift package's YOLO(url:) loading, and the Flutter package assets download the official models on first use and cache them locally.

The build-time download is a specific mechanism. The main app bundles all seven nano models, one per task, including in App Store and archive builds, and they are fetched at build time by a Download YOLO Models Xcode build phase that runs scripts/download-models.sh. The .mlpackage files are never committed to the repository, since the pattern is gitignored. The step is idempotent and it is skipped on GitHub Actions CI, which runs the same script in its own step instead.

Two consequences follow. Anyone building the app needs network access to the release assets at build time, and anyone using the Swift package in an app that loads models by URL needs to handle a first-use download and the local cache. For a shipped product, that download behaviour is a real design decision, because a model that arrives on first use means the first run is not the first run.

What is in the repository

The top-level entries describe a project with three delivery targets. There is Package.swift for the Swift package, with the sources under Sources, tests under Tests, and an UltralyticsYOLO.podspec for CocoaPods, whose version badge is in the README. There is the YOLOiOSApp directory for the application, and an ExampleApps directory for further examples.

Alongside those are the operational pieces: a scripts directory holding the model download script, a docs directory with the performance document, a .github directory with the format and CI workflows and a codecov badge for coverage, and an AGENTS.md and CLAUDE.md for automated coding assistants working in the repository.

The presence of a podspec as well as Package.swift is a compatibility decision rather than an accident, since CocoaPods is still what a lot of existing iOS codebases use, and a package that drops it forces a migration on its users. The README also has a Simplified Chinese translation, and the project runs a Discord server, a community forum and a subreddit, which is the standard support surface for a project of this size.

Release notes that read like a changelog

The recent releases are more informative than the version numbers, because the tag names carry the change description.

Version 8.9.16, released on 2026-10-09, is titled as stretching depth inputs to match validation. Version 8.9.15, from 2026-09-20, added the opt-in Apple Core AI backend for iOS 27 and later. Version 8.9.14, from 2026-08-27, made the BasePredictor label parser public for SDK consumers.

All three are worth reading as signals about the direction of the project. The first is a numerical consistency fix in the depth path, which is the kind of change that matters when a metric output has to match a training pipeline's expectations. The second is a new execution backend on new hardware. The third is a widening of the public API for people embedding the package rather than using the app, and it is the one that says the package is being treated as a product with its own users rather than as a demo for the app.

The last push to the repository was on 2026-10-09, the same day as the latest release, and the repository is not archived.

Where this is the wrong choice

The first limit is the licence, and it is not a small one. The project is licensed under AGPL-3.0, which for a commercial app is a serious constraint, and the licence of the source does not change the fact that the model weights are distributed as release assets under their own terms. A team shipping a closed source iOS product has to resolve both before it starts.

The second is that the models are not in the source. The .mlpackage files are gitignored and fetched at build time, and the package downloads on first use. That keeps the repository small and is the right engineering choice, but it means a build depends on an external asset store, and a shipped app has a first-run download to design around.

The third is the platform. Everything here is Apple specific, Core ML on the Neural Engine and GPU, iOS and iPadOS. There is an Android app linked from the same README, and Flutter package assets are mentioned, but this repository is the iOS one, and a cross-platform product needs a different path for the other platforms.

The fourth is the version floor for the newer model format. The .aimodel backend needs iOS 27 and later, so if your deployment target is older, you are on the Core ML path and the newer models have to be exported in the older format.

The fifth is that the app and the package are the reference, not a product. The UI is there to demonstrate the capabilities, and if you need a different camera pipeline, a different result model or a different interaction, you are writing that code yourself and using the package for the inference and postprocessing.

Licence, App Store presence and who maintains it

The licence is AGPL-3.0, with the LICENSE file at the root of the repository. The homepage given for the project is the App Store listing for the Ultralytics YOLO app, and the same README links a Google Play listing, which reflects that the Android counterpart is a separate project.

The maintenance pattern is visible in the release cadence, with three releases in the two months from 2026-08-27 to 2026-10-09 and a push on the day of the latest one. The repository is not archived.

The project sits inside the wider Ultralytics ecosystem. The main YOLO repository is linked as the upstream, and the README points to the YOLO11 documentation and the YOLO26 platform pages, which is where the model formats and the export path are described. The channels for support are the Discord server, the community forum and the subreddit, and the README is written in English and Simplified Chinese.

For an adopter, the practical point is that this package is one layer of a stack that starts with a trained model elsewhere. What Ultralytics provides here is the iOS execution and postprocessing layer, and the model itself is something you export and then fetch as an asset.

Editorial conclusion

Ultralytics YOLO for iOS fits a team that wants to ship real-time vision on Apple hardware without writing the model plumbing, whether through the demo app or the Swift package in a SwiftUI app of its own, and it is a good reference for how Core ML inference and postprocessing are wrapped in a modern Swift interface. It is the wrong tool if you need the model itself to be open, since the weights are separate release assets rather than part of the source, and the wrong tool if you need to run outside Apple platforms. Before you adopt it, check three things: that the task you need is one of the seven listed, that you understand the model download model, since the package downloads official models on first use and caches them, and that the AGPL-3.0 licence is acceptable for your product, because it is the licence of both the app and the package. The current release is v8.9.16 from 2026-10-09 and the last push was on 2026-10-09.

Frequently asked questions

Official sources

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