Im Rahmen der Einführung des MacBook Neo hat Apple auch an seinen Produktionsverfahren gearbeitet. So wird das Gehäuse in einem neuartigen „materialeffizienten Umformverfahren“ hergestellt, wie Apple angibt. Dabei wird laut dem Konzern nur noch die Hälfte an Alu als Ausgangsmaterial „gegenüber herkömmlichen Zerspanungsmethoden“ benötigt. Gänzlich recycelt ist der Stoff allerdings nicht: Hier erreicht Apple aktuell aber einen Faktor von 90 Prozent. Was bislang noch nicht bekannt war: Das Neo soll auch beim Wasserverbrauch in der Herstellung deutlich umweltfreundlicher sein.

Viermal Wasser des Westsees

Angaben dazu macht Apple auf seiner chinesischsprachigen Presse-Website. Man habe einen neuen „Closed Loop“-Prozess für den Eloxierprozess entwickelt, schreibt der Konzern dort. Er wird bei den verwendeten Fertigern – Apple erwähnt Foxconn – in China verwendet. „Closed Loop“ heißt, dass weniger Wasser verloren gehen soll. Allerdings ist auch das nicht perfekt: Die Wasserrecyclingrate liegt derzeit bei 70 Prozent im Produktionsprozess für das Neo.

Insgesamt soll Apple bei seinen Fertigern mit dieser und anderen Maßnahmen 55 Milliarden Liter Trinkwasser eingespart haben. Das entspricht rund dem vierfachen Wasservolumen des bekannten Westsees in Zhejiang. Laut Aussagen von Operations-Chef (COO) Sabih Khan arbeitet mit allen chinesischen Lieferanten zusammen, um „die wertvollste Ressource der Welt“ zu schützen. Der neue Alu-Prozess sei hier ein nächster Schritt, der ein 100 Jahre altes, traditionell wasserintensives Industrieverfahren verändere.

Sauberes Trinkwasser fehlt

Apple hatte vor 13 Jahren das sogenannte Clean Water Project für China gestartet. Dabei soll möglichst wenig Trinkwasser in die Prozesse des Konzerns gelangen, stattdessen Wasser recycelt werden. Zudem werden Lieferanten in den Bereichen Wassermanagement und Ökodesign trainiert. Bei Foxconn entstand so auf dem Campus in Longshua ein Gartenprojekt, bei dem Regenwasser gereinigt und wiederverwendet wird.

Das Thema Trinkwasser ist in China besonders wichtig. So wird auch in Großstädten wie Peking immer noch davon abgeraten, Leitungswasser direkt zu trinken, da dieses belastet sein kann.

(bsc)

Mit den am Dienstagabend veröffentlichten Aktualisierungen auf iOS 26.4, macOS 26.4, iPadOS 26.4, watchOS 26.4, visionOS 26.4, tvOS 26.4 sowie einer neuen Firmware für die HomePods liefert Apple einmal mehr ein großes Paket an Sicherheitsfixes aus. Diese sollte man ernst nehmen: Zuletzt hatte es schwerwiegende Angriffe auf ältere iOS-Versionen gegeben, zudem ist ein bekanntes Exploitkit im Quellcode verfügbar gemacht worden. Die Vorfälle zeigen, dass Apple schneller reagieren muss – und Nutzer dringend auf dem aktuellen Stand bleiben müssen. Apple hat zwar neue Möglichkeiten wie die sogenannten Background Security Improvements eingeführt, die schnellere Updates (mit geringerer Reboot-Zeit) versprechen, nutzt diese aber noch selten beziehungsweise versteckt diese in den Systemeinstellungen.

Was in den Updates aus Security-Sicht steckt

Wie üblich erhalten bei Apple nur die neuesten Betriebssysteme alle Fixes – auch das wird immer wieder kritisiert. Die Aktualisierungen auf iOS 26.4 und iPadOS 26.4 sowie macOS Tahoe 26.4 liefern Dutzende Fehlerbehebungen, darunter auch solche, die aus der Ferne ausgenutzt werden können. Auf dem iPhone kann so das Baseband im 16e außer Betrieb gesetzt werden (Denial of Service), auf anderen Geräten lassen sich darüber Apps abschießen. Gleiches gilt für das Calling Framework, das es mittlerweile auch für macOS gibt.

Die Zwischenablage kann Daten leaken, über einen iCloud-Trick lässt sich auslesen, welche Apps installiert sind und im Kernel stecken gleich mehrere Bugs, die für tiefere Hackversuche genutzt werden könnten. Immerhin nennt Apple keine direkten Berichte über bekannte Angriffe auf die nun gefixten Sicherheitslücken. Über 40 in den neuen Systemen gestopfte Löcher führt Apple nicht detailliert aus – auch das wird immer wieder kritisiert. Was genau angreifbar ist, wird oft erst nach Monaten mitgeteilt.

Weitere Betriebssysteme und ältere Versionen

visionOS 26.4, watchOS 26.4 und tvOS 26.4 enthalten ebenfalls viele Sicherheits-Fixes mit auf die Systeme angepassten Änderungen. Einzeln ausgeliefert wird Safari 26.4 mit Fehlerbehebungen für verschiedene WebKit-Lücken. Es steht für macOS Sonoma (14) und Sequoia (15) bereit, ist sonst Teil von macOS 26.4. Auch die Entwicklungsumgebung Xcode enthielt sicherheitsrelevante Bugs und sollte auf Xcode 26.4 aktualisiert werden.

Weiterhin stellt Apple macOS 15.7.5, macOS 14.8.5 und iOS und iPadOS 18.7.7 zum Download bereit, die Teile der Fehler auch für ältere Betriebssysteme ausbessern. Vollends geschützt ist man wie erwähnt nur, wenn man auf die Version 26.4 der jeweiligen Betriebssysteme aktualisiert.

(bsc)

Echten Nutzen bringt generative KI nicht bei individuellen Experimenten und Prototyping, sondern dann, wenn bestehende Softwareprodukte, Plattformen und Geschäftsprozesse gezielt durch GenAI erweitert werden.

Oft bilden hier C# und .NET das Fundament zahlreicher ERP-naher Systeme, Individualanwendungen und Standardprodukte. Rund um diese Plattform existieren umfangreiches Know-how, stabile Build- und Deployment-Pipelines sowie erprobte Betriebs- und Sicherheitskonzepte. Diese Investitionen sind langfristig angelegt und lassen sich nicht ohne Weiteres ersetzen.

Statt also komplette Systeme für GenAI neu zu entwickeln, sollen bestehende Anwendungen durch Assistenzfunktionen, kontextbezogene Unterstützung, teilautomatisierte Workflows oder Copilot-ähnliche Erweiterungen intelligenter werden. Dafür müssen Large Language Models (LLMs) nahtlos in bestehende Architekturen integrierbar sein.

Der Kontext zählt: GenAI als Experiment oder im Produktiveinsatz

Hier zeigt sich der Unterschied zwischen Experiment und Produktivsystem. Ein Proof of Concept lässt sich schnell in Python umsetzen. Für produktive Systeme zählen jedoch andere Kriterien: Integration in bestehende Authentifizierungsmechanismen, Zugriff auf interne Services und Datenbanken, Wiederverwendung bestehender Bibliotheken, sauberes Logging, reproduzierbare Builds und klar geregelter Betrieb. Jede zusätzliche Sprache und jede neue Toolchain erhöhen die Komplexität und damit Aufwand und Risiko.

Aus dieser Perspektive ist .NET für GenAI-Anwendungen hochrelevant. Nicht, weil .NET grundsätzlich besser für KI geeignet wäre, sondern weil es den Übergang vom Experiment zur produktiven Anwendung deutlich vereinfacht. Bestehende Teams können mit bekannten Werkzeugen arbeiten, vorhandene Infrastruktur bleibt nutzbar, Governance- und Sicherheitsanforderungen lassen sich leichter einhalten.

Gleichzeitig gilt: .NET ist selten die erste Wahl für KI-nahe Forschung, Modelltraining oder frühe Exploration. In diesen Bereichen dominieren Python und zunehmend auch TypeScript. Neue Frameworks und APIs erscheinen dafür meist zuerst.

Für produktive GenAI-Systeme in Unternehmen hingegen ist .NET häufig die naheliegende Plattform, vorausgesetzt, geeignete SDKs stehen zur Verfügung. Niemand möchte auf Protokollebene mit HTTP-Requests, JSON-Parsing und asynchronen Event-Streams arbeiten, nur um ein LLM anzubinden.

Gut gepflegte .NET-SDKs sind deshalb kein Luxus, sondern ein Enablement-Faktor. Sie bestimmen, ob bestehende Entwicklungsteams GenAI schnell, sicher und wartbar integrieren können oder ob unnötige Reibungsverluste entstehen. Wie gut die aktuelle SDK-Landschaft diesen Anspruch heute erfüllt, zeigt der Blick auf die verfügbaren Anbieter und Abstraktionen.

Die SDK-Landschaft für Large Language Models aus .NET-Sicht

Wer ein LLM mit .NET nutzen möchte, trifft heute auf eine deutlich vielfältigere SDK-Landschaft als noch vor einem Jahr. Doch nicht alle verfügbaren SDKs sind gleichwertig und nicht jedes eignet sich für produktive Anwendungen.

Die folgende Abbildung stellt den Zusammenhang zwischen Basis-SDKs, LLM-Proxies, Agenten-Schicht, Präsentationsschicht und MCP dar. Auf diese Punkte gehen die folgenden Kapitel genauer ein. Dabei beschäftigt sich der Artikel insbesondere damit, wie gut die SDK-Landschaft aus .NET-Sicht aufgestellt ist.

Lange Zeit waren offizielle SDKs für Large Language Models fast ausschließlich für Python und TypeScript verfügbar. Das beginnt sich zu ändern. Inzwischen stellen mehrere große Modellanbieter .NET-SDKs bereit, die sich für produktive Anwendungen eignen.

Die ersten ernstzunehmenden C#-SDKs für die OpenAI-API entstanden nicht direkt bei OpenAI selbst, sondern bei Microsoft als Teil der engen strategischen Partnerschaft zwischen beiden Unternehmen. Sie wiesen jedoch noch Schwächen auf. Nach einer Übergangsphase übernahm OpenAI selbst die Verantwortung. Heute wird das offizielle C#-SDK direkt von OpenAI gepflegt und als reguläres NuGet-Paket veröffentlicht. Microsoft stellt ergänzend ein begleitendes Paket bereit. Es erleichtert unter anderem Authentifizierung, Konfiguration und Integration mit OpenAI in Azure Foundry, ist jedoch optional. Die Kernfunktionalität für den Zugriff auf OpenAI-Modelle liegt heute eindeutig im offiziellen OpenAI-SDK selbst.

Anthropic stellt ein offizielles C#-SDK bereit, das aktuell noch als Beta gekennzeichnet ist, jedoch bereits gut nutzbar ist. Google bietet mit seinem GenAI-SDK eine offizielle .NET-Anbindung für Gemini-Modelle, sowohl für Google AI als auch für Vertex AI. Auch für andere LLM-Anbieter existieren heute offizielle, vom Hersteller gepflegte .NET-SDKs.

Die größte Reife und Verbreitung besitzt aber das OpenAI-SDK. Das zugehörige GitHub-Repository verzeichnet mehrere Tausend Sterne und das NuGet-Paket kommt auf fast 35 Millionen Downloads.

Neben den offiziellen SDKs existiert eine Vielzahl an Community- und Open-Source-SDKs. Eine besondere Rolle spielt hier das Projekt tryAGI, das auf Basis von OpenAI-Spezifikationen systematisch C#-SDKs für eine Vielzahl von LLM-Anbietern generiert.

Auf diese Weise stehen für viele Modelle SDKs zur Verfügung, für die es keine offiziellen .NET-Bibliotheken gibt, darunter auch Anbieter wie Mistral und Plattformen wie Ollama. Der Ansatz ist pragmatisch: Die SDKs sind konsistent aufgebaut, schnell verfügbar und decken in der Regel die grundlegenden API-Funktionen zuverlässig ab. Allerdings haben sie Grenzen: Generierte SDKs folgen relativ streng der jeweiligen API-Spezifikation mit keinen oder begrenzten manuellen Anpassungen, weshalb fortgeschrittene API-Funktionen manchmal nur holprig oder gar nicht verfügbar sind. Auch die langfristige Wartung hängt nicht vom Modellanbieter selbst ab, sondern vom Engagement der Community.

Für einfache Anwendungsfälle sind solche SDKs oft vollkommen ausreichend. Für komplexere, interaktive oder langfristig betriebene Systeme sollte man jedoch genau prüfen, ob ein Community-SDK den eigenen Anforderungen genügt.

Proxies und Kompatibilitätsschichten: Abstraktion statt Anbieterbindung

Eine weitere Kategorie bilden Proxies und Kompatibilitätsschichten, die versuchen, unterschiedliche Modellanbieter hinter einer einheitlichen API zu bündeln. Ein prominentes Beispiel dafür ist LiteLLM, das eine OpenAI-kompatible API bereitstellt und Anfragen an eine Vielzahl von Modellen weiterleitet.

Für .NET-Entwicklerinnen und -Entwickler kann dieser Ansatz attraktiv sein, da sie OpenAI-SDKs verwenden können. Oft genügt es, die Base-URL zu ändern und andere Modellnamen zu konfigurieren. Ähnlich verhält es sich bei lokal betriebenen Modellen über Ollama, das ebenfalls OpenAI-kompatible Endpoints bereitstellt.

Diese Abstraktion erleichtert den Wechsel zwischen Modellen und Anbietern, hat jedoch ihren Preis. Kompatibilitätsschichten orientieren sich in der Regel am kleinsten gemeinsamen Nenner der unterstützten APIs. Neuere oder anbieterspezifische Features werden häufig nur eingeschränkt unterstützt oder fehlen ganz. Besonders bei neueren API-Varianten oder fortgeschrittenen Funktionen kann es hier zu spürbaren Einschränkungen kommen.