coremltools: converting PyTorch, TensorFlow and scikit-learn models to Core ML
Core ML tools contain supporting tools for Core ML model conversion, editing, and validation.
At a glance
- What is it?
- Apple's Python package turns trained models from TensorFlow, PyTorch, scikit-learn, XGBoost and LibSVM into the Core ML format, then lets you read, edit and validate the result. Its value is real but bounded: prediction checks need macOS, and the converter targets Apple's runtime rather than a portable one.
- Who is it for?
- Adopt coremltools if you are shipping a model inside an Apple platform app and your training stack is PyTorch, TensorFlow, scikit-learn, XGBoost or LibSVM. Do not adopt it if you need one artifact that runs on Android, Linux servers and browsers as well, or if you have no macOS machine available for the prediction step, since the README ties verification to macOS.
- Can I use it commercially?
- Yes. BSD-3-Clause is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap coremltools fills between a training script and an app binary
A model that trains fine in PyTorch is not something an iOS or macOS app can load. Core ML is Apple's framework for on-device inference, and it expects a model in its own format. coremltools is the Python side of that boundary. The README lists the sources it accepts: TensorFlow 1.x, TensorFlow 2.x, PyTorch, and the non-neural frameworks scikit-learn, XGBoost and LibSVM. The audience is therefore narrow and identifiable. You are a Python-side engineer or an ML engineer working alongside an app team, your trained artifact lives in one of those libraries, and the destination is an Apple device. If the destination is a Linux inference server or an Android build, this package is pointed at the wrong target, and no amount of configuration changes that. The package does three things according to its own description: convert trained models to Core ML, read and write and optimize Core ML models, and verify conversion or creation by making predictions using Core ML, with the README parenthetically noting that this last capability is available on macOS.
What conversion actually produces, and why the intermediate representation matters
The mechanism is a translation into a typed model file rather than a wrapper around the original framework. The repository links a Core ML Specification document, and the README describes Core ML as providing "a unified representation for all models." That phrasing is the design constraint: the converter does not preserve your PyTorch graph and execute it through some compatibility shim. It maps your operators onto the operators that the Core ML specification defines, and the resulting file is what the runtime executes. Two consequences follow. First, operator coverage is the binding constraint. A layer that has no Core ML equivalent has nowhere to go, and the failure surfaces during conversion rather than at inference time. Second, the specification is versioned, and the version of the specification you can emit depends on the version of coremltools you install. The README does not enumerate supported operators or map specification versions to package versions; it points to the API Reference and the specification document for that. Treat operator coverage as the first thing to check against your own model, because it is the thing most likely to decide whether the project is usable for you. The editing and optimization surface is the other half of the mechanism. Because the converted artifact is a Core ML model that coremltools can read and write, you can modify it after conversion, which is how you would adjust a model without going back to the training library. The README gives no detail on what optimization means in practice, so this is a claim to verify in the API reference rather than take on faith.
Installing and pinning a version
Installation is a single pip command from PyPI: `pip install coremltools`. The README also documents a pre-release channel, `pip install coremltools==9.1.dev1`, which pins an explicit development version rather than resolving to the latest stable release. That pinning style is worth copying for the stable line too, because the conversion output is tied to the package version. The release history supplied shows 9.0 published on 2025-11-10, a 9.0b1 beta on 2025-07-28, and 8.3 on 2025-04-29, so a project moving from 8.3 to 9.0 crosses a major version boundary and should expect conversion behaviour to be checked rather than assumed. The README points to a separate Installing Core ML Tools guide and a BUILDING.md for source builds, which suggests the documented install path is the supported one and building from source is a distinctly different exercise. There is no configuration file, no environment variable and no config key described in the README: this is a library you import, not a service you configure. That is a genuine simplification, and it also means there is no central place to record which converter version produced a given model file. If you need that traceability, it has to come from your own build tooling.
The macOS boundary and what it does to a CI pipeline
The README's parenthetical about macOS is the most consequential limitation in the whole document. Conversion, reading and writing are Python operations, but verifying the conversion by making predictions using Core ML requires macOS. For a team on Linux CI runners, that splits the pipeline in two. The conversion step can run anywhere Python runs. The verification step cannot, and without it you are shipping a model file whose numerical output you have not compared against the source model. Prediction checks are exactly the kind of thing that catches a silently wrong operator mapping, so losing them is not a minor inconvenience. The practical options are a macOS runner in CI, a manual check on a developer machine, or accepting unverified conversions. The README does not describe a Linux fallback for the prediction path, so do not plan around one existing. A second, related limitation is that the README says nothing about how well a converted model performs on the Neural Engine or how Core ML's CPU, GPU and Neural Engine scheduling decisions are surfaced to the converter. The README states that Core ML optimizes on-device performance by using those units while minimizing memory and power, but it offers no numbers, and none should be inferred from it.
Where ONNX sits relative to this, and why the difference is not cosmetic
ONNX is the obvious alternative to name, and the difference is architectural rather than a matter of taste. ONNX is an interchange format with multiple runtimes and multiple converters feeding it, so a single ONNX file can be executed by different engines on different operating systems. coremltools produces a Core ML model, which is an Apple runtime format. The conversion path reflects that: ONNX conversion is typically framed as exporting from your framework into a neutral graph, while coremltools maps your framework's operators directly onto the Core ML specification's operators and emits a file the Apple runtime consumes. Choosing ONNX buys portability across targets and costs you the direct mapping into Apple's runtime and the editing surface coremltools provides over its own format. Choosing coremltools buys a tighter fit to the Apple deployment story and costs you any path to non-Apple targets without a second conversion pipeline. Neither is a superset of the other. If your product ships an Apple app and nothing else, the direct route is the shorter one. If the same model also needs to run on a server, you will end up maintaining two artifacts, and that duplication is a real ongoing cost that the README does not address because it is out of scope for the project.
Maintenance, versioning and the BSD-3-Clause licence
The repository is not archived and the last push recorded is 2026-09-09, with a stable 9.0 release in November 2025, so this is an actively maintained package rather than a frozen one. Active maintenance cuts both ways for adopters: fixes and new operator support arrive, and so do behaviour changes in conversion output. Because the emitted model is tied to the specification version the package supports, a coremltools upgrade is a change to a build artifact, not just a dependency bump. The supplied material does not describe a deprecation policy or a compatibility guarantee between major versions, so the safe assumption is that 8.3 to 9.0 is a boundary worth testing rather than trusting. The licence is BSD-3-Clause, a permissive licence that generally allows use in proprietary software provided the copyright notice and licence text are retained and the names of the copyright holders are not used to endorse derived products. That is a general description of the licence family, not legal advice, and it says nothing about the terms attached to the Core ML framework itself, which is a separate Apple product governed by its own agreements. Check those separately before shipping, because a permissive licence on the converter does not imply anything about the runtime your app links against.
Who should pick this up and what to confirm before the first conversion
The fit is specific: an Apple-platform app, a model trained in PyTorch, TensorFlow, scikit-learn, XGBoost or LibSVM, and a team willing to run the prediction check on macOS. The mismatch is equally specific: a model with operators that have no Core ML equivalent, a pipeline that must produce one artifact for Apple and non-Apple targets, or a team with no macOS machine in the loop. Before converting anything real, take the smallest model in your stack and run it end to end, then compare its outputs against the source model on macOS. That single exercise tells you more about operator coverage than reading a support matrix, because the failure mode here is a conversion that succeeds and produces different numbers. Pin the coremltools version in your build, record which version produced each shipped model file, and re-run the comparison whenever that pin moves. Everything else the README promises about reading, writing and optimizing Core ML models is documented in the API reference rather than the README, and that is where the detail on the editing surface lives.
Editorial conclusion
Adopt coremltools if you are shipping a model inside an Apple platform app and your training stack is PyTorch, TensorFlow, scikit-learn, XGBoost or LibSVM. Do not adopt it if you need one artifact that runs on Android, Linux servers and browsers as well, or if you have no macOS machine available for the prediction step, since the README ties verification to macOS. Before committing, confirm the exact PyTorch or TensorFlow operator coverage your model uses against the release notes for the version you pin, and check whether your deployment targets require a Core ML specification newer than the one your installed coremltools writes.
Community notes