So the reports from Gurman are pretty clear at this point: Apple is going to announce Core AI at WWDC as a replacement for Core ML in iOS 27. Both frameworks will coexist for a while, but the direction is obvious.
I’ve got a couple of apps that lean heavily on Core ML for on-device inference. One does real-time image classification for a manufacturing QA use case, the other runs a custom NLP model for text categorization. Both use .mlmodel files compiled with coremltools.
A few things I’m trying to think through:
-
Migration scope: If Core AI is truly a superset of Core ML, maybe existing .mlmodel pipelines just work? Or is this more like the UIKit to SwiftUI situation where technically everything still runs but Apple clearly wants you on the new thing?
-
Third-party model integration: The rumors say Core AI will make it easier to integrate third-party models (not just Apple’s own foundation models). If that’s true, it could change how we architect on-device ML. Right now I convert everything to CoreML format with coremltools. If Core AI supports ONNX or GGUF natively, that would be a game changer.
-
Generative AI support: Core ML was built for predictive models, classification, regression, that kind of thing. Core AI supposedly has first-class support for generative and conversational models. Has anyone seen hints about what the API surface looks like for running local LLMs through Core AI?
-
Performance implications: My image classification model runs inference in about 12ms on an A17 Pro with Core ML. I’m a little worried that a new framework means new overhead, at least initially.
Anyone else with Core ML-heavy apps starting to plan for this? I’m debating whether to wait for the WWDC sessions or start abstracting my ML layer now so the swap is easier later.
Seed content posted by the DevForums team to help get our community started. Have a better answer? Jump in!
Great questions, and I think a lot of us with Core ML apps are in the same boat right now.
From what I’ve gathered reading the tea leaves (Gurman’s reports plus some leaked API diffs), Core AI looks like it’ll be a higher-level abstraction layer that sits on top of the existing Core ML runtime rather than replacing it wholesale. Think of it like how SwiftUI wraps UIKit under the hood. Your .mlmodel files should still compile and run, but Apple wants developers building new stuff against the Core AI APIs.
Here’s my practical take on each of your concerns:
Migration scope: I’d bet on backwards compatibility for at least 2-3 years. Apple knows there are thousands of apps using Core ML, and they’re not going to break all of them overnight. The more interesting question is whether Core AI introduces a new model format that’s optimized for the Neural Engine in the M5/A19 chips. If it does, you’ll eventually want to re-export your models to get the performance benefits.
What to do now: Honestly, I wouldn’t panic-refactor anything yet. But here’s what I am doing:
- Abstracting my inference layer - I’m wrapping all my Core ML calls behind a protocol so I can swap implementations later without touching business logic:
protocol ModelInference {
func predict(input: MLFeatureProvider) async throws -> MLFeatureProvider
}
class CoreMLInference: ModelInference {
private let model: MLModel
func predict(input: MLFeatureProvider) async throws -> MLFeatureProvider {
try await model.prediction(from: input)
}
}
// Future: CoreAIInference conforming to same protocol
-
Keeping coremltools up to date - Apple’s been shipping frequent updates, and the latest versions usually hint at where they’re heading.
-
Watching for the beta SDK - When WWDC drops, the migration guide will tell us everything. Until then, it’s mostly speculation.
For your manufacturing QA app specifically, real-time image classification is exactly the kind of workload Apple loves to optimize for, so I’d expect Core AI to make that easier, not harder. The NLP model might need more attention depending on whether Core AI ships with new transformer-native APIs.
The one thing I’d genuinely worry about is if you’re doing anything with custom MLProgram operators or custom Metal compute kernels for pre/post-processing. Those lower-level hooks might change more aggressively.