Was Apples Performance-Team im WWDC26-Lab gesagt hat

Auf der WWDC26 stellte Apple fünf eigene Power-&-Performance-Ingenieure für eine Stunde live vor die Kamera, um Entwicklerfragen zu beantworten – und zwar genau jene Fragen, die Entwickler wirklich stellen: warum ein untätiger SwiftUI-Bildschirm trotzdem den Akku leert, wie man ein altes Gerät simuliert, das man gar nicht besitzt, und worin der größte Power-Fehler in ausgelieferten Apps tatsächlich besteht. Die geschliffenen Sessions erklären Ihnen, wie ein Framework funktioniert. Das Group Lab verriet Ihnen, wie Apples eigene Teams es nutzen. Dieser Beitrag bündelt die praktischen Hinweise, die es wert sind, behalten zu werden.

Ein Hinweis zur Quellenlage: Apple veröffentlichte dieses Lab-Video ohne Untertitel. Ich habe es lokal mit Whisper transkribiert, sodass jedes Lab-Zitat weiter unten eine Paraphrase aus dieser Transkription ist und kein wortwörtliches Apple-Transkript. Die Sprecher ordne ich anhand der Namen und Rollen zu, die in den Einführungen des Labs genannt und aus dem Gesprächskontext abgeleitet wurden: Terry zu Performance, Yanni zu MetricKit, Kaspar zu Instruments, Kunal zu CoreOS Power und Marco zur Render-Pipeline, mit Cole als Moderator.¹ Wo die Lab-Hinweise etwas berühren, das Apple formell dokumentiert, zitiere ich die Dokumentation oder die passende Session und kennzeichne dies.

Der untethered Power-Trace-Workflow, der einen Großteil der Ratschläge des Labs trägt, beginnt etwa bei 11:42.

Kurzfassung

• Die alte Objective-C-Schnittstelle von MetricKit wird abgelöst: MXMetricManager ist seit 27.0 offiziell veraltet (deprecated), und die neuen Metrik- und Diagnosetypen erscheinen ausschließlich auf der neuen Swift-API.²³
• Der Xcode Organizer bietet nun Metric Goals: Vergleichswerte aus Ihrem eigenen Verlauf und aus Apps, die Apple als Ihren ähnlich einstuft – für Launch, Hang-Rate, Festplattenschreibvorgänge, Akku, Speicher und Hitches.⁴
• Der Power-Workflow, den das Team empfiehlt, ist der Power-Profiler-Modus von Performance Trace: zeichnen Sie auf dem Gerät untethered einen .aar-Trace auf, übertragen Sie ihn auf Ihren Mac und lesen Sie die Power-Lanes für CPU, GPU, Display und Networking in Instruments. Die Funktion kam mit iOS 26, nicht mit iOS 27.⁵
• Apple-Intelligence-Aufgaben laufen größtenteils auf der Neural Engine und in Private Cloud Compute, sodass CPU-gebundene App-Arbeit oft parallel dazu laufen kann, ohne in Konkurrenz zu treten. Teilen Sie Hintergrundaufgaben in Stücke, damit das System sie pausieren und fortsetzen kann.¹
• Der größte Power-Fehler, den das Team beobachtet, ist unzureichende Telemetrie: Entwickler optimieren das Falsche, weil sie das Richtige nie gemessen haben.¹

Warum ein Lab das Transkribieren wert ist

Apples aufgezeichnete Sessions sind durchgeplant, einstudiert und geschnitten. Ein Group Lab ist nichts davon. Es zeigt Ingenieure, die in Echtzeit auf Fragen praktizierender Entwickler reagieren, und die Antworten tragen die Textur echter Felderfahrung: die Kriegsgeschichten, das „das sehen wir ständig”-Mustererkennen, die kleinen Eingeständnisse darüber, was schwierig ist. Genau diese Textur schleift eine geschliffene Session ab.

Der Haken ist, dass Apple das Lab ohne Untertitel veröffentlichte. Um es überhaupt zitieren zu können, habe ich das Video durch eine lokale Spracherkennung laufen lassen, was bedeutet, dass Eigennamen und API-Schreibweisen nur annähernd herauskommen. Ich habe jede technische Behauptung mit Apples Dokumentation oder der passenden WWDC-Session abgeglichen, bevor ich sie als Tatsache formuliere, und ich halte die Worte des Labs als klar gekennzeichnete Paraphrase fest. Behandeln Sie die Einordnung der Ingenieure als maßgeblich für Absicht und Priorität, und betrachten Sie die Zitate als verbindliche Quelle für die Details.

Die Felddaten-Geschichte: MetricKit wird neu gebaut

Yanni, der an MetricKit arbeitet, nannte es ein sehr großes Jahr für das Framework und beschrieb einen Neuaufbau von Grund auf rund um eine neue, Swift-first ausgelegte API. Seine Begründung: Die Swift-API ist für Swift Concurrency gebaut und wurde für eine neue Datengranularität entworfen, bei der Entwickler nicht nur den täglichen Metrikbericht erhalten, sondern auch feinere Aufschlüsselungen über kürzere Intervalle. Entscheidend ist sein Hinweis, dass neue Diagnose- und Metriktypen ausschließlich auf der neuen API erscheinen – was er als den eigentlichen Grund für eine Migration darstellte.¹

Apples Dokumentation untermauert die härtere Kante dieser Aussage. MXMetricManager, der Einstiegspunkt, den Entwickler seit der Einführung von MetricKit genutzt haben, ist nun offiziell veraltet: Apples Referenzseite markiert ihn als deprecated ab 27.0 und verweist Entwickler darauf, stattdessen MetricManager zu verwenden.² WWDC26-Session 222 macht die Exklusivität explizit: Die neuen Metrik- und Diagnosetypen leben auf der neuen Swift-API und werden nicht auf die alte zurückportiert.³ Wenn Sie weiterhin MXMetricManager aufrufen, sind Sie nicht bloß auf einem älteren Stil unterwegs; Sie sind von allem abgeschnitten, was Apple künftig hinzufügt.

Das Lab brachte außerdem eine immer wiederkehrende Verwirrung darüber zur Sprache, woher Felddaten stammen und wie man sie liest. Kunal und Yanni zogen die Linie klar: Instruments liefert Ihnen tiefes lokales Profiling auf einem Gerät an Ihrem Schreibtisch, während Xcode Organizer und MetricKit aggregierte Feldtelemetrie von echten Nutzern auf echten Geräten liefern. Die beiden widersprechen sich häufig, und genau das ist der Punkt. Kunal beschrieb Entwickler, die einem Hang nachjagen, den sie in Instruments reproduzieren können, während Organizer zeigt, dass die tatsächlich häufigste Ursache für Hangs etwas ganz anderes ist – etwas, das sich am Schreibtisch nie reproduzieren lässt.¹

Der neue Hebel auf der Organizer-Seite sind Metric Goals. Kunal hob sie als die eine Funktion hervor, die Entwickler unbedingt ausprobieren sollten, bevor sie die WWDC verlassen. Session 258 erklärt, was sie sind: empfohlene Zielwerte, die Organizer „auf Basis technischer und funktionaler Ähnlichkeiten zwischen Ihrer App und anderen Apps” ableitet, kombiniert mit Ihren eigenen historischen Vergleichswerten – über Launch-Zeit, Hang-Rate, Festplattenschreibvorgänge, Akku, Speicher und Hitches hinweg.⁴ Das Lab fasste den Nutzen in menschlichen Begriffen. Cole beschrieb einen Entwickler, der eine Video-App hochhält und fragt, ob deren hoher Stromverbrauch ein Problem ist oder einfach der Preis dafür, den ganzen Tag Videos abzuspielen. Vor Metric Goals konnte das niemand beantworten. Jetzt vergleicht der Organizer Sie mit ähnlichen Apps und gibt Ihnen eine Basis, von der aus Sie argumentieren können.¹

Ein weiterer Punkt zur Felddaten-Hygiene kam auf, und er ist es wert, klar ausgesprochen zu werden, weil Entwickler ihn immer wieder falsch machen: Bauen Sie keinen eigenen Launch-Timer. Das Lab berichtete von Entwicklern, die Kernel-APIs für den Zeitpunkt der Prozesserstellung inspizieren und diesen als Launch-Messpunkt verwenden. Yannis Antwort war, dass MetricKit und Organizer Launch bewusst nicht so messen; sie messen das Intervall, das der Nutzer tatsächlich spürt. Apples Dokumentation bestätigt die Definition: Launch-Zeit ist „die Anzahl der Millisekunden zwischen dem Antippen Ihres Icons durch den Nutzer und dem Zeichnen Ihres ersten Bildschirms”, gemessen nach dem statischen Splash-Screen.⁶ Ihr eigener Timer kann den Moment des Antippens nicht sehen, weil Ihr Prozess da noch gar nicht existiert. Apples Werkzeuge können es, und sie verursachen keinerlei Mess-Overhead in Ihrer App.

Der Power-Workflow, den das Team tatsächlich empfiehlt

Der nützlichste prozedurale Rat im Lab betraf die Frage, wie man Power-Probleme aufspürt, die an Ihrem Schreibtisch nie auftauchen. Kaspar und Kunal kamen immer wieder auf einen Workflow zurück: den untethered Trace.

Der Mechanismus ist, in Kaspars Worten, dass Sie sich von Instruments trennen, auf dem Gerät einen Trace aufzeichnen, der über mehrere Stunden laufen kann, dann die Datei auf Ihren Mac übertragen und sie zur späteren Analyse in Instruments öffnen. Der Vorteil sind reale Bedingungen: Sie bewegen sich, durchlaufen echte Mobilfunk-Handovers, lassen das Gerät warm werden und erfassen, was tatsächlich passiert, statt dessen, was in einer kontrollierten Schreibtisch-Session passiert. Kunal wies darauf hin, dass dies der Weg ist, eine bestimmte Bug-Klasse aufzuspüren – Hintergrundaufgaben, die geplant werden, obwohl sie es nicht sollten –, die unsichtbar ist, solange Sie angebunden (tethered) zuschauen.¹

Dieser Workflow ist der Power-Profiler-Modus von Performance Trace, und es lohnt sich, bei seiner Herkunft präzise zu sein: Es handelt sich um eine iOS-26-Funktion von der WWDC25, nicht um eine Neuerung in iOS 27. Apple dokumentiert sie unter „Measuring your app’s power use with Power Profiler”. Sie aktivieren sie unter Einstellungen > Developer > Performance Trace, lösen sie mit einem Control-Center-Steuerelement aus, übertragen die resultierende .aar-Datei auf Ihren Mac und lesen in Instruments den nach Subsystem aufgeschlüsselten Stromverbrauch über die Lanes für CPU, GPU, Display und Networking.⁵ Das Lab präsentierte sie als ihr empfohlenes Standardwerkzeug, nicht als 27er-Schlagzeile. (Das wirklich neue Geschwister in diesem Jahr ist der Lookback-Collection-Workflow und das metalperftrace-macOS-CLI, das ich im Beitrag Metal Machine Learning behandelt habe. Es sind verschiedene Werkzeuge für verschiedene Aufgaben; verwechseln Sie sie nicht.)

Zwei weitere Techniken aus der Power-Diskussion sind es wert, behalten zu werden:

• Low Power Mode als Stellvertreter für ein schwaches Gerät. Terry bot einen Trick für Entwickler an, die nur neue Hardware besitzen, aber wissen müssen, wie sich die App auf alter Hardware anfühlt: Schalten Sie den Low Power Mode ein. Er verlangsamt die CPUs, um Akku zu sparen, wodurch Probleme zutage treten, die Sie sonst nur auf einem älteren Gerät sehen würden. Er fügte hinzu, dass es zugleich eine gute allgemeine Optimierungspraxis ist, weil viele Nutzer den Low Power Mode bewusst verwenden und sich Ihre App auch dort gut anfühlen sollte.¹
• Device Conditions für Thermik- und Netzwerksimulation. Das Lab erwähnte wiederholt einen „Condition Inducer”, um die App in einen erhöhten thermischen Zustand oder eine verschlechterte Netzwerkverbindung zu zwingen. Apples offizielle Bezeichnung für die Funktion ist Device Conditions; der Sprecher selbst war sich nicht sicher, wo sie in Xcode 27 zu finden ist. Sie war historisch im Devices-Fenster zu Hause und könnte in den Device Hub integriert werden. Der Lab-Sprecher war sorgfältig in der Beschreibung dessen, was sie tut und was nicht: Sie induziert künstlich das Drosselungsverhalten eines heißen Geräts; sie erhitzt die Hardware nicht tatsächlich. So können Sie beobachten, wie sich Ihre App unter thermischem Druck verhält – mehr Hitches, mehr Hangs –, ohne Ihr Telefon zu backen.¹

Und eine klare Regel, die mehr als einmal aufkam: Niemals auf dem Simulator profilen. Kaspar wies darauf hin, dass der Simulator auf Ihrem Mac läuft, sodass seine Performance Ihnen nichts über die Geräteleistung verrät – unabhängig davon, welches Gerät Sie auswählen. Nutzen Sie ein physisches Gerät zum Profilen und stützen Sie sich auf die Felddaten von MetricKit und Organizer, um die Gerätevielfalt abzudecken, die Sie nicht kaufen können.¹

Performance-Triage: Thermik, KI-Konkurrenz und gestückelte Arbeit

Als sich die Fragen der Triage-Strategie zuwandten, stachen drei Hinweise heraus.

Das Thermik-Playbook. Ein Entwickler fragte nach einer ARKit- und Metal-App, die im Freien in direktem Sonnenlicht genutzt wird, wo das Gerät ständig heiß läuft. Kunals Antwort begann bei der API: Lauschen Sie auf ProcessInfo.thermalState und fahren Sie das Erlebnis zurück, wenn er ansteigt.¹ Die konkreten Hebel, die das Panel anbot: leichtere Netzwerkressourcen anfordern, damit das Gerät weniger Zeit mit Dekodieren und Parsen verbringt, üppigere Animationen gegen einfachere tauschen und unter Druck die Bildrate oder Rendering-Auflösung senken. Kunal merkte an, dass das System Animations- und Display-Bildraten in höheren thermischen Zuständen bereits selbst drosselt, sodass ein Teil der Entlastung automatisch erfolgt und Sie Ihre eigene obendrauf legen. Marcos abschließender Satz dazu: weniger Pixel zu schieben ist weniger Arbeit, und „an der Thermodynamik kommt man nicht vorbei”. Sie kontrollieren die Rechenarbeit Ihrer App; Sie kontrollieren nicht die Physik – also optimieren Sie hart an dem Teil, der Ihnen gehört.¹

Das Apple-Intelligence-Konkurrenzmodell. Eine pointierte Frage lautete, wie iOS 27 die Hintergrundaufgaben von Apps priorisiert, wenn das System mit Apple-Intelligence-Arbeit beschäftigt ist. Terrys Antwort war beruhigend und konkret: Viele Apple-Intelligence-Funktionen laufen auf der Neural Engine oder in Private Cloud Compute, sodass die beiden oft gleichzeitig laufen können, ohne um dieselbe Ressource zu konkurrieren, wenn Ihre App die CPU nutzt, während eine KI-Arbeitslast die Neural Engine beansprucht. Der defensive Schritt, den er empfahl, ist struktureller Natur: Konfigurieren Sie Hintergrundaufgaben in kleine Stücke, damit das System sie pausieren und fortsetzen kann, statt eines monolithischen Jobs, der bei jeder Unterbrechung wieder bei null beginnen muss. Gestückelte Arbeit kommt selbst dann voran, wenn der Scheduler Sie nicht so oft laufen lässt, wie Sie es gern hätten.¹

StateReporting-Kardinalität. Die neue MetricKit-Funktion StateReporting lässt Sie Metriken nach Anwendungszustand aufschlüsseln, was mächtig und leicht zu missbrauchen ist. Das Lab gab eine klare Regel zur Kardinalität: Berichten Sie keine sich häufig ändernden exakten Werte wie die genaue Anzahl von Elementen in einer Liste. Fassen Sie sie stattdessen in Buckets – klein, mittel, groß –, damit Sie später fragen können „ist die Performance in dieser Größenordnung schlechter geworden?”, ohne den Preis dafür zu zahlen, jede einzelne Anzahl aufzuzeichnen. Yannis Beispiel: Eine Liste mit 1.000 Elementen und eine mit 1.001 machen keinen bedeutsamen Unterschied, sodass das Festhalten der genauen Zahl reiner Overhead ist. Definieren Sie die Grenzen, die für Ihre Analyse wichtig sind, und berichten Sie den Bucket.¹

Speziell beim Launch konvergierte das Panel auf ein einziges mentales Modell, das die Triage-Ratschläge zusammenbindet: Finden Sie heraus, welche Mindestdaten Sie brauchen, um das erste Frame zu zeichnen, laden Sie nur diese und verschieben Sie alles andere. Terry warnte vor dem häufigen Fehler, einen Haufen Hintergrundarbeit abzuspalten und dann den Main Thread zu blockieren, bis all das fertig ist – was die ganze App während des Launches einfriert. Um zu erkennen, ob das Ihr Problem ist, verwies Kaspar auf die Main-Thread-Ansicht der System-Trace-Vorlage, in der ein blockierter Main Thread direkt sichtbar wird. Das Panel beschrieb außerdem, dass System Trace Thread-Prioritäten, Preemption und ein Context-Switch-Histogramm zutage fördert, doch ich konnte diese nicht als dokumentierte Funktionen von Instruments 27 bestätigen – nehmen Sie das also als Beschreibung des Werkzeugs durch das Lab und nicht als Spezifikation.

Tooling-Notizen: das Foundation-Models-Instrument und ein Einstieg für Anfänger

Zwei Tooling-Punkte runden das Lab ab.

Für Entwickler, die Foundation-Models-Funktionen ausliefern, beschrieb Kaspar, wie das Instruments-Werkzeug aus den letzten Jahren – mit grundlegenden Token-Zählungen – zu einem vollwertigen Debugging-Instrument herangewachsen ist, das Prompts und Antworten erfasst und anzeigt, wie viele Tokens zwischengespeichert werden.¹ Das genaue Bild über die WWDC26-Sessions hinweg: Das Foundation-Models-Instrument erfasst Prompt- und Antwortdaten vom Gerät für die Dauer des Traces (Session 243, die zudem anmerkt, dass die Erfassung sensible Informationen einschließen kann und daher in der Produktion deaktiviert ist).⁷ Die Zählungen der zwischengespeicherten Tokens kommen über die usage-API der Modellantworten (Session 241).⁸ Zwei verschiedene Mechanismen – einer für die Trace-Zeitleiste und einer für die Abrechnung pro Antwort –, die man auseinanderhalten sollte, wenn man seine Zahlen liest.

Für Anfänger war das Panel konsistent darin, wo man anfangen sollte. Marco empfahl den Time Profiler mit der Flame-Graph-Ansicht als ersten Durchgang, weil ein Flame Graph visuell zeigt, wie viel ein Call Stack Sie kostet, statt Sie Zahlen in einer Gliederung lesen zu lassen. Kaspar fügte den Top-Functions-Modus als nächsten Schritt hinzu – eine flache Liste der schwergewichtigsten Funktionen, sodass Sie die Übeltäter auf einen Blick erkennen, ohne einen tief verschachtelten Aufrufbaum zu durchwandern.¹ Und der am häufigsten wiederholte Meta-Rat des Panels: messen Sie, bevor Sie optimieren. Kunals Einordnung war, dass die häufigste Falle unzureichende Telemetrie ist, die Entwickler dazu verleitet, Bereiche zu optimieren, die keine echten Gewinne bringen. Terrys Folgerung zu Launch und Hintergrundarbeit: eine halb so oft gesendete Netzwerkanfrage ist ein kostenloser Power-Gewinn.¹ Betrachten Sie das Gesamtbild, bevor Sie in irgendein einzelnes Subsystem eintauchen.

Wichtigste Erkenntnisse

Für iOS-Entwickler, die heute ausliefern: - Migrieren Sie von MXMetricManager zur neuen MetricManager-Swift-API. Die alte Schnittstelle ist seit 27.0 veraltet, und neue Metrik- und Diagnosetypen sind exklusiv auf der neuen API.²³ - Öffnen Sie den Xcode Organizer und prüfen Sie Ihre Metric Goals gegen die Vergleichswerte ähnlicher Apps für Launch, Hangs, Akku, Hitches, Festplattenschreibvorgänge und Speicher.⁴ - Hören Sie auf, Launch mit Ihrem eigenen Timer zu messen; MetricKit und Organizer messen ab dem Antippen des Icons, was Ihr Prozess nicht sehen kann.⁶

Für Performance- und Power-Triage: - Nutzen Sie den untethered Trace des Power Profilers (iOS 26, Einstellungen > Developer > Performance Trace), um Probleme mit Hintergrundaufgaben und Power-Probleme aus der realen Welt aufzuspüren, die sich an Ihrem Schreibtisch nie reproduzieren lassen.⁵ - Profilen Sie auf einem physischen Gerät, niemals auf dem Simulator, und nutzen Sie den Low Power Mode als Ersatz für alte Hardware, die Sie nicht besitzen.¹ - Lauschen Sie auf ProcessInfo.thermalState und fahren Sie unter Druck Bildrate, Auflösung, Animationsfülle und Netzwerklast zurück.¹

Für Teams, die KI-Funktionen bauen: - Stückeln Sie Hintergrundarbeit, damit der Scheduler sie pausieren und fortsetzen kann; CPU-Arbeit kann oft neben KI-Arbeitslasten der Neural Engine und von Private Cloud Compute laufen, ohne in Konkurrenz zu treten.¹ - Fassen Sie StateReporting-Werte in Buckets (klein, mittel, groß); berichten Sie niemals sich schnell ändernde exakte Zählungen.¹ - Lesen Sie für Foundation Models das Instruments-Werkzeug zur Erfassung von Prompts und Antworten (Session 243) und ziehen Sie die Zählungen zwischengespeicherter Tokens aus der usage-API der Antwort (Session 241).⁷⁸

Dieses Lab passt natürlich zu den tieferen Betrachtungen der Serie: MetricKit und StateReporting in iOS 27 über das Aufschlüsseln von Metriken nach App-Zustand, Instruments 27 und App-Reaktionsfähigkeit über die neuen Diffing- und Hang-Erkennungs-Workflows und der Performance-Blindfleck darüber, warum Felddaten und Schreibtisch-Profiling sich widersprechen. Der vollständige Serien-Hub ist die Apple Ecosystem Series.

Quellen