Foundation Lab: eine macOS- und iOS-Werkbank für Apples Foundation Models
A practical lab for building, testing, and evaluating apps with Apple's Foundation Models framework.
Auf einen Blick
- Was ist das?
- Foundation Lab bündelt Prompt, Konfiguration, Werkzeuge und Run-Protokolle in einer nativen App. Der Nutzen liegt im schnellen Durchlauf einzelner Beispiele, nicht in einer Produktionspipeline.
- Für wen ist es gedacht?
- Sinnvoll ist Foundation Lab für Swift-Entwickler mit Apple-Silicon-Mac und aktivierter Apple Intelligence, die einzelne Foundation-Models-APIs ausprobieren und Runs nachvollziehbar vergleichen wollen. Wer eine Pipeline für automatisierte Auswertung über viele Modelle braucht, ist hier falsch und sollte zuerst den externen FoundationModelsBench prüfen.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 6 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Swift, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welche Lücke die App schließt
Apples Foundation Models Framework liefert die Laufzeit, aber keinen Ort, an dem Prompt, Sampling-Parameter, Werkzeugliste und Antwortprotokoll zusammen sichtbar bleiben. Foundation Lab setzt genau dort an. Die README beschreibt die App als native Workbench für iOS und macOS, die Prompt, Konfiguration, Tools, Transkript und Run-Nachweise an einer Stelle hält und für APIs mit spezieller Oberfläche eigene Labs bereitstellt. Zwei Arbeitsweisen werden genannt: ein vorhandenes Rezept öffnen, eine Sache ändern, sofort ausführen. Oder eigene Prompts und Tools zusammenstellen, jeden Lauf inspizieren, Adapter vergleichen und reproduzierbare Belege exportieren. Adressat sind Swift-Entwickler, die das Framework nicht über einen Playground, sondern über eine echte App-Oberfläche kennenlernen wollen. Wer bereits eine Evaluationspipeline besitzt, gewinnt hier wenig.
Drei Ziele, ein gemeinsamer Datenfluss
Die App gliedert sich laut README in Library, Playground und Runs. Die Library listet 18 editierbare Rezepte, 14 geführte Labs, drei Workshops, gespeicherte Experimente und einen Workspace. Jeder Eintrag trägt eine Kennzeichnung, die bestimmt, wohin er öffnet. Ein Recipe landet im Playground und lässt sich dort bearbeiten, ausführen und speichern. Ein Guided Lab bekommt eine eigene Oberfläche für eine bestimmte API. Ein Workshop bündelt verwandte Schema-, Sprach- oder Xcode-27-Beispiele, ohne eine weitere oberste Ebene einzuführen. Der Workspace öffnet ein Spezialwerkzeug wie den Adapter-Vergleich. Diese Zuordnung ist der eigentliche Mechanismus: derselbe Lauf erzeugt Einträge in Runs, und Runs zeigt Status, Konfiguration, Transkript-Ereignisse, Tool-Aufrufe, Zeitmessung und Token-Verbrauch. Wer wissen will, warum eine Antwort so aussah, springt nicht zwischen Werkzeugen, sondern liest das persistierte Protokoll desselben Laufs.
Installation und die Grenze des Simulators
Der Einstieg ist knapp dokumentiert. Die README nennt drei Befehle: git clone des Repository, cd in das Verzeichnis, dann open FoundationLab.xcodeproj. Für den Kommandozeilenbau stehen zwei xcodebuild-Aufrufe bereit, jeweils mit dem Projekt FoundationLab.xcodeproj und dem Schema 'Foundation Lab'. Der eine zielt auf generic/platform=macOS, der andere auf generic/platform=iOS Simulator, beide mit CODE_SIGNING_ALLOWED=NO. Anforderungen: iOS 26.0+ oder macOS 26.0+, Apple Silicon für die Ausführung des On-Device-Modells, aktivierte Apple Intelligence für Live-Läufe, dazu Xcode 26.6 oder Xcode 27. Der wichtigste Satz steht am Ende des Abschnitts: Live-Modellausführung braucht ein kompatibles physisches Gerät, Simulator-Builds bleiben für Kompilierung und Oberflächenprüfung nützlich. Wer also im Simulator auf eine echte Antwort wartet, wartet vergeblich. APIs aus dem OS-27-SDK sind compiler- und availability-gesteuert, der Kern bleibt mit Xcode 26 nutzbar, Xcode 27 schaltet die neuesten Labs frei.
Werkzeuge, Schema-Zwang und der Bestätigungsschritt
Neun fertige Tool-Rezepte stammen laut README aus dem gemeinsamen Paket FoundationModelsTools: Wetter über Open-Meteo, Keyless Search1, Kontakte, Kalender, Erinnerungen, Standort- und Ortssuche, autorisierte HealthKit-Daten, Apple Music und Web-Metadaten. Sie öffnen im Playground und lassen sich dort kombinieren oder entfernen. Ein Detail ist wichtiger als die Liste: Werkzeuge, die Nutzerdaten verändern können, verlangen eine Bestätigung über einen app-eigenen Ablauf. Das ist keine Formalie, sondern der Punkt, an dem ein Modellaufruf die Kontrolle an die Oberfläche zurückgibt. Für strukturierte Ausgaben nennt die README @Generable-Modelle und @Guide-Einschränkungen, dazu dynamische Schemata, verschachtelte Objekte, Unions, Formulare und Rechnungsextraktion. RAG taucht mit Dokumentindizierung und semantischer Suche über LumoKit und VecturaKit auf. Ein HealthKit-Dashboard und ein Chat, der ausschließlich auf autorisierten Gesundheitsdaten beruht, sind ebenfalls dokumentiert.
Adapter-Vergleich: gleicher Prompt, zwei Sitzungen
Der Adapter-Vergleich ist der einzige Workspace, den die README ausführt. Auf macOS lässt sich ein .fmadapter-Paket importieren und derselbe Prompt einmal durch eine frische Basismodell-Sitzung und einmal durch eine Adapter-Sitzung schicken. Die Oberfläche zeigt beide Ströme und diagnostische Messungen zu Time-to-First-Token und Gesamtdauer. Das ist ein bewusst schmaler Zuschnitt: zwei Läufe, zwei Zahlenreihen, sonst nichts. Training und Export bleiben ausgelagert in das CLI fmas, das über eine virtuelle Python-3.11-Umgebung eingerichtet wird: python3.11 -m venv .venv-fmas, Aktivierung, dann python -m pip install -e Tools/AdapterStudio, gefolgt von fmas init, fmas setup und den Hilfeaufrufen fmas train-adapter --help sowie fmas export --help. Wer Adapter trainieren will, arbeitet also nicht in der App, sondern daneben. Das ist eine klare Trennung, aber auch eine Reibungsstelle.
Xcode 27, CLI und die Frage der Wartung
Mit Xcode 27 kommen zusätzliche Labs hinzu: PrivateCloudComputeLanguageModel, geteilte LanguageModel-Ausführung, Bildanhänge und Referenzen, explizite Tool-Calling-Modi, dynamische Profile und Reasoning-Steuerung, Transkript-Inspektion und History-Transformationen, Kontextbudget-Visualisierung sowie eigene Model Executors, darunter eine video-fähige Provider-Brücke. Eine Sonde unter Tools/ImageInputProbe soll die praktische Grenze des dekodierten Puffers im jeweiligen SDK messen. Das ist viel Oberfläche für ein Repository, und genau daraus entsteht der Wartungsaufwand: zwei Xcode-Versionen, availability-gesteuerte APIs, ein externes Paket für Werkzeuge und ein separates CLI. Die CLI afm liegt inzwischen im Repository rudrankriyam/Foundation-Models-Framework-CLI und wird über brew tap rudrankriyam/tap und brew install afm installiert. Laut README hält diese Auslagerung CLI-Releases unabhängig von den App-Releases. Das entlastet die App, verlagert aber auch einen Teil der Verantwortung auf ein zweites Projekt mit eigener Veröffentlichungsroutine. Die Lizenz ist MIT, was Weitergabe und Änderung erlaubt, solange Copyright- und Lizenzhinweis erhalten bleiben. Rechtliche Einordnung ersetzt das nicht.
Wo die App an ihre Grenzen stößt
Der harte Schnitt liegt bei der Hardware. Ohne Apple Silicon und aktivierte Apple Intelligence bleibt nur Kompilieren und Klicken im Simulator. Das schließt jeden aus, der auf Intel-Macs oder in einer CI ohne physisches Gerät arbeitet. Dazu kommt die Plattformbindung: iOS 26.0+ und macOS 26.0+ sind keine Untergrenze, die man nebenbei absenkt. Für Teams, die Foundation Models nur auf einem Teil ihrer Zielgeräte einsetzen können, taugt die App als Lernwerkzeug, nicht als Referenzimplementierung. Ein zweiter Punkt betrifft die Rolle im Werkzeugkasten. Die Runs-Ansicht speichert und zeigt, sie wertet nicht aus. Wer Kennzahlen über viele Prompts, Sicherheitsklassifikationen oder Tool-Nutzungsquoten über eine Serie hinweg braucht, bekommt hier Protokolle einzelner Läufe, keine Aggregation. Die README verweist für Qualität, Safety, Tool-Use und On-Device-Messungen auf das externe Projekt FoundationModelsBench. Das ist die ehrlichere Aufteilung: Foundation Lab ist das Cockpit, nicht das Prüfstand-Skript.
Wann man besser zu FoundationModelsBench greift
FoundationModelsBench ist das naheliegende Gegenstück, und der Unterschied liegt im Ansatz, nicht im Umfang. Foundation Lab ist interaktiv: ein Mensch ändert einen Parameter, startet einen Lauf, liest das Transkript. FoundationModelsBench ist als externes Projekt für Qualitäts-, Safety-, Tool-Use- und On-Device-Messungen beschrieben, also für wiederholbare Auswertung statt für Einzelbeobachtung. Wer eine Regressionsprüfung vor einem Release braucht, wird mit dem Adapter-Vergleich nicht weit kommen, weil dort zwei Sitzungen gegenüberstehen und keine Serie. Umgekehrt ist ein Benchmark-Harness kein Ort, um eine neue API zum ersten Mal anzufassen. Beide Werkzeuge liegen im selben Umfeld, und die README behandelt sie ausdrücklich als getrennte Oberflächen. Diese Trennung sollte man beim Einstieg ernst nehmen, sonst baut man sich eine Auswertung auf einer Ansicht, die dafür nicht gedacht ist.
Redaktionelles Fazit
Sinnvoll ist Foundation Lab für Swift-Entwickler mit Apple-Silicon-Mac und aktivierter Apple Intelligence, die einzelne Foundation-Models-APIs ausprobieren und Runs nachvollziehbar vergleichen wollen. Wer eine Pipeline für automatisierte Auswertung über viele Modelle braucht, ist hier falsch und sollte zuerst den externen FoundationModelsBench prüfen. Vor dem ersten Klonen lohnt der Blick in die Projektdatei: welches Schema tatsächlich existiert, ob Xcode 26.6 oder 27 installiert ist und ob ein physisches Gerät für Live-Läufe bereitsteht.
Community-Notizen