Foundation Lab has an iOS 26 floor, four repositories, and a Python virtual environment

Eighteen recipes, fourteen labs, three workshops and one workspace

The Library is the entry point and it is counted rather than described, which is useful. Eighteen editable recipes, fourteen guided labs, three workshops, plus whatever experiments you have saved and a single workspace. What matters is that those four kinds are not variations on one screen. A recipe opens in the Playground and can be edited, run and saved, so it is the fast path: open a working example, change one variable, run it. A guided lab instead uses a focused interface built for one specific API, which is what you want when the thing you are learning needs its own controls. A workshop groups related schema, language or new-compiler examples, and the page is explicit that it exists so those do not become another top-level destination. A workspace opens a dedicated tool, and the one that ships is adapter comparison.

The floor is iOS 26, and the newest labs move with the compiler

The requirements are four lines and the fourth is the one that matters for planning. You need iOS 26 or later, or macOS 26 or later. You need Apple Silicon, because the model runs on device. You need Apple Intelligence turned on for live runs. And you need either Xcode 26.6 or Xcode 27. The page then explains why both are supported rather than picking one: APIs introduced with the newer operating system SDK are compiler- and availability-gated, so the core application stays usable with the older Xcode while the newer one exposes the newest labs. In practice that means the app you build is not the same app on both toolchains. A team pinned to one version sees a smaller lab set, and the features that are missing are not behind a runtime check, they are not compiled at all.

What the newer compiler adds is a specific list rather than a general upgrade: a private cloud compute language model type, shared language model execution, image attachments and references, explicit tool-calling modes, dynamic profiles and reasoning controls, transcript inspection and history transforms, context-budget visualisation, and custom model executors including one that can take video. There is even a probe in the tools directory whose stated purpose is to measure where the current SDK's practical decoded-buffer boundary sits for image input, which is the kind of measurement that only exists to be redone because the limit moves between releases.

A simulator build compiles, and then cannot run the model

The command line section gives you two build invocations, one for a generic macOS destination and one for a generic iOS Simulator destination, both with code signing turned off. The project opens the same way it has for everyone else:

git clone https://github.com/rudrankriyam/Foundation-Models-Framework-Lab.git
cd Foundation-Models-Framework-Lab
open FoundationLab.xcodeproj

Then the sentence that decides how you will actually use it: live model execution requires a compatible physical device, while simulator builds remain useful for compilation and interface validation. That is an honest split and it is worth taking at face value. This is a workbench whose value is in its transcripts and its token counts, and you cannot get a single one of those from a simulator. Combined with the Apple Silicon and Apple Intelligence requirements, the practical order is: build and fix the interface on the simulator, then move to a device signed normally and with the feature switched on before you believe anything about output quality.

Nine tool recipes, including a web search with no key

The built-in tools come from a shared package and there are nine of them, and the list is the honest description of what the app can reach: weather through a public forecast service, a web search that needs no API key, contacts, calendar, reminders, location and place search, authorised health data, music, and web page metadata. Two design points are stated. The recipes open in the Playground, so you can combine them or take them out rather than accepting a fixed toolset. And any tool that can change user data requires confirmation through a workflow the app owns, which is the correct pattern for a workbench that will be handed to someone unfamiliar with it. The practical caveat is that five of the nine sit behind operating system permission prompts, so a clean simulator run tells you almost nothing about whether the tools will work.

The applied-project list sits alongside the tools as a separate capability, and it is where the framework's own types appear. Structured output uses the generative model macro and its guidance macro, with dynamic schemas, nested objects, unions, form filling and invoice extraction as the worked examples. There are multilingual sessions with a way to inspect which languages are supported, retrieval-augmented document indexing and semantic retrieval through two named third-party libraries, and a health dashboard whose chat is grounded only in authorised health records rather than in the model's own knowledge.

The transcript, context and history packages live in another repository

The repository map is the section to read before you clone, because it shows that one product is spread across four. This repository holds the native application and its UI-independent core, which carries requests, results, use cases, providers and experiment models. The package handling transcripts, context, history and the system tools is in a separate repository under a different owner entirely, and both of the project's Swift packages are defined there. The command line tool and the benchmarking suite, which covers quality, safety, tool use, on-device behaviour and the private cloud path, are each released from their own standalone repository. The page says so itself: this repository keeps the app, the app runtime and the adapter tooling, and the other two are developed and released elsewhere. Anyone vendoring this needs to decide which of the four they are actually taking.

The adapter loop needs a second language toolchain

Adapter comparison is the most interesting feature and it has a cost. On macOS you import a package with a specific file extension and run the same prompt twice, once through a fresh base-model session and once through an adapter session, and the workspace shows both response streams side by side with time-to-first-token and total duration measurements. Training and exporting an adapter is not in the app. That stays with a companion command line tool, and its setup is a Python virtual environment created with a specific interpreter version, an editable install of a Python package that lives inside this Swift repository, and then four subcommands for initialising, setting up, training and exporting:

python3.11 -m venv .venv-fmas
source .venv-fmas/bin/activate
python -m pip install -e Tools/AdapterStudio
fmas init
fmas setup

So the adapter story crosses from Swift into Python and back, and the repository carries the Python package to make that possible. The same split runs through the command line interface: it ships from its own standalone repository, installs through a package manager tap, and uses the same public package as the app, which is why the page says its releases are kept independent from the app's.

Three releases in one weekend, then three months of commits

The release history is short and lopsided. Version 1.0.0 was tagged on 2026-06-20, 1.1.0 the next day, and 1.2.0 the day after that, so the entire published history is three tags across a single weekend in June. The most recent push to the default branch is 2026-09-18, nearly three months later, with no new tag. The tags also carry no version prefix, which is a small thing that breaks a script written against the other convention. For anyone tracking this project, the practical consequence is that the branch is where the work is and the tags are a starting point, not a description of the current state. The root layout reinforces that it is a working repository rather than a published package: two separate lint configurations, two directories whose names contain a space, two agent instruction files, and two loose markdown documents sitting beside the readme.

Editorial conclusion

Foundation Lab fits someone building an app on Apple's on-device model who wants to see prompts, tools, transcripts and token counts in one place and to keep an exportable record of every run. It does not fit you if your team is on one Xcode version, because the lab set changes with the compiler, or if you are validating on a simulator, because the model itself needs a physical device. Before you plan around it, work out which of the four repositories you actually need, since the transcript and context packages and the benchmarking suite are not here, and decide whether a Python virtual environment inside a Swift repository is a toolchain you want to maintain.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. rudrankriyam/Foundation-Models-Framework-Lab on GitHub