Your Create ML model trained fine but fails, crashes, or gives wrong results inside your iOS app. Here's how to diagnose and fix the most common integration problems with Core ML.
When a Create ML model fails in your app, the first job is to figure out where. Is the model good but integrated wrong, or is the model itself weak?
You already have a clue: Create ML's evaluation tab told you how the model performs on held-out data. If that number was good, the problem is almost certainly integration, not the model.
Separating these two possibilities prevents wasted effort. Retraining a fine model will not fix a preprocessing bug in your app.
This guide focuses on the integration side, where most in-app failures actually live: missing models, input mismatches, threading issues, and misread outputs.
If the app cannot find the model, or the build fails referencing it, the cause is usually target membership.
Select the model file in Xcode's navigator and check the File Inspector. The model must be included in your app target, and it must actually be copied into the project, not just referenced from an external location.
If the generated Swift class is missing or unrecognized, try a clean build. Xcode generates the model interface at build time, and a stale build can hide it.
Also confirm the class name you are calling matches the model file name. Renaming the file changes the generated class name.
The most common in-app failure is a model that scored well in Create ML but returns nonsense in the app. The usual cause is an input mismatch.
Models expect inputs in a precise form. An image classifier wants a specific size and pixel format; if your app feeds a differently scaled, cropped, or color-formatted image, predictions degrade.
Use the Vision framework for image models. It handles resizing and formatting to match what the model expects, eliminating a whole class of subtle bugs.
For text, use the Natural Language framework and feed input the way the model was trained. Matching preprocessing to training is the single most important fix here.
Crashes usually come from unhandled errors or bad input types. Core ML prediction can throw, and force-unwrapping optionals around it is a common crash source.
Wrap model loading and prediction in proper error handling. Handle the failure path gracefully instead of assuming success.
Check that the types you pass exactly match the generated interface. Passing the wrong input type, or a nil where a value is required, leads to crashes.
Inspect the model's input and output definitions in Xcode's model view. That is the authoritative contract, and matching it precisely prevents most runtime failures.
If the app hangs or stutters during prediction, you are likely running inference on the main thread.
Move model inference off the main thread. Keeping heavy work off the main thread keeps scrolling and animations smooth, especially for images or live camera feeds.
For real-time scenarios, avoid running the model more often than you need. Throttling how frequently you run predictions on a camera stream can dramatically improve responsiveness.
Also test on a real device. The simulator does not represent on-device hardware acceleration, so performance and even behavior can differ from your Mac.
Behavior that differs between simulator and device is a known gotcha. The simulator and real hardware do not run models identically.
Always validate on a physical device before trusting results. Neural Engine acceleration exists on device, not in the simulator, and real cameras and sensors provide different input.
If device results are worse, revisit preprocessing with real inputs. Live camera frames are messier than the clean test images that looked fine in the simulator.
When possible, test across a range of devices. Performance and available acceleration vary by hardware, and a model that feels instant on a newer device may be slower on an older one.
Sometimes the model is correct but your code interprets the output wrong. Classifiers typically return a top label plus confidence scores for all classes.
Confirm you are reading the right output field. Mixing up the predicted label and the confidence dictionary leads to confusing behavior.
Use the confidence values. Acting only on predictions above a sensible confidence threshold, and handling low-confidence cases gracefully, makes the feature feel far more reliable.
Display or log the full output during development. Seeing the actual labels and scores quickly reveals whether the model or your interpretation is at fault.
When behavior is baffling, confirm that the model in the app is the one you think it is, and that you are feeding it what it expects.
It is easy to fix a model in Create ML, re-export, and forget to replace the file bundled in the app. The app then runs an older model while you debug the new one, which produces symptoms that make no sense against your latest evaluation. Check the file that is actually in the target.
Inspect the model's input and output description in Xcode and compare it against the code calling it. If the model expects an image of a specific size, or a particular set of named features, and your code supplies something else, predictions degrade even though nothing crashes.
Adopt a simple versioning habit. Give each export a distinct name or embedded version note, and record which app build shipped which model. When behavior changes between releases, you can immediately tell whether the model or the surrounding code moved.
A quick end-to-end sanity test helps too. Run one known input through the app and confirm the output matches what Create ML's Preview showed for the same input. If they disagree, the gap is in your integration, and that is where to look first.
After the integration checks, decide honestly whether to retrain. If Create ML's evaluation was strong and preprocessing now matches training, the model is probably fine and further retraining is wasted effort.
If, even with correct inputs, the model genuinely misclassifies real-world data, the fix moves back to data — more varied, balanced, cleanly labeled examples — and a fresh export.
Keep your Create ML project so you can iterate without starting over, and version your exported models so you know which one each app build used.
And keep scope in mind. Fixing integration is app work in Xcode; Create ML only produced the model. Shipping the fixed app to users still requires code signing and an Apple Developer Program membership.
Almost always an input mismatch. If your app scales, crops, or formats inputs differently than training, predictions degrade. Use Vision for images and Natural Language for text to match the expected input format.
Check that the model is added to your app target and copied into the project, confirm the class name matches the file name, and do a clean build so Xcode regenerates the model interface.
You are likely running inference on the main thread. Move prediction off the main thread, and for camera feeds, throttle how often you run the model.
Always validate on a real device. The simulator doesn't fully represent on-device hardware acceleration, and real cameras and sensors provide different inputs than clean test data.
If Create ML reported good accuracy and your app now preprocesses inputs correctly, the model is likely fine — fix the integration. Retrain only if the model genuinely misclassifies real-world data, and fix it by improving the dataset.