# CoreNet: Apple's deep learning toolkit for reproducing its own papers

> CoreNet is not a general purpose framework. It is the training and evaluation layer Apple used for OpenELM, FastViT, MobileViT and CatLIP, and the projects folder is the point.

**apple/corenet** — CoreNet: A library for training deep neural networks

- Repository: https://github.com/apple/corenet
- Stars: 7,005 · Forks: 541
- Language: Jupyter Notebook
- License: NOASSERTION
- Published: 2026-10-06 · Updated: 2026-10-06 · Language: en
- Canonical page: https://hysenlabs.com/projects/apple-corenet

## A research toolkit rather than a general framework

The README describes the scope in deliberately broad terms: a deep neural network toolkit that lets researchers and engineers train standard and novel small and large-scale models for a variety of tasks, including foundation models such as CLIP and an LLM, object classification, object detection and semantic segmentation.

What separates it from PyTorch, torchvision or a model hub is the reason it exists. The README collects publications from Apple that use CoreNet, and the list is long: OpenELM, FastViT, MobileOne, MobileViT and MobileViTv2, CatLIP, ByteFormer, RangeAugment, KV Prediction, and the earlier CVNets paper. Each of those has a matching folder under `projects/`.

The relationship to CVNets has its own section in the table of contents, which is where to look if you arrive from the older computer vision library. The stated range covers vision and language models rather than a single domain, though the centre of gravity in the publication list is still vision backbones and multimodal training.

So the honest summary is that this is the layer underneath Apple's research papers, published so others can run and extend them. If your goal is to fine-tune a CLIP model on your own data, this is a heavier route than a model hub. If your goal is to know exactly how FastViT was trained, the yaml files and checkpoints are the answer.

## Installing on Linux requires Git LFS before anything else

The install instructions open with an unusual requirement: Git LFS, needed to run the tests and the Jupyter notebooks in the repository and to contribute to it. The reason is model weights. Skip the LFS pull and you end up with pointer files where checkpoints should be, which is a confusing failure rather than an obvious one.

The Linux sequence is clone, enter the directory, install LFS, pull the LFS objects, then create a virtual environment and install the package in editable mode:

```bash
sudo apt install git-lfs

git clone git@github.com:apple/corenet.git
cd corenet
git lfs install
git lfs pull
python3 -m venv venv && source venv/bin/activate
python3 -m pip install --editable .
```

Audio and video work needs system packages on top of that:

```bash
sudo apt install libsox-dev ffmpeg
```

The README recommends Python 3.10+ and PyTorch version 2.1.0 or later on Linux, and says Python 3.9+ should be enough on macOS. Keep the second half of that in mind, because the pinned requirements are older.

## The macOS path exists because of case insensitive file systems

The macOS instructions include a step that looks like a typo and is not. Git LFS comes from Homebrew rather than apt, but the notable line is a physical-path `cd` between entering the directory and running `git lfs install`:

```bash
brew install git-lfs

git clone git@github.com:apple/corenet.git
cd corenet
cd $(pwd -P)  # See the note below.
git lfs install
git lfs pull
python3 -m venv venv && source venv/bin/activate
python3 -m pip install --editable .
```

The README explains the reason in its own note: the macOS file system is case insensitive, and that can cause issues with Git, so you should treat the repository on disk as though the path were case sensitive, matching the capitalisation you see when you list the directories. Resolving the physical path switches you onto it.

This is the sort of detail that only appears in a README written by people who hit the problem. It also says something about where the work happens: development and testing are aimed at macOS and Linux, and the Apple Silicon angle is more than incidental.

Optional audio and video dependencies install from Homebrew as well:

```bash
brew install sox ffmpeg
```

## Projects as recipes: yaml configs beside pretrained weights

The `projects/` directory is where the research content actually lives, and the README describes a consistent shape for each project folder. A `README.md` with documentation, links to the pretrained weights and citations. A path of the form `<task_name>/<model_name>.yaml` holding the configuration used to reproduce training and evaluation. Alongside those, pre-trained model weights and checkpoints.

The projects listed are kv-prediction, byteformer, catlip, clip, fastvit, mobilenet_v1, mobilenet_v2, mobilenet_v3, mobileone, mobilevit, mobilevit_v2, openelm, range_augment, resnet and vit. kv-prediction is marked as newly released, matching the note under What's new that version 0.1.1 includes KV Prediction with a direct link into that folder.

That yaml-plus-weights arrangement is the entire workflow. To reproduce a paper you find its folder, take the config, point it at your data, and use the published weights as a reference for what correct output looks like. The README's claim is reproducible training recipes, and the design is honest about that: the config is the artefact, not a general API.

Beside `projects/` sit `tutorials/` with notebooks and guides, including train_a_new_model_on_a_new_dataset_from_scratch.ipynb, clip.ipynb, semantic_segmentation.ipynb, object_detection.ipynb, and a markdown guide to slurm and multi-node training.

## Pinned dependency versions are the upgrade ceiling

requirements.txt pins everything with an equals sign, and the PyTorch line is the one that decides whether you can install this at all. The README recommends PyTorch 2.1.0 or later while the pinned set is older and internally consistent:

```bash
torch==2.3.0
torchvision==0.18.0
torchtext==0.18.0
torchaudio==2.3.0
torchdata==0.7.1
```

Around that sit `numpy==1.26.4`, `scipy==1.13.0`, `pandas==2.2.1`, `pycocotools==2.0.7` for MSCOCO, `cityscapesscripts==2.2.2`, `coremltools==7.2` for the Core ML path, `pytorchvideo==0.1.5`, `av==12.0.0` for video decoding, `h5py==3.10.0`, `pybase64==1.3.2` for reading byte data as ByteFormer needs, and `ftfy==6.2.0` with `regex` for the CLIP tokenizer.

The tooling pins are just as tight: `black==24.4.0` and `isort==5.13.2` for formatting, `pytest==8.1.1` with `pytest-mock`, `pytest-xdist` and `pytest-timeout`. A comment in the file notes that the PyTorch section has to stay synchronised with the Dockerfile used for CI.

Practically that means installing CoreNet inside an environment built for it. Sliding it into an environment shared with other work will fight the pins, and because the lint tooling lives in requirements rather than an extra, a version conflict shows up as a CI-style failure instead of a warning.

## Formatting, tests and what the repository does not settle

There is real engineering discipline here even though the README is short. pyproject.toml configures isort with the black profile and black itself, sets pytest's junit family to xunit2, and disables the warnings plugin because `corenet/__init__.py` installs its own warning filters and CI turns unexpected warnings into errors. It also registers a `skip_ci` marker for tests that should be skipped in CI because they download files.

The Makefile holds a `format` target chaining several checks: missing `__init__.py` files, license headers, end-of-file newlines, isort, black and convention checks over `corenet` and `tests`. There is an `update-copyright-year` target that rewrites copyright lines in bulk, which is where the headers in the source come from.

Two things a reader should settle personally. Repository metadata reports no recognised licence, though there is a `LICENSE` file and a setup.py carrying an Apple Inc. copyright, so read the licence text rather than inferring it. And there are no GitHub releases, so the version you get is whatever sits in `corenet/__version__.py`, which setup.py parses with a regular expression.

The `mlx_examples/` directory is worth a look if you are on Apple Silicon, since those examples exist to show CoreNet models running efficiently there. For multi-GPU or multi-node work, the slurm guide in `tutorials/` is the documented route. The default branch is `main` and the last push was on 2026-09-25.

## Conclusion

CoreNet makes sense if you want to reproduce a specific paper from its list or train one of its backbones, and the setup is an ordinary Python install once Git LFS is out of the way. It is the wrong choice if you want a general framework with a large plugin ecosystem, or if you need a current PyTorch release, since requirements.txt pins torch to 2.3.0. Before committing, read one project folder end to end, because the yaml config beside pretrained weights beside a README is the format you will be working in, and open the LICENSE file yourself given the repository metadata reports no recognised licence.

## FAQ

### What is CoreNet used for?

It is the deep learning toolkit Apple used for a list of published papers, covering foundation models such as CLIP and an LLM, plus object classification, detection and semantic segmentation. Each listed paper has a folder under `projects/` with a yaml config and pretrained weights.

### How do I install CoreNet?

Install Git LFS first, clone the repository, run `git lfs install` and `git lfs pull`, then create a virtual environment and use `python3 -m pip install --editable .`. The README recommends Python 3.10+ and PyTorch version 2.1.0 or later on Linux.

### Why does CoreNet need Git LFS?

Model weights and checkpoints are stored through Git LFS, and without pulling them you get pointer files where the weights should be. The README also notes that LFS is needed to run the tests and the notebooks, and to contribute.

### What is the relationship between CoreNet and CVNets?

CVNets is Apple's earlier computer vision library, and the publication list in the README includes the CVNets paper alongside later work such as MobileViT, MobileOne and FastViT. The README has a dedicated section explaining the relationship.

## Sources

- [apple/corenet on GitHub](https://github.com/apple/corenet)
- [Issues](https://github.com/apple/corenet/issues)
- [README](https://github.com/apple/corenet/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/apple-corenet