docs/en/integrations/coreai.md
!!! warning "Core AI export is not yet available in Ultralytics"
Ultralytics does **not currently support** `format=coreai` or direct export to Apple's `.aimodel` format. For production deployment on Apple devices today, use the supported [Core ML integration](coreml.md). Core AI support is planned for Q4 2026, after iOS 27 and macOS 27 become generally available.
Core AI is Apple's new framework for running neural networks directly on Apple silicon. It introduces the .aimodel model format, a modern Swift inference API, PyTorch-based conversion tools, ahead-of-time compilation, model specialization, and dedicated debugging and profiling tools.
Apple describes Core AI as the next evolution of on-device AI execution and the inference framework behind on-device Apple Intelligence. It is designed for current neural network architectures, from compact vision models to large generative models, and can schedule work across the CPU, GPU, and Apple Neural Engine (ANE).
Core AI is a new deployment path rather than a new name for Core ML. The frameworks use different model formats, conversion tools, runtime APIs, and application-integration patterns.
| Capability | Core AI | Core ML |
|---|---|---|
| Model artifact | .aimodel | .mlpackage or .mlmodel |
| Ultralytics export | Planned | Available with format=coreml |
| Apple runtime API | AIModel, InferenceFunction, and NDArray | MLModel, often through VNCoreMLModel and VNCoreMLRequest |
| Conversion workflow | PyTorch torch.export through coreai-torch | TorchScript conversion through coremltools |
| Primary focus | Modern neural networks and generative AI | Broad machine learning deployment, including neural and non-neural models |
| Image integration | Applications prepare tensors or use Core AI image descriptors and buffers | Direct integration with the Vision framework for image scaling, orientation, and requests |
| Hardware | CPU, GPU, and Apple Neural Engine | CPU, GPU, and Apple Neural Engine |
| Model preparation | Specialization at installation or first use, with optional ahead-of-time compilation | Xcode or on-device model compilation |
| Custom operations | Custom Core AI lowerings and Metal kernels | Core ML custom layers and supported MIL operations |
| Deployment availability | New Apple operating-system generation; currently beta | Broad support across existing Apple operating systems |
| Ultralytics iOS and Flutter SDKs | Not yet supported | Fully supported |
Core ML remains the appropriate choice when an application needs broad device coverage, Vision framework integration, or model types such as decision trees and tabular pipelines. Apple continues to support Core ML and directs developers with non-neural model types to it.
The Core AI authoring workflow starts from a PyTorch model:
PyTorch model
↓ torch.export
ExportedProgram
↓ coreai-torch
Core AI program
↓ optimize and save
.aimodel
↓ specialize or compile ahead of time
Apple silicon executable
Apple's coreai-torch package converts a torch.export.ExportedProgram by lowering PyTorch ATen operations into Core AI operations. Unsupported operations can be implemented with a custom lowering or custom Metal kernel.
The resulting .aimodel is an unspecialized model asset. When an application prepares the model, Core AI specializes it for the target device. Applications can let this happen on first use, request specialization earlier, or ship an ahead-of-time compiled model to reduce initial loading time.
In Swift, applications load the asset with the Core AI framework, select an inference function, provide typed NDArray inputs, and receive named outputs. This is different from wrapping a Core ML model in a Vision request, so adopting Core AI requires an application runtime designed for .aimodel assets.
For implementation details, see Apple's documentation for AIModel, model specialization and caching, and ahead-of-time compilation.
!!! danger "Planned examples — these commands do not work yet"
The following examples illustrate the intended integration and are **not available in the current Ultralytics release**. Use [`format=coreml`](coreml.md#exporting-yolo26-models-to-coreml) for a supported Apple export today.
After the planned integration ships, the Python API is expected to export a YOLO26 model to .aimodel with a dedicated format value:
from ultralytics import YOLO
model = YOLO("yolo26n.pt")
model.export(format="coreai") # Planned: creates yolo26n.aimodel
The equivalent planned CLI command is:
yolo export model=yolo26n.pt format=coreai # Planned: not yet available
The final arguments, supported YOLO tasks, precision options, and dynamic-shape behavior will be documented in Export mode after the exporter is implemented and validated.
On iOS 27 or macOS 27, an application would then load and run the exported asset through Apple's Core AI Swift API. The function and tensor names below are illustrative; the supported Ultralytics output contract will be published with the exporter:
import CoreAI
let modelURL = Bundle.main.url(forResource: "yolo26n", withExtension: "aimodel")!
let model = try await AIModel(contentsOf: modelURL)
guard let function = try model.loadFunction(named: "main") else {
throw AppError.missingInferenceFunction
}
let outputs = try await function.run(inputs: ["image": imageTensor])
Unlike the current Core ML and Vision workflow, the future Core AI path will need to define image preprocessing, NDArray construction, model metadata, and output decoding in the Ultralytics iOS SDK. Apple provides current API details in the Core AI framework documentation and working model examples in the Core AI models repository.
Core AI offers several promising advantages for future Ultralytics deployment:
torch.export, preserving a more expressive PyTorch graph than the tracing workflow used by many existing exporters.These capabilities could be particularly useful for future YOLO models with dynamic execution, larger multimodal components, or custom operations that do not map cleanly to existing Core ML operations.
Core AI is not currently a replacement for the production Core ML path:
coreai-torch currently requires Python 3.11 or newer and recent PyTorch versions, which is much narrower than Ultralytics' supported Python and PyTorch range.yolo export format=coreai is not implemented, tested, or covered by Ultralytics' compatibility guarantees.MLModel and Vision..aimodel cannot be substituted for an .mlpackage; model loading, preprocessing, inference calls, metadata handling, and output decoding need a Core AI implementation.Use Core ML today when you need:
Evaluate Core AI in the future when you can require iOS 27 or macOS 27 and need:
Core ML and Core AI are expected to coexist while applications transition. Supporting Core AI does not immediately remove the need for Core ML because their deployment targets and application contracts differ.
Ultralytics plans to evaluate a dedicated coreai export target in Q4 2026, after iOS 27 and macOS 27 are generally available. The initial work is expected to focus on NMS-free YOLO26 models and the .aimodel format while retaining Core ML for established Apple deployment targets.
Before Core AI can become a supported export format, the integration needs:
Follow the Ultralytics roadmap and release notes for availability. Until support ships, commands or third-party patches that produce .aimodel files are experimental and outside the supported Ultralytics export matrix.
.aimodel today?No. Ultralytics currently supports Apple's Core ML .mlpackage format through model.export(format="coreml"). A native Core AI export target is planned but is not yet part of the supported exporter.
Not immediately. Core AI is Apple's newer path for modern neural networks, while Core ML remains supported and provides broader operating-system coverage, Vision integration, and non-neural model support.
.mlpackage to .aimodel?No. They contain different model representations and are loaded by different frameworks. Conversion must start from the source model through the appropriate Apple toolchain.
format=coreml?The initial integration is expected to coexist with Core ML. Any future replacement decision depends on operating-system adoption, stable tooling, performance, and downstream iOS and Flutter support.