CoreML-Models: a model zoo where the .mlpackage is the deliverable
Core ML model zoo for iOS/macOS — PyTorch models converted to ready-to-use .mlpackage, each with a conversion script and SwiftUI sample app. Sibling repos cover Apple's Core AI framework (iOS/macOS 27) and on-device LLMs.
At a glance
- What is it?
- john-rocky/CoreML-Models distributes pre-converted Core ML packages through Google Drive links, with per-model conversion scripts and SwiftUI sample apps. It is a distribution channel, not a framework, and the licence situation is the first thing to check.
- Who is it for?
- Adopt this if you need a working .mlpackage quickly and can accept that the artefact arrives from Google Drive rather than a package registry. Do not adopt it if you need a pinned dependency, an auditable build, or a licence you can state without checking the original project first.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Swift, 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 problem is conversion, not model availability
Getting a PyTorch checkpoint onto an iPhone is not one step. You need coremltools, a traced or scripted graph, correct input shapes and dtypes, and a deployment target that matches the ops the converter emits. Most published research code ships a .pt file and a training script, and nothing else. The gap between that and a .mlpackage Xcode will accept is where projects stall. This repository exists to close that gap. Each entry pairs a downloadable converted model with a conversion script and, where one exists, a SwiftUI sample app. That is the whole proposition. The README is explicit about the workflow: find the model in the zoo, download it from the Google Drive link, and bundle it into your project. The stated audience is iOS and macOS developers who want on-device inference without running the conversion pipeline themselves. A secondary audience is people who want to read the conversion script to understand how a particular architecture maps onto Core ML, which is a different use of the same repository.
What is actually in the catalogue
The section list is long and unevenly weighted. Object detection carries eleven entries, including YOLOv5s through YOLO26, YOLO-World, YOLOE, D-FINE and RF-DETR. Segmentation has eighteen, from U2Net and RMBG1.4 through to SAM2-Tiny, FastSAM and MobileSAM. Super resolution has fifteen. Beyond vision there are audio entries (Kokoro-82M for text to speech, HTDemucs for source separation, pyannote segmentation-3.0 for speaker diarization, Stable Audio Open Small), a vision-language entry (Florence-2-base), and a language model block listing Gemma 4 E2B and E4B, Qwen3.5 2B and 0.8B, and Qwen3-VL 2B. The three most recent releases give a sense of the cadence: yoloe-v1 in June 2026, fastsam-v1 in May 2026, moge2-v1 in April 2026. MoGe-2 is listed as ViT-B Normal at 504x504 in FP16, which is the kind of detail the release notes carry and the README table does not always repeat. The breadth is the point. It also means quality and documentation depth vary per entry, and the README does not present a uniform template across all of them.
The delivery mechanism is a Google Drive link
This is the design decision that shapes everything else. Models are not published to a package registry, a CDN, or a Git LFS store. They are hosted on Google Drive and linked from tables in the README. For a first experiment that is fine. For a build pipeline it is not. There is no version string you can pin, no checksum published alongside the file, and no way to fetch the artefact from a script without going through whatever interface Drive exposes. The README acknowledges the licence situation directly: the licence for each model conforms to the licence for the original project. That is a correct position and also a burden transferred to you. The repository's own licence field is not established in the material available, so the terms covering the conversion scripts and sample apps are not something that can be stated here. The image classifier tables do carry a License column with links, and Efficientnetb0 and Efficientnetv2 both point at Apache 2.0, but that pattern is not shown to hold across every section. Assume you must check each entry.
Getting a model into an Xcode project
The documented path is short. Open the repository, find the section for the model class you need, follow the Google Drive link in the table row, download the file, and drag the .mlpackage into your Xcode project. If the row has a sample project link, open it and read how the model is invoked rather than guessing at input names and output shapes. The README does not document a command line fetch, a manifest, or a versioned install step, because none is offered. The repository does include conversion scripts per model, which matter if you want to reconvert at a different precision or input size rather than accept the published artefact. Those scripts are the closest thing to a reproducible build path here, and running them requires the upstream training code and the original weights, which live in the original projects. The README's own framing is permissive about all of this: you are free to use the model or not. That is an honest description of what is being offered.
Where this approach breaks down
The failure mode is supply chain, not inference. A model that arrives as an opaque binary from a file sharing link cannot be diffed, cannot be verified against a hash published in the repository, and cannot be restored if the link stops resolving. The README warns that if you like the repository you should give it a star, which is a request for visibility rather than a maintenance commitment. There is no stated support window, no deprecation policy for older entries, and no indication of which models have been re-exported after a coremltools change. The catalogue also spans years of upstream work, from Efficientnetb0 (2021 era) through to YOLO26 and Gemma 4, so the minimum deployment target implied by each .mlpackage will differ. A model converted against a newer Core ML opset may not load on the iOS version you support. That is not stated per entry in the material available. The second limitation is scope: this is a zoo, not a library. There is no shared Swift API across entries. Each sample app stands alone, and moving from one model to another means reading a different sample.
Compared with converting it yourself
The real alternative is not another model zoo. It is coremltools plus the original repository. That path costs you a conversion script, a traced graph, and debugging time when an operator is unsupported, but it gives you a checksum you control, a pinned commit, and a licence you have read at the source rather than inferred from a table. The trade is time against provenance. This repository's value is highest when the conversion is the annoying part and the model is a commodity: a YOLO variant, a super resolution network, an ESRGAN-family upscaler. It is lowest when the model is the product, when you need to prove what binary you shipped, or when the upstream licence is ambiguous and you would rather read it in the original repository than in a link. A middle path exists and the repository supports it: use the published .mlpackage to validate that the architecture works on device, then run the included conversion script against the upstream weights to produce your own artefact. That gets you the fast answer and the auditable build.
Maintenance cost and what to verify first
The recurring cost is re-export. Core ML and coremltools move, and a .mlpackage that loads today may need reconversion after an OS or toolchain change. Because this repository publishes artefacts rather than a build system, that reconversion is the maintainer's work, and you inherit the timing of it. If a model you depend on stops being updated, your options are to pin your OS version, to run the included conversion script yourself, or to drop the model. Budget for the third option being the realistic one for anything long-lived. On licensing, the repository's position is that each model follows its original project, which means the licence question is answered per entry and not once. Nothing here constitutes legal advice, and the absence of a stated repository licence in the available material is a gap you should resolve before redistributing the conversion scripts or bundling a model into a commercial app. Verify three things before you commit: the upstream licence for your specific model, the minimum deployment target the .mlpackage requires, and whether the Google Drive link is stable enough for however you plan to fetch it.
Editorial conclusion
Adopt this if you need a working .mlpackage quickly and can accept that the artefact arrives from Google Drive rather than a package registry. Do not adopt it if you need a pinned dependency, an auditable build, or a licence you can state without checking the original project first. Before shipping anything, open the per-model table, read the License column, follow it to the upstream repository, and confirm the terms match your distribution. Then run the model on your oldest supported device, because the README does not state a minimum OS version per entry.
Community notes