A hands-on guide to taking a model you trained in Create ML and wiring it into an iOS app using Core ML — adding the file, using the generated Swift class, and running predictions.
Training a model in Create ML is only half the job. The other half is integrating it into an app so users benefit from it. That is what Core ML and Xcode handle.
The workflow is straightforward. Create ML exports a Core ML model file, you add it to Xcode, and Xcode generates a Swift class you call to make predictions.
Because inference runs on-device, your feature works offline, respects privacy, and avoids server costs. Core ML also picks efficient hardware — Neural Engine, GPU, or CPU — automatically.
This guide assumes you already have a Core ML model from Create ML. If not, train one first, then come back to wire it up.
Drag your Core ML model file into the Xcode project navigator. In the dialog, make sure Copy items if needed is checked and that the model is added to your app target.
Target membership is the detail people miss. If the model is not part of the target, the app will not include it and your code will fail to find it at build time.
Click the model in the navigator. Xcode shows a model overview — inputs, outputs, and metadata such as description — which is a useful sanity check that the right model arrived.
At this point Xcode has already generated a Swift interface for the model behind the scenes. You do not write that class yourself.
When you add a Core ML model, Xcode auto-generates a Swift class named after the model file. Choose descriptive export names in Create ML so this class reads well.
The generated class exposes an initializer plus prediction methods whose parameters match the model's inputs and outputs. For an image classifier, that means an image input and a label plus confidence output.
You can inspect the generated interface in the model's detail view. This tells you exactly what types to pass in and what you get back.
Understanding this contract up front saves time. Most integration bugs come from feeding the model the wrong input shape or type.
Models are picky about input. An image classifier expects an image in a specific size and pixel format; a text classifier expects a string; a tabular model expects specific named features.
For images, the Vision framework is your friend. It resizes and reformats images to what the model expects and reduces the boilerplate you would otherwise write by hand.
For text, the Natural Language framework can run classifiers directly and handle tokenization. For tabular models, you construct the feature inputs the generated class defines.
Getting this preprocessing right is critical. A model that scored well in Create ML can produce nonsense in the app simply because the input was scaled, cropped, or formatted differently than during training.
With input prepared, you instantiate the generated model class and call its prediction method. It returns the model's output — for a classifier, typically a predicted label and a set of confidence scores.
Wrap prediction in error handling. Model loading and prediction can throw, and you want to fail gracefully rather than crash if something is off.
Run inference off the main thread for anything non-trivial. Keeping heavy work off the main thread keeps your UI responsive, especially for image or real-time inputs.
Use the confidence scores, not just the top label. Showing or acting only on high-confidence predictions makes features feel far more trustworthy to users.
Always test on a physical device, not only the simulator. The simulator does not fully represent on-device hardware acceleration, and real cameras and sensors behave differently.
Test with realistic, messy inputs. Users provide dark photos, cropped screenshots, and unusual phrasing that never appeared in your clean training data.
Watch performance. Measure how long predictions take and how they affect responsiveness, particularly for live camera scenarios where you may run the model many times per second.
If accuracy on-device disappoints, suspect preprocessing first. A mismatch between how you prepare inputs and how the model was trained is the most common culprit.
Bundling the model in your app is the simplest approach — it ships with the binary and always works offline. The tradeoff is app size and the need for an app update to change the model.
Core ML also supports loading and compiling models at runtime, which enables downloading updated models without a full app release. Consider this if your model changes often.
Keep an eye on size. Multiple large models can noticeably inflate your download, so weigh accuracy against footprint.
Whatever path you choose, version your models clearly and record which app release used which model. This makes debugging behavior changes far easier later.
A robust integration plans for the moments when the model is unsure or the input is unusual, not just the happy path.
Every classifier returns a best guess, even for inputs unlike anything it was trained on. If a user points the camera at something outside your categories, the model still emits a label with some confidence. Decide what your app does in that situation before it happens.
A common pattern is a confidence threshold. When the top prediction sits below a sensible bar, treat the result as uncertain — ask the user to try again, show a neutral state, or fall back to a default rather than acting on a shaky guess.
Also think about latency and resource use. On older devices, or with large models run repeatedly on a camera feed, inference takes real time and energy. Throttling how often you run the model and cancelling stale requests keeps the experience smooth.
Finally, log predictions during development, including confidence scores. Seeing where the model hesitates or fails on real inputs tells you exactly which categories need more data before your next training pass, and it turns vague bug reports into concrete improvements.
Integration ends where normal iOS shipping begins. Once the model works in your app, you build and archive in Xcode as usual.
Distribution requires code signing and the Apple Developer Program. Whether you use TestFlight for beta testing or submit to the App Store, this membership is mandatory.
Be clear-eyed about tooling limits. Create ML trains the model and Core ML runs it, but neither builds, signs, or submits your app — that is Xcode plus your developer account.
With the model integrated and the app signed, your on-device machine learning feature is ready for real users. Keep your training project handy so you can retrain and re-integrate as your data grows.
No. When you add a Core ML model to Xcode, it automatically generates a Swift class named after the model. You just call its initializer and prediction methods.
The most common cause is an input mismatch. If your app preprocesses images or text differently than during training, results degrade. Use Vision or Natural Language to match the expected input format.
For anything non-trivial, no. Run inference off the main thread to keep the UI responsive, especially for image or real-time inputs.
Yes. In addition to bundling the model, Core ML supports compiling and loading models at runtime, which lets you download updated models without a full app update. Bundling is simpler but requires an app release to change the model.
Yes. Integrating the model is just development work. Distributing the app via TestFlight or the App Store requires code signing and a paid Apple Developer Program membership.