Apple lowers training friction

Apple has spent two years building AI features into its own apps. The more important shift came later, when it started handing those same building blocks to outside developers. At WWDC 2025, Apple introduced the Foundation Models framework, which lets apps call the on-device language model behind Apple Intelligence for text generation, structured output, tool use, and session-based context on iPhone, iPad, Mac, and Vision Pro. The point was not to win a benchmark race. It was to make local AI feel like another system service, as ordinary to use as speech recognition or Core ML (developer.apple.com, developer.apple.com). That already lowered the barrier to shipping AI on Apple platforms. A developer no longer had to host a model, manage GPUs, or send user data to a cloud API just to add summarization or text extraction. Apple’s framework exposes the system model through native APIs, includes guided generation for typed Swift outputs, and supports tool calling so the model can reach into app code and local data when it needs facts the base model does not know (developer.apple.com, developer.apple.com). Once that plumbing was in place, the next bottleneck was obvious. Developers could use Apple’s model, but they still could not easily teach it app-specific behavior. Apple has now opened that door too. Its Foundation Models adapter training toolkit lets developers train a custom adapter that teaches the on-device model “new skills specific to your app,” then package that adapter for use inside the Foundation Models framework (developer.apple.com). Apple’s own documentation is blunt about what this is for: not retraining the whole model, but specializing it for a domain or task with a separate add-on package (developer.apple.com). That is the step the video is reacting to. Fine-tuning on Apple’s stack no longer looks like a research project. It looks like a workflow. The catch is that Apple has not made training disappear. It has hidden the worst parts. The adapter toolkit uses Python and PyTorch, and Apple says developers need familiarity with machine-learning training to use it (developer.apple.com). Each adapter is tied to one specific system model version, which means developers must retrain for every new base model Apple ships. Apple says that model changed again with iOS 26.4, iPadOS 26.4, macOS 26.4, and visionOS 26.4, and it tells developers to test prompts and maintain behavior across versions (developer.apple.com, developer.apple.com). The friction is lower, not gone. Apple moved it from infrastructure to lifecycle management. That still matters because lifecycle management is a much cheaper problem than training from scratch. Apple’s open-source MLX framework, built by Apple machine learning researchers for Apple silicon, already made it unusually practical to run and fine-tune open models on a Mac using unified memory and hardware optimized for local workloads (github.com, machinelearning.apple.com). Its companion package, MLX LM, supports low-rank and full fine-tuning, quantized models, and one-command access to a large catalog of Hugging Face-compatible models on Apple hardware (github.com, github.com). Apple did not invent low-rank adaptation. What it did was make the path from “I have a small dataset” to “my app has a specialized model behavior” much shorter on machines many developers already own. That changes where the hard part lives. If the base model is a system resource and customization is packaged as an adapter, the scarce asset is no longer raw model access. It is the quality of the task data, the care of the evaluation loop, and the discipline to keep adapters matched to the right OS model version. Apple’s own deployment guidance makes that concrete: adapter files are large, 160 MB or more, should not be bundled directly in the app, and are meant to be delivered on demand through asset packs or a server (developer.apple.com). The glamorous part is training. The product part is shipping the right 160-megabyte file to the right device at the right time.