john-rocky/CoreML-Models: a Core ML model zoo with conversion scripts and SwiftUI samples

What CoreML-Models solves, and for whom

Getting a PyTorch model onto an iPhone is mostly conversion work: tracing the graph, picking an input size, handling ops that coremltools cannot lower, and checking that the output tensor layout is what your Swift code assumes. CoreML-Models exists to skip that step for a long list of architectures. The README tells you to find the model you want, download it from the Google Drive link, and bundle it in your project, or open the sample project where one is provided.

The audience is narrow and specific. This is for iOS and macOS developers who already know which architecture they need (a segmentation net, a depth estimator, a small language model) and want the .mlpackage without running the conversion themselves. It is not for people shopping for a model. There is no accuracy comparison, no latency table, and no guidance on which of the eleven YOLO variants in the object detection section is the right trade-off for a given device.

The catalog is broad. Sections cover image classification, object detection, multi-object tracking, segmentation, video matting, super resolution, low light enhancement, image restoration, image generation, image2image, inpainting, monocular depth estimation, Stable Diffusion, colorization, face recognition, 3D face pose, speaker diarization, voice conversion, text-to-speech, text-to-music, audio source separation, vision-language, language models, zero-shot classification, anomaly detection and music transcription.

How the .mlpackage files are produced and distributed

The repository layout tells most of the story. At the top level there are conversion_scripts/, docs/, and sample_apps/, alongside the README. The README does not describe a build pipeline, a CI job, or a hosted registry. The models themselves live on Google Drive, and the README is the index: each entry is a table row with a Drive link, a file size, the dataset, a link to the original project, and the licence of that original project.

So the data flow is manual in both directions. The maintainer converts a PyTorch checkpoint with coremltools, uploads the resulting .mlpackage to Drive, and records the row. You download the file and drag it into Xcode. There is no versioned artifact URL, no checksum published in the README, and no manifest that a script could consume. If a Drive link rots, the only signal is a failed download.

The conversion_scripts/ directory is the part that makes the catalog auditable. Because the script for a given model is in the repository, you can read what input size was traced, what precision was used, and which ops were handled, then decide whether to trust the uploaded artifact or rerun the conversion on your own machine. That is a meaningfully different proposition from a Drive folder of anonymous .mlpackage files.

The sample_apps/ directory covers the other half. Where a sample project exists, the README points you at it, and the SwiftUI code shows the expected input shape and how outputs are decoded. For models without a sample, the README's instruction is simply to try the model and see.

Installing a model and running a first inference

There is no package manager step. The README's instruction is to download the model from its Google Drive link and bundle it in your project. The commands below are the surrounding workflow: fetch the repository so you have the conversion script and any sample app for the model you picked, then inspect the tree to find the matching sample.

git clone https://github.com/john-rocky/CoreML-Models.git
cd CoreML-Models
ls sample_apps
ls conversion_scripts

The two listings are the practical index. sample_apps tells you which models ship with a working SwiftUI project, and conversion_scripts tells you which models have a reproducible conversion path. A model that appears in neither is a Drive file and a README row only.

Once you have the .mlpackage, add it to an Xcode target and let Xcode generate the model class. The README does not spell out the generated API, and the exact class name and method signature depend on the model, so read the sample app for the model you chose rather than guessing. The shape of the integration is the standard Core ML one: load the compiled model, build an input feature provider, call prediction, and read the named outputs.

If you would rather not trust the uploaded artifact, the conversion script is the alternative path. The README does not give a single command that works for every model, because each script targets a different upstream repository and input size. Open the script for your model and follow what it does. Do not assume a shared flag set across the directory.

Where the catalog breaks down

The licence situation is the largest open question. The repository has no licence file, and the README states that the licence for each model conforms to the licence for the original project. That means the collection has no single licence. A model converted from an Apache 2.0 upstream and a model converted from a research-only checkpoint sit in the same README with the same download instruction, and the difference only shows up in the licence column of the table. Before you ship anything, read that column and follow the link.

Distribution through Google Drive is the second constraint. Drive links are not a package registry. They can be rate-limited, they can require a browser session, and they give you no way to pin a version or verify that the bytes you downloaded match what the maintainer uploaded. For a production build, the usual fix is to download once, commit the .mlpackage to your own artifact store, and treat the Drive link as a one-time fetch.

The README is also thin on the things that decide whether a model is usable. It gives file size and dataset but no accuracy numbers, no on-device latency, and no minimum OS version per model. The topics list mentions apple-silicon and core-ai, and the repository description mentions sibling repos for Apple's Core AI framework and on-device LLMs, but the README itself does not map models to OS requirements. If your deployment target is older than the model's requirements, you will find out at integration time.

Finally, the README is explicit that the maintainer is not offering support: you are free to do or not. That is an honest framing, and it should shape how you plan around the project.

CoreML-Models compared with converting it yourself or using MLX

The realistic alternative is not another model zoo. It is running the conversion yourself with coremltools. The difference is control versus time. Doing it yourself means you choose the input size, the precision, and the ops you are willing to leave out, and you end up with a script you own and can rerun when the upstream checkpoint changes. CoreML-Models gives you the artifact immediately and, in conversion_scripts/, a reference implementation of that same work. If the script is present and readable, the gap narrows a lot: you can use the uploaded model to prototype and the script to build your own version later.

The other comparison people search for is Core ML versus MLX. They are aimed at different problems. Core ML produces .mlpackage artifacts that Xcode compiles into an app and that run through the system's model runtime on iOS and macOS. MLX is Apple's array framework for running and training models, and it is not a path to an .mlpackage you bundle in an iOS app. If your goal is a shipped app with a model inside it, Core ML is the target format and this repository is a source of that format. If your goal is experimentation on a Mac, the two are not substitutes.

Within the Core ML ecosystem, the practical alternative to this repository is converting on demand from the upstream project, which the README links for every entry. That link is arguably the most valuable column in the table, because it tells you where the weights, the paper, and the real licence live.

Maintenance, releases and what an upgrade costs you

The last push to the default branch was on 2026-09-09, and the repository is not archived. Releases are tagged per model rather than per collection: yoloe-v1 on 2026-06-01, fastsam-v1 on 2026-05-29, and moge2-v1 on 2026-04-08. That release pattern matters for upgrade planning. There is no version 2.0 of the zoo that you bump as a unit. You upgrade one model at a time, by replacing one .mlpackage in your project.

That is good for stability and bad for predictability. A model you adopted two years ago will not change under you, because nothing pushes updates to a file you already downloaded. But you also get no deprecation notice, no migration guide, and no changelog beyond the release titles. When a new tag appears for a model you use, the only way to know whether it is faster or more accurate is to read the conversion script diff and measure it yourself.

The upgrade cost is therefore mostly integration testing, not code changes. Swapping an .mlpackage can change the generated class name, the input feature names, or the output tensor shape, all of which your Swift code depends on. Budget for re-verifying the input and output contract each time, and keep the previous .mlpackage in your own artifact store so a rollback is a file swap rather than a Drive re-download. The README does not document rollback, so that procedure is yours to define.

Licence implications follow the same per-model logic. Because there is no repository licence and the README defers to each original project, an upgrade can move a model from a permissive licence to a more restrictive one, or the reverse. Re-read the licence column when you take a new tag. This is not legal advice; it is a description of where the licence information lives in this repository.

Editorial conclusion

Adopt it if you want a ready-made .mlpackage for a known architecture and you are willing to verify the upstream licence yourself before shipping. Do not adopt it if you need a single licence covering the whole collection, a package manager install, or a support commitment: the README states the licence for each model conforms to the original project, and the repository carries no licence file. Verify first that the Google Drive link for your model still resolves, that the bundled model matches the input size and output tensor layout your app expects, and that the original project's licence permits your use.

Frequently asked questions

Official sources

1. Issues
2. john-rocky/CoreML-Models on GitHub
3. Project website
4. README
5. Releases