Your Create ML model trains but predicts poorly. Here's a focused troubleshooting guide to the real causes of low accuracy — bad data, imbalance, overfitting — and how to fix each.
Low accuracy is the most common Create ML frustration. The instinct is to retrain repeatedly, but that rarely helps if the underlying data is the problem.
Start by locating where accuracy is low. Compare training accuracy, validation accuracy, and testing accuracy — the pattern between them points at the cause.
If training accuracy is high but validation and testing are low, you are overfitting. If all three are low, the model is underfitting or your data is too weak to learn from.
Treat this like debugging. Form a hypothesis from the numbers, change one thing, and remeasure. Random retraining wastes hours and teaches you nothing.
The single biggest lever is data quality. Machine learning models learn whatever patterns exist in your examples, including bad ones.
Audit your labels first. Mislabeled examples — a positive review tagged negative, or a cat photo in the dog folder — directly teach the model the wrong thing.
Check for inconsistency. If different people labeled data with different rules, the model receives contradictory signals. Write down clear labeling rules and apply them uniformly.
Also remove junk. Corrupt images, blank text rows, or duplicated samples add noise. A smaller, clean dataset routinely beats a larger, messy one.
Class imbalance quietly wrecks accuracy metrics. If most of your samples belong to one class, a model can score high by always guessing that class while being useless.
Check the counts per class. Create ML's evaluation view often exposes per-class performance, which reveals whether one category is dragging the rest down.
To fix imbalance, gather more examples for the underrepresented classes. This is the most reliable remedy because it gives the model genuine signal.
When collecting more is impossible, be realistic about expectations for the rare class and consider whether it belongs as its own category at all. Sometimes merging or dropping a tiny class is the honest fix.
Overfitting shows up as high training accuracy with much lower validation and testing accuracy. The model memorized your examples instead of learning general patterns.
The best antidote is more varied data. Add examples that cover the real diversity of inputs — different lighting, phrasing, backgrounds, and edge cases.
For image classifiers, Create ML's data augmentation options — noise, blur, rotation, cropping, flipping — synthetically increase variety. Enable them when your dataset is small, but note they lengthen training.
Also resist over-training. Squeezing training accuracy toward perfection often widens the gap to validation accuracy. A model that generalizes beats one that memorizes.
Sometimes accuracy is low because the task itself is ambiguous. If humans cannot reliably agree on a label, a model will not either.
Review your categories. Overlapping or fuzzy classes — like optimistic versus positive — confuse both labelers and the model. Clearer, more distinct classes are easier to learn.
Consider whether you have the right template. A problem you framed as classification might be better as object detection, sound classification, or a tabular model.
Also ask whether the signal exists at all. If the input genuinely does not contain enough information to predict the label, no amount of tuning will fix it. Reframing beats brute force.
A misleading accuracy number often comes from a weak evaluation. If your test set overlaps with training data, accuracy looks great but means nothing.
Ensure your testing data is truly held out — samples the model has never seen during training or validation. This is the only honest measure of real-world performance.
Make the test set representative. It should reflect the messy, varied inputs real users produce, not just clean examples that resemble training data.
If on-device accuracy is worse than Create ML's reported number, suspect an input-preprocessing mismatch in the app rather than the model itself. Matching how inputs are prepared to how they were trained often recovers the lost accuracy.
Data leakage is a subtle cause of accuracy that looks great in Create ML but collapses in the real app. It happens when information sneaks from your test set into training.
The classic version is near-duplicates. If several photos of the same object, or lightly edited copies of the same text, land in both training and testing, the model effectively sees the answers in advance.
Group related samples so they stay on the same side of the split. All shots from one photo session, or all messages from one conversation, should sit together rather than be scattered across training and testing.
When a reported accuracy looks suspiciously high, leakage is a prime suspect. A cleaner split usually brings the number down to something honest and more predictive of real behavior.
A single overall accuracy number hides more than it reveals, and chasing it blindly can send you in the wrong direction.
Open the per-class results in Create ML's evaluation view. A model at strong overall accuracy can still contain one or two classes performing far worse than the rest, and those weak classes are usually where users feel the failures.
Look at the pattern of mistakes, not just the totals. If two categories are constantly confused for each other, that is a signal they overlap, share too little distinguishing signal, or need clearer, more distinct examples. That is a data and framing problem, not a training-time problem.
Weigh the classes by how much they matter to your product. Misclassifying a rare but important category may hurt the experience more than a few errors spread across common ones. Direct your next round of data collection at the classes that are both weak and important.
Finally, resist the urge to optimize a number that already looks good. If the average is high but one critical class lags, the honest move is to strengthen that class specifically rather than declaring victory on the headline figure.
Occasionally the ceiling is the tool, not your data. Create ML is deliberately opinionated and does not expose custom architectures.
For most image, text, sound, and tabular problems, that ceiling is high enough. But a genuinely hard, specialized task may need a full framework and a conversion step to Core ML.
Before concluding that, though, exhaust the cheaper fixes: cleaner labels, balanced classes, more varied data, and honest evaluation. These solve the vast majority of low-accuracy cases.
And keep the boundaries in mind. Improving accuracy is data and modeling work; shipping the improved model still means integrating in Xcode and distributing through the App Store with a developer account.
That is classic overfitting: the model memorized training data instead of generalizing. Add more varied examples, balance classes, use augmentation for images, and verify your test set is truly held out.
Almost always, improving data quality — fixing mislabeled examples, balancing classes, and adding varied samples — beats retraining or tweaking settings. Audit your data before you retrain again.
Check the sample count per class and review per-class accuracy in the evaluation view. If one class dominates the dataset or one class scores far lower than the rest, you likely have imbalance.
Yes. If Create ML reports good accuracy but the app performs poorly, the input preprocessing in your app probably doesn't match training. Use Vision or Natural Language to match expected formats.
Only after exhausting data fixes. If a genuinely specialized task needs a custom architecture, you may train in a full framework and convert to Core ML — but most accuracy problems are data problems, not tool limits.