Apple Foundation Models: Was Indie-Mac-Entwickler mit On-Device-KI machen können

Etwa drei Jahre lang musste jeder Indie-Entwickler, der „KI-Features" ausliefern wollte, dieselbe unangenehme Entscheidung treffen. Entweder eine OpenAI- oder Anthropic-Rechnung zahlen, die linear mit den Nutzern skaliert, oder KI-Features komplett weglassen. Die Mathematik für eine Einmalkauf-App war brutal. Ein paar Cent pro Nutzer pro Monat zerstört die Marge einer $9.99-Lifetime-App innerhalb von Monaten.

Apples Foundation-Models-Framework, auf der WWDC 2025 angekündigt und in macOS 26 (Tahoe) enthalten, ändert die Mathematik. Das Framework gibt Entwicklern programmatischen Zugang zu demselben On-Device-Sprachmodell, das Apples Intelligence-Features auf dem Mac des Nutzers antreibt. Das Modell läuft lokal. Deine App zahlt nicht für Inferenz. Der Nutzer braucht keinen API-Schlüssel. Der Text verlässt das Gerät nie.

Dieser Beitrag ist eine praktische Tour durch das, was Indie-Entwickler tatsächlich mit dem Framework machen können, worin es nicht gut ist und was die architektonische Verschiebung für eine fokussierte Mac-App bedeutet.

Was du bekommst

Das Framework stellt eine LanguageModelSession bereit, die du mit Text ansprechen kannst. Das Modell antwortet mit Text und optional mit einem strukturierten Objekt, das du mit dem @Generable-Makro spezifizierst. Der Structured-Output-Modus ist der nützlichere für die meisten Apps, weil er dich sagen lässt „gib mir JSON zurück, das diesem Schema entspricht", anstatt freiform Text zu parsen.

Ein typischer Ablauf sieht so aus:

1. Eine Session mit System-Anweisungen erstellen, die die Aufgabe des Modells beschreiben.
2. Eine Nutzernachricht senden.
3. Die strukturierte Antwort lesen.
4. Die Antwort nutzen, um die App anzutreiben.

Das Ganze läuft in Millisekunden für kurze Prompts und ein paar Sekunden für lange. Es gibt keinen Netzwerkaufruf. Es gibt keinen API-Schlüssel. Es gibt kein Rate-Limit über das hinaus, was das Gerät selbst aufrechterhalten kann.

Worin das Modell wirklich gut ist

Das On-Device-Modell ist klein im Vergleich zu einem state-of-the-art Cloud-Modell. Es ist nicht GPT-4. Es so zu behandeln führt zu Enttäuschung. Wo es glänzt, ist eine bestimmte Klasse von Aufgaben:

• Klassifikation. „Ist diese Zeichenkette ein Datums-Ausdruck oder nicht?" „Zu welcher der fünf Kategorien gehört diese Aufgabe?" Das sind Aufgaben, die das On-Device-Modell zuverlässig und schnell bewältigt.
• Strukturierte Extraktion. Bestimmte Felder aus einer Freitext-Eingabe ziehen. „Auf welche Tageszeit bezieht sich dieser Satz?" „Was ist das Verb in diesem Satz?" Der Structured-Output-Modus des Frameworks ist genau dafür gebaut.
• Kurzes Text-Umschreiben. Eine informelle Notiz in einen sauberen Titel umwandeln, einen Absatz in einem Satz zusammenfassen, die Grammatik in einem Entwurf korrigieren. Das Modell ist gut bei kleinen, abgegrenzten Texttransformationen.
• Ton-Änderungen. Einen Entwurf wärmer, prägnanter oder professioneller machen. Dieselbe Einschränkung: kurze Eingaben, abgegrenzte Ausgaben.

Das ist der Großteil dessen, was eine Produktivitäts-App tatsächlich braucht. Beachte, was nicht auf der Liste steht: Langform-Generierung, komplexes Denken, Weltwissen-Fragen, Code-Generierung. Das On-Device-Modell kann das, aber nicht so gut wie ein Cloud-Modell. Wenn das für dein Produkt zentral ist, brauchst du noch Cloud.

Worin das Modell nicht gut ist

Drei Klassen von Aufgaben, bei denen du etwas anderes nehmen solltest:

1. Langer Kontext. Das On-Device-Modell hat ein kleineres Kontextfenster als ein Cloud-Modell. Ein 50-Seiten-Dokument hineinzufüttern und nach Analyse zu fragen wird nicht gut gehen. Füttere stattdessen den relevanten Auszug.
2. Offenes kreatives Schreiben. Es kann kurzes kreatives Schreiben machen, aber du wirst den Unterschied im Vergleich zu einem Frontier-Cloud-Modell bemerken. Wenn deine App ein Schreibassistent für Romanautoren ist, ist das wahrscheinlich nicht dein Modell.
3. Aufgaben, bei denen der Nutzer State-of-the-Art-Qualität erwartet. Wenn deine Nutzer deine Ausgabe mit ChatGPT vergleichen und entsprechend urteilen werden, wirst du verlieren. Das Modell ist ausgezeichnet für unsichtbare Hilfsfunktionen, weniger für Aufgaben, bei denen die KI das sichtbare Produkt ist.

Die richtige Rahmung lautet: Verwende das On-Device-Modell, um die App im Hintergrund intelligenter zu machen, nicht um das sichtbare Produkt zu sein.

Was das für Indie-Preisgestaltung bedeutet

Die interessanteste Konsequenz des On-Device-Modells ist die Preisgestaltungs-Implikation. Für den Großteil der letzten drei Jahre war der Standardrat für Indie-Entwickler, die KI-Features ausliefern, „du musst ein Abonnement berechnen, weil Inferenzkosten real und wiederkehrend sind." Dieser Rat war korrekt.

Er ist nicht mehr korrekt für Apps, bei denen On-Device-Intelligenz ausreicht. Der eigentliche Grund, warum eine Einmalkauf-App keine KI ausliefern konnte, waren die wiederkehrenden Kosten. Wenn die wiederkehrenden Kosten null sind, bricht das Modell zusammen. Du kannst KI-Features in einer Einmalkauf-App ausliefern und nicht pleite gehen.

Das ist ein großer Deal für die kleine Welle von Indie-Mac-Apps, die versuchen, das Einmalkauf-Modell wiederzubeleben. Wir haben über den breiteren Trend geschrieben, aber das KI-Stück ist einer der tatsächlichen technischen Gründe, warum es 2026 funktioniert.

Wie man anfängt

Das Framework ist Teil des Standard-Apple-SDK auf macOS 26. Es gibt keinen separaten Download. Es gibt keinen API-Schlüssel. Es gibt kein Konto zu erstellen. Füge import FoundationModels zu einer Swift-Datei hinzu, erstelle eine LanguageModelSession, sende einen Prompt, lies die Antwort.

Das Modell ist auf Apple-Silicon-Macs verfügbar, die die Systemanforderungen für Apple Intelligence erfüllen. Ältere Intel-Macs bekommen das Framework nicht, also braucht deine App eine Fallback-Strategie, wenn du sie unterstützen möchtest. Für die meisten Indie-Mac-Apps, die heute ausgeliefert werden, sind eine Verfügbarkeitsprüfung und ein Graceful-Degradation-Pfad genug. Der Nutzer ohne das Modell bekommt die Regex-basierte Version des Features; der Nutzer mit dem Modell bekommt die intelligentere Version.

Wie das in TodoBar aussieht

TodoBar nutzt das Framework als Fallback für natürlichsprachige Datumsanalyse. Der schnelle Pfad sind reguläre Ausdrücke, die etwa 90 % der Datums-Phrasen in unter einer Millisekunde abfangen. Wenn der Regex-Pfad scheitert, macht das On-Device-Modell einen Versuch, mit einer typischen Latenz von etwa 50 Millisekunden, und gibt eine strukturierte Klassifikation dessen zurück, was der Nutzer meinte. Wir haben die vollständige Pipeline im Datumsanalyse-Beitrag beschrieben.

Das Modell ist für den Nutzer unsichtbar. Er weiß nicht, dass es da ist. Er bemerkt nur, dass „in ein paar Stunden" genauso funktioniert wie „in 2 Stunden". Das ist das Gefühl guter On-Device-KI.

Es ist auch der Grund, warum eine $9.99-Einmalkauf-App ein Feature ausliefern kann, das vor einem Jahr ein Abonnement erfordert hätte. Die Mathematik stimmt endlich.