Claude in Apple Foundation Models integrieren

 (platform.claude.com)
1 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Ein Swift-Paket, das Claude als serverseitiges Modell an Apples Foundation Models Framework anbindet, sodass Entwickler Claude über denselben Codepfad wie Apples On-Device-Modelle aufrufen können
  • Dank des von Apple auf der WWDC 2026 eingeführten LanguageModel-Protokolls wird eine hybride Architektur mit nur einer Standard-API möglich: Prototyping mit dem On-Device-Modell, komplexe Aufgaben gehen nur an ein Cloud-Modell
  • Der Kernpunkt ist die Austauschbarkeit von Providern – ohne die Session-Logik anzufassen, kann man allein durch den Wechsel der Swift-Package-Abhängigkeit zwischen Apple, Claude und Gemini wechseln
  • Das von Anthropic unter Apache 2.0 veröffentlichte Paket ist der erste praktisch funktionierende Beleg für die Idee, dass sich „jedes Backend anbinden lässt“
  • Anfragen gehen direkt aus der App an die Claude API, Apple ist nicht im Übertragungsweg, sieht also weder Prompts noch Antworten; die Kosten werden ebenfalls direkt dem Anthropic-Konto berechnet

Warum das wichtig ist

  • Um Sprachmodelle in iOS-Apps einzubinden, waren bisher ein separates Cloud-API-Konto, Schlüsselverwaltung, tokenbasierte Abrechnung und die Übertragung aller Prompts außerhalb des Geräts nötig; auf der WWDC 2026 hat Apple dieses langjährige Problem gelöst
  • Das Foundation Models Framework wurde so erweitert, dass On-Device-Modelle von Apple Intelligence, Private Cloud Compute und Third-Party-Clouds wie Claude oder Gemini alle über eine einzige native Swift-API aufgerufen werden können
  • Anthropic hat ein Swift-Paket veröffentlicht, das dieses neue Protokoll implementiert. Es dient dazu, von Apples On-Device-Modell an Claude zu übergeben, damit komplexere Workflows verarbeitet werden

Was sich für Entwickler ändert

  • Provider-Wechsel ohne Codeänderungen

    • Nachdem eine App mit Apples On-Device-Modell prototypisiert wurde, lassen sich komplexe Anfragen an Google Gemini oder Anthropic Claude weiterleiten oder zwischen ihnen umschalten, indem lediglich die Swift-Package-Manager-Abhängigkeit aktualisiert wird – ohne Änderungen an der Session-Logik oder dem restlichen App-Code
    • Das On-Device-Modell bleibt für schnelle lokale Aufgaben wie Zusammenfassung oder Extraktion zuständig; nur wenn mehrstufiges Reasoning, Codegenerierung, Websuche oder Code-Ausführung nötig sind, erfolgt die Übergabe an Claude
    • In beiden Fällen wird dieselbe LanguageModelSession-API verwendet, sodass der Wechsel allein durch den Austausch des model:-Arguments erfolgt

  • Typbasierte Übergabe

    • Nach dem Hinzufügen zum Projekt und der Anmeldung mit einem Anthropic-API-Schlüssel kann die typisierte Ausgabe von Apples On-Device-Modell an eine Claude-Anfrage übergeben werden; das Paket verarbeitet dann Streaming, Tool-Aufrufe und strukturierte Antworten wieder bis in SwiftUI-Views hinein
    • Die Nutzung ist so einfach, dass sich mithilfe der Guide-Generierung mit nur drei Zeilen Code typisierte Swift-Werte zurückgeben lassen

Datenschutz- und Kostenstruktur

  • Anfragen werden direkt aus der App an die Claude API gesendet, Apple ist nicht im Anfragepfad und sieht weder Prompts noch Antworten
  • Die Nutzung wird zu den Standard-API-Preisen direkt dem Anthropic-Konto berechnet
  • Die App entscheidet pro Session selbst, ob Claude oder Apples On-Device-Modell verwendet wird

Das größere Bild

  • Apple will das Foundation Models Framework, die 2025 eingeführte native Swift-API für On-Device-Modelle, in diesem Sommer als Open Source freigeben; mit dem neuen LanguageModel-Protokoll können Apples eigene Modelle ebenso wie Remote-Provider hinter einer einzigen Swift-API eine LanguageModelSession betreiben
  • Als Beispiel für dieses „jedes Backend ist anschließbar“ konkretisiert Anthropics ClaudeForFoundationModels das Adapter-Pattern
  • Mit dem System der Dynamic Profiles ermöglicht Apple Apps, mitten in einer Session Modelle, Tools und Anweisungen auszutauschen, und positioniert dies als Grundlage für Multi-Agent-Workflows
  • Diese Integration befindet sich jedoch noch in der Beta und erfordert iOS, iPadOS, macOS, visionOS, watchOS 27 sowie Xcode 27; bis zur finalen Veröffentlichung sind API-Änderungen möglich

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 시간 전
Hacker-News-Kommentare

  • Apple macht LLMs zur Commodity, während das Unternehmen die User Experience kontrolliert
    Als Hardware-Firma ist das eine Strategie, weiterhin die besten Geräte für die AI-Nutzung zu verkaufen, und sie scheint eine gute Entscheidung zu sein

    • Vielleicht hatte Benedict Evans am Ende doch recht. Frontier-Modelle wirken immer mehr wie Telekommunikationsanbieter in den 90ern
      Sie investieren Milliarden in Infrastruktur, aber der Wert wird von anderen Unternehmen in den darüberliegenden Schichten abgeschöpft
    • Das ist zwar etwas getrennt von der Formulierung Kontrolle der User Experience, aber das ist mein Lieblingsresultat von AI. Jahrzehntelang haben Firmen ihre Dienste eingemauert und den Nutzern miserable UIs aufgezwungen, und in den letzten 12 Monaten hat plötzlich alles MCP bekommen und lässt sich über eine Chat-Oberfläche in der Kommandozeile nutzen
      Firmen, die sich nicht anpassen, werden von AI-basierten DIY-Web-Scrapern der Nutzer so lange verprügelt, bis sie sich am Ende fügen müssen
    • Ich bin nicht sicher, ob die besten Geräte für die AI-Nutzung hier die richtige Formulierung ist. Laufen diese Modelle nicht immer noch serverseitig?
    • Dass AI am Ende auf Betriebssystemebene eingebaut wird, war schon seit einigen Jahren klar. Apple hat das auch bereits erkannt, als Apple Intelligence erstmals vorgestellt wurde
      Formulierungen wie LLMs zur Commodity zu machen passen schon, aber das hier ist eine nutzerseitige Funktion, die seit Jahren verfeinert wird
    • Jetzt muss nur noch die Hardware zur Commodity werden

  • Ein Swift-Paket also, das es erlaubt, Claude im Apple's Foundation Models framework als serverseitiges Sprachmodell zu verwenden — ich hatte eher die umgekehrte Richtung erwartet. Ich hatte gehofft, dass die bestehenden Funktionen von Claude Code somehow lokal auf der Neural Engine meines Laptops laufen würden
    Mit einem M2 und 8 GB RAM ist das wohl nur Wunschdenken, aber für einen Moment hatte ich Hoffnung

    • Schau dir diese WWDC-Session an. Natürlich kann das nicht mit Frontier-Modellen konkurrieren, und 8 GB sind wohl auch viel zu wenig, aber Apple hat MLX + OpenCode tatsächlich demonstriert
      https://developer.apple.com/videos/play/wwdc2026/232/
      https://www.youtube.com/watch?v=wykPErJ8M-8
    • Wenn man OpenCode oder Pi mit SSD-Streaming nutzt, wäre technisch gesehen der volle Funktionsumfang möglich. Es wäre nur unerträglich langsam
    • Die meisten Frontier-Coding-Modelle scheinen zwischen 300 GB und 1 TB zu brauchen, um ihren vollen Funktionsumfang zu nutzen
    • Claude Code kann über Umgebungsvariablen mit buchstäblich jedem beliebigen Endpoint sprechen, solange eine kompatible API vorhanden ist
    • Wenn die Cloud tatsächlich das private iCloud des Nutzers wäre, fände ich das in Ordnung. Wenn der Nutzer die Kosten trägt und es in der Nähe der Apple-Server läuft, auf denen ohnehin iPhotos gespeichert werden, könnte das eine sehr elegante Lösung sein
      Tatsächlich bekommt man aber Claude, und niemand weiß, wo das gehostet wird. Es könnte ein X-AI-Rechenzentrum sein, irgendwo bei Amazon oder sonst wo — niemand weiß es

  • Das ist nicht nur für Claude gedacht. Entwickler können auch Apps bauen, die Googles serverbasierte Gemini-Modelle aufrufen
    Auf der WWDC hat Apple angekündigt, das Foundation Models framework für Cloud-Modellanbieter von Drittanbietern zu öffnen. Ab iOS 27, macOS 27, iPadOS 27, visionOS 27 und watchOS 27 können Modellanbieter das neue öffentliche LanguageModel-Protokoll implementieren, um eine gemeinsame Schnittstelle für Modellinferenz bereitzustellen. Google hat über das Firebase Apple SDK ermöglicht, Gemini-Modelle im Foundation Models framework zu verwenden
    Dadurch wird eine vollständig native Entwicklungserfahrung möglich. Cloud-gehostete Gemini-Modelle können über dieselbe API direkt an das Foundation Models framework angebunden werden, und On-Device-Apple-Modelle sowie cloud-gehostete Gemini-Modelle liegen hinter derselben gemeinsamen API-Oberfläche, sodass sich je nach Anwendungsfall leicht zwischen lokaler und Cloud-Inferenz wechseln lässt
    https://blog.google/innovation-and-ai/technology/developers-...

    • Das Entscheidende ist, dass Apple die OpenAI-kompatible API einfach in language model protocol umbenannt hat, und bevor wir von dieser furchtbar langen Bezeichnung verflucht werden, sollten sich jetzt besser alle schnell darum scharen

  • Es ist zwar erfreulich, dass Apple eine solche Abstraktion eingeführt hat, aber die Hauptsorge betrifft die lokalen Modelle.
    Selbst wenn man zum Beispiel Gemma4 verwenden möchte, bläht sich aus Nutzersicht das Handy unnötig auf, wenn 10 Apps dasselbe Modell jeweils separat herunterladen.
    Ich habe noch nicht verstanden, ob Apple eine Möglichkeit bietet, damit mehrere Apps dasselbe Modell auf dem Gerät verwenden können. Das müsste ohne komplizierte Namespace- oder Berechtigungstricks möglich sein.
    Ich habe nichts gesehen, was darauf hindeutet.

    • Ich denke, genau das will Apple vermeiden. Wenn Intelligenz auf dem Gerät gebraucht wird, lautet der Vorschlag sinngemäß: „Das Modell, das bereits auf dem Gerät ist, ist am besten“, und wenn etwas Spezifischeres nötig ist, sind Adapter, also Fine-Tuning/LoRA, die beste Lösung.
      Als die Modelle auf dem Gerät noch weit zurücklagen, war das falsch, langfristig könnte es aber weiterhin stimmen.
      Mehrere Apps, die ich nutze, könnten Gemma 4 E4B benötigen, aber ich verwende Dutzende Apps und Entwickler können aus Hunderten Modellen wählen. Ein gemeinsamer Cache würde bei Überschneidungen etwas Speicher sparen, aber das Kernproblem bleibt. Wenn jede App ihr Modell auswählt, explodieren Festplatten- und Memory-Swapping-Probleme.
      Wahrscheinlich ist es besser, wenn der Gerätehersteller einen Standard einbaut. Das heißt nicht, dass andere Modelle verhindert werden sollten, aber ein gemeinsamer Standard könnte für 99 % der Apps sowohl für Entwickler als auch für die Nutzererfahrung die beste Lösung sein.
      Dass ein Modell bereits im Speicher geladen ist, bringt den größten Performancegewinn, und ein Standardmodell bleibt mit viel höherer Wahrscheinlichkeit warm.
      Das „beste Modell“ ist in der Regel das „beste Modell für dieses Gerät“, wenn man RAM und Rechenaufwand berücksichtigt. Entwickler können nicht alle Geräte testen, Apple aber schon und wird es auch tun.
      Jedes Modell muss auf die Hardware abgestimmt optimiert werden. Es ist wichtig, was auf ANE, Metal oder CPU läuft, und das Standardmodell wird optimiert sein.
      Wenn ein angepasstes Modell nötig ist, ist LoRA wahrscheinlich die beste Lösung. Es ist etwa 30 MB groß und bietet alle genannten Vorteile.
      Man kann argumentieren, dass der Standard austauschbar sein sollte, aber das ist eher ein Linux-artiges Ideal als etwas, das wir tatsächlich sehen werden. Außerdem gibt es reale Nachteile. Ob beabsichtigt oder nicht: Prompts werden auf das Zielmodell hin optimiert, daher kann das Ersetzen des System-Standardmodells die Qualität aller Apps verschlechtern.
    • Das wäre eine gute Gelegenheit für Apple, ein universelles Protokoll für eindeutige Modell-IDs und gemeinsamen Speicher bereitzustellen, damit Entwickler Modelle registrieren können.
    • Siehe „Bring an LLM provider to the Foundation Models framework“.
      https://developer.apple.com/videos/play/wwdc2026/339
    • Apps können über dasselbe Framework und dieselbe API das vom System bereitgestellte On-Device-Modell nutzen. Es gibt aber keinen Mechanismus, um doppelte benutzerdefinierte Modelle zwischen Apps zu vermeiden.
    • Genau das sind foundation models. Auch Androids AICore nutzt intern Gemma, und Apps fragen dann das LLM an und bekommen Antworten zurück, statt eigene Modelle zu bündeln.

  • Ich frage mich, ob Apple Entwickler dazu bringen will, LLMs über seine eigene API-Abstraktionsschicht zu verwenden. Das könnte dazu dienen, später einen reibungslosen Wechsel zu ermöglichen, falls Apple ein eigenes LLM herausbringt.
    Ich meine gehört zu haben, dass Apple viel Geld in Training steckt und dass das irgendwie mit Siri oder der aktuellen Apple AI zusammenhängen könnte. Oder ist es einfach nur eine Komfortfunktion für Entwickler, oder steckt noch etwas anderes dahinter?

    • Apple hat einige ziemlich clevere Mechanismen zum Schutz von Nutzerdaten. Ich musste mich vor Kurzem mit App-Tracking beschäftigen, und die Art, wie Benutzerdetails vor dem Melden von Tracking-Ereignissen an Drittplattformen in mithilfe von SKAN und Differential Privacy anonymisierten Kohorten verborgen werden, war besser durchdacht, als ich erwartet hatte.
      Wenn einem Datenschutz wichtig ist, hat es einen Wert, dass Apple dazwischen sitzt.
    • Das ist Unterstützung für ein neues Framework, das in reality/mac/iPad/watch/tv/iOS 27 enthalten ist. Sie haben gesagt, dass es später in diesem Jahr als Open Source veröffentlicht wird, daher dürfte es sich auch nutzen lassen, wenn man Swift im Backend einsetzt.
      Der Kern dieses Frameworks ist, dass man mit derselben API sowohl auf integrierte On-Device-Modelle, auf Apples gehostetes Online-Modell Private Cloud Computer als auch auf einen eigenen Shim für beliebige gehostete Online-Modelle zielen kann.
      Damit kann man Aufrufe über die System-API dynamisch an verschiedene Modell-/Anbietertypen routen, ohne eine eigene Abstraktionsschicht nach dem Muster „Das hier lokal, das dort mit Claude“ bauen oder Anthropic-/OpenAI-API-Integrationen direkt anbinden zu müssen.
      Es bietet mehrere Komfortfunktionen und Besonderheiten, etwa Tool-Calling an einer Stelle zu abstrahieren oder innerhalb einer Sitzung Anbieter oder Modell dynamisch zu wechseln und dabei dasselbe transcript fortzuführen.
    • Zynisch oder realistisch betrachtet wirkt diese Abstraktionsschicht wie Apples Weg, dafür zu sorgen, dass Nutzer die Funktion Apple Intelligence zuschreiben, auch wenn das eigentliche LLM von einer anderen Firma bereitgestellt wird.
    • Das ist eine düstere Lesart, aber nicht völlig unberechtigt. Für Apple wird es einfacher, Zahlungen für von anderen Firmen bereitgestellte Modelle abzuwickeln, und wenn Apple wollte, könnte es auch Daten darüber sammeln, wie Nutzer Drittmodelle verwenden, um Datensätze zum Training eigener Modelle aufzubauen.
      Da diese API nur auf Apple-Geräten nutzbar ist, hat sie außerdem den Effekt, den Markt weiter zu fragmentieren und Nutzer stärker einzubinden, weil Entwickler dieses System verwenden müssen, um unter iOS ordentlich zu funktionieren.
    • Über dieses Framework gibt es bereits On-Device-Modelle, die Entwickler nutzen können. Claude ist nur ein weiteres Modell, das dort hinzukommt.

  • Es scheint, als bereite sich Apple darauf vor, dass die eigenen On-Device-Modelle besser werden, und wenn man bedenkt, dass nun Zugriff auf Gemini möglich ist, ergibt das Sinn
    Wenn Entwickler ihren gesamten Code für Aufrufe externer LLMs darüber schreiben, kann man später, wenn Apples Modelle leistungsfähiger werden und mehr Anwendungsfälle abdecken, die einzelnen Aufrufstellen leicht umstellen. Das verbessert dann die User Experience der App und senkt außerdem die Abrechnungskosten der Entwickler, an denen Apple keine Gebühren verdient

    • Anders gesagt: Da sich damit kein Geld verdienen lässt, ist es eher unwahrscheinlich, dass das passiert. Apple wäre wohl besser damit beraten, neue AI- und AI-lite-Tarife einzuführen, die Leute abonnieren können
      Apple ist ein Unternehmen, und wir alle wissen, worauf Unternehmen achten, daher wirkt die Utopie lokal auf dem Handy laufender Modelle eher unwahrscheinlich
    • Ich verstehe nicht, wie die Nutzung von Gemini dazu führen soll, dass die On-Device-Modelle besser werden
    • User Experience ist nur ein anderes Wort für Ökosystemaufbau, und genau das kann Apple besser als die Konkurrenz. Dass sie dazu auch noch passende Hardware machen, schadet ebenfalls nicht
      Microsoft und Nvidia tun sich nicht ohne Grund zusammen

  • Ich frage mich, wie man das in Software, die man an Nutzer ausliefert, tatsächlich einsetzen soll. Nutzer direkt dazu zu bringen, selbst einen API-Schlüssel zu erstellen und einzugeben, ist für eine gute User Experience eine viel zu hohe Hürde

    • Die noch größere Hürde ist, normalen Nutzern, also Nicht-Entwicklern, tokenbasierte Preise plausibel zu machen
      „Geld für eine Frage zu zahlen, ohne zu wissen, wie viel sie kostet, möglicherweise nicht die gewünschte Antwort zu bekommen und für mehr Nutzung noch mehr zahlen zu müssen“ ist für die meisten Menschen, die keine Spieler sind, kein attraktives Modell. Noch schwerer vermittelbar ist für Durchschnittsnutzer, dass ein „Danke“ am Ende eines langen Gesprächs wegen des Kontexts teuer sein kann
      Es hilft auch nicht, dass die Tokenkosten wie ein Jo-Jo rauf und runter gehen. Normale Nutzer brauchen feste Kosten und wollen ihre Energie nicht darauf verwenden, dem AI-Markt ständig hinterherzulaufen. Probleme wie „Letzten Monat hat mein Abo viel länger gereicht“ sind ebenfalls keine gute Entwicklung
      In den meisten Fällen halte ich Apples Einschätzung, dass lokale LLMs die Zukunft sind, für richtig
    • Absolut. Ich betreibe allihat.com, und es scheint immer noch die einzige Safari-Erweiterung zu sein, die mit Claude kommuniziert, und die Nachfrage ist durchaus da. Aber die Nutzer müssen ihren verdammten Claude-API-Schlüssel selbst eingeben
      Ich verstehe auch die Anthropic-Nutzungsbedingungen noch nicht vollständig. Man kann zwar so etwas wie setup-token Set up a long-lived authentication token (requires Claude subscription) eingeben, aber das wirkt wie eine Falle. Ich weiß nicht, wer das verwenden soll, und frage mich, ob man damit nicht sofort gegen die Bedingungen verstößt, sobald man es irgendwo benutzt
      Bei allihat.com können Nutzer inzwischen, wenn sie keinen Claude-Schlüssel verwenden wollen, das lokale Apple-Modell nutzen, und die Conversion zu zahlenden Nutzern ist etwa um das Dreifache gestiegen. Natürlich ist das trotzdem kein Ersatz für Claude. Ich hatte gehofft, Apple würde irgendeinen Mechanismus bereitstellen, der als Claude-Proxy fungiert, damit auch ich nicht meinen eigenen Server als Proxy betreiben muss, nur um den Claude-API-Verbrauch zu verwalten
    • Für Production soll man Anfragen über .proxied durch das eigene Backend routen
      Apple stellt Entwicklern mit weniger als 2 Millionen Downloads kostenlose AI-Modelle über die eigenen Server bereit https://techcrunch.com/2026/06/08/apple-bets-cheaper-ai-will...
    • Wie bisher auch: die Anfragen einfach über das eigene Backend proxien
    • Es geht nicht darum, dass Nutzer einen API-Schlüssel angeben. In der Dokumentation steht, wie man einen Backend-Proxy einrichtet

  • Ich verstehe schon, dass die Formulierung „Requests gehen direkt aus der App an die Claude API, Apple liegt nicht im Request-Pfad und sieht weder Prompts noch Antworten“ aus Entwicklersicht gemeint ist
    Aber aus Verbrauchersicht ist das einfach nur komisch

    • Warum?

  • Microsoft hat das Feld zuerst verzerrt, indem es in die Copilot-Nutzungsbedingungen geschrieben hat, Copilot werde nur zu Unterhaltungszwecken bereitgestellt, und dann sogar für Copilot in Excel gewarnt hat, man solle COPILOT nicht für Aufgaben verwenden, die Genauigkeit oder Reproduzierbarkeit erfordern oder rechtliche, regulatorische oder Compliance-Auswirkungen haben
    Apple wiederum weigert sich stillschweigend mitzumachen, statt zig Milliarden bis Hunderte Milliarden Dollar in den Versuch zu stecken, ein konkurrierendes LLM zu bauen. Natürlich verkauft Apple Claude für Naive weiter oder nutzt Gemini, aber Apple weiß, wie die Lage ist
    https://www.microsoft.com/en-us/microsoft-copilot/for-indivi...
    https://support.microsoft.com/en-US/Excel/copilot-function

  • Coding-Agenten selbst sind schon eine aufgezwungene zusätzliche Schicht, und jetzt soll noch eine weitere dazukommen? Coding-Agenten wirken oft wie Vendor Manager von Personaldienstleistern aus den 90ern
    Sie versprechen dem Kunden alles unter dem Himmel und setzen dann den armen Auftragnehmer unter Druck, damit er liefert. Coding-Agenten verbrauchen dabei zehnmal mehr Token, so wie die Differenz zwischen dem, was der Personaldienstleister dem Kunden berechnet, und dem, was er dem Auftragnehmer zahlt. Ein einfacher Test zeigt: Wenn man über einen Coding-Agenten geht, überschreitet das Modell bei derselben Aufgabe die Kontextlänge, während es mit einem direkten Prompt problemlos funktioniert
    Schichten sind Luxus und nehmen Kontrolle und Transparenz

    • Wenn ich einen Coding-Agenten baue, werde ich das nicht verwenden