Lo que dijo el equipo de rendimiento de Apple en el lab de la WWDC26

En la WWDC26, Apple puso ante la cámara a cinco de sus propios ingenieros de Power & Performance para una hora de preguntas y respuestas en vivo con desarrolladores, y respondió las preguntas que los desarrolladores de verdad plantean: por qué una pantalla de SwiftUI inactiva sigue agotando la batería, cómo simular un dispositivo antiguo que no tienes, cuál es realmente el mayor error de consumo de energía en las apps en producción. Las sesiones pulidas te explican cómo funciona un framework. El Group Lab, en cambio, te mostró cómo lo usan los propios equipos de Apple. Este artículo recoge la guía de campo que vale la pena conservar.

Una nota sobre las fuentes: Apple publicó este video del lab sin subtítulos. Lo transcribí en local con Whisper, así que cada cita del lab que aparece abajo es una paráfrasis de esa transcripción, no una transcripción literal de Apple. Atribuyo los comentarios a cada participante según los nombres y roles dados en las presentaciones del lab, inferidos por el contexto de la conversación: Terry en rendimiento, Yanni en MetricKit, Kaspar en Instruments, Kunal en CoreOS Power y Marco en el pipeline de renderizado, con Cole moderando.¹ Donde la guía del lab toca algo que Apple documenta formalmente, cito el documento o la sesión correspondiente y lo señalo.

El flujo de trabajo de traza de energía sin cable, que sostiene gran parte de los consejos del lab, comienza alrededor del 11:42.

TL;DR

• La vieja superficie de MetricKit en Objective-C va camino de desaparecer: MXMetricManager queda formalmente obsoleto a partir de la 27.0, y los nuevos tipos de métricas y diagnósticos se entregan exclusivamente en la nueva API de Swift.²³
• Xcode Organizer ahora ofrece Metric Goals: referencias extraídas de tu propio historial y de las apps que Apple considera similares a la tuya, que abarcan el lanzamiento, la tasa de bloqueos, las escrituras en disco, la batería, el almacenamiento y los hitches.⁴
• El flujo de trabajo de energía que el equipo recomienda es el modo Power Profiler de Performance Trace: graba una traza .aar sin cable en el dispositivo, compártela a tu Mac y lee en Instruments los carriles de consumo de CPU, GPU, pantalla y red. Esta función llegó con iOS 26, no con iOS 27.⁵
• El trabajo de Apple Intelligence se ejecuta sobre todo en el Neural Engine y en Private Cloud Compute, así que el trabajo de una app que depende de la CPU a menudo puede correr en paralelo sin contención. Divide las tareas en segundo plano en fragmentos para que el sistema pueda pausarlas y reanudarlas.¹
• El mayor error de consumo que ve el equipo es una telemetría insuficiente: los desarrolladores optimizan lo equivocado porque nunca midieron lo correcto.¹

Por qué vale la pena transcribir un lab

Las sesiones grabadas de Apple llevan guion, ensayo y edición. Un Group Lab no es nada de eso. Son ingenieros reaccionando en tiempo real a las preguntas de desarrolladores en activo, y las respuestas tienen la textura de la experiencia de campo: las anécdotas de guerra, el reconocimiento de patrones del tipo «esto lo vemos todo el tiempo», las pequeñas confesiones sobre qué es difícil. Esa textura es justo lo que una sesión pulida lima.

El problema es que Apple publicó el lab sin subtítulos. Para citarlo siquiera, tuve que pasar el video por un reconocimiento de voz local, lo que significa que los nombres propios y la ortografía de las API salen aproximados. He contrastado cada afirmación técnica con la documentación de Apple o con la sesión de la WWDC correspondiente antes de enunciarla como un hecho, y mantengo las propias palabras del lab claramente señaladas como paráfrasis. Toma el encuadre de los ingenieros como autoridad sobre la intención y las prioridades, y toma las citas como la fuente de referencia sobre los detalles.

La historia de los datos de campo: MetricKit se está reconstruyendo

Yanni, que trabaja en MetricKit, lo calificó de un año muy grande para el framework y describió una reconstrucción de raíz en torno a una nueva API Swift-first. La motivación que dio: la API de Swift está construida para Swift concurrency, y se diseñó pensando en una nueva granularidad de datos, donde los desarrolladores obtienen no solo el informe diario de métricas, sino también desgloses más finos en intervalos más cortos. Y, crucialmente, señaló que los nuevos tipos de diagnósticos y métricas se entregan únicamente en la nueva API, lo que planteó como la verdadera razón para migrar.¹

La documentación de Apple respalda el filo más duro de esa afirmación. MXMetricManager, el punto de entrada que los desarrolladores usan desde que llegó MetricKit, ahora está formalmente obsoleto: la página de referencia de Apple lo marca como obsoleto en la 27.0 y dirige a los desarrolladores a usar MetricManager en su lugar.² La sesión 222 de la WWDC26 hace explícita la exclusividad: los nuevos tipos de métricas y diagnósticos viven en la nueva API de Swift y no se trasladan a la antigua.³ Si sigues llamando a MXMetricManager, no estás meramente en un estilo más viejo; estás aislado de todo lo que Apple añada de aquí en adelante.

El lab también sacó a la luz una confusión recurrente sobre de dónde vienen los datos de campo y cómo leerlos. Kunal y Yanni trazaron la línea con claridad: Instruments te da un perfilado local profundo en un solo dispositivo sobre tu escritorio, mientras que Xcode Organizer y MetricKit te dan telemetría de campo agregada de usuarios reales en dispositivos reales. Las dos discrepan a menudo, y esa discrepancia es justo el punto. Kunal describió a desarrolladores que persiguen un bloqueo que pueden reproducir en Instruments mientras Organizer muestra que la verdadera causa principal de los bloqueos es algo completamente distinto, algo que nunca se reproduce en un escritorio.¹

La nueva palanca del lado de Organizer son los Metric Goals. Kunal los señaló como la única función que más quería que los desarrolladores probaran antes de irse de la WWDC. La sesión 258 detalla qué son: objetivos recomendados que Organizer deriva «con base en las similitudes técnicas y funcionales entre tu app y otras apps», combinados con tus propias referencias históricas, y que abarcan el tiempo de lanzamiento, la tasa de bloqueos, las escrituras en disco, la batería, el almacenamiento y los hitches.⁴ El lab expresó el valor en términos humanos. Cole describió a un desarrollador que sostiene una app de video y pregunta si su alto consumo de energía es un problema o solo el costo de reproducir video todo el día. Antes de los Metric Goals, nadie podía responder. Ahora Organizer te compara con apps similares y te da una referencia desde la cual razonar.¹

Salió un último punto de higiene de datos de campo, y vale la pena decirlo sin rodeos porque los desarrolladores se siguen equivocando: no fabriques tu propio temporizador de lanzamiento. El lab relató a desarrolladores que inspeccionan las API del kernel para obtener la hora de creación del proceso y la usan como referencia de lanzamiento. La respuesta de Yanni fue que MetricKit y Organizer deliberadamente no miden el lanzamiento de esa forma; miden el intervalo que el usuario realmente siente. La documentación de Apple confirma la definición: el tiempo de lanzamiento es «el número de milisegundos entre que el usuario toca tu icono y que se dibuja tu primera pantalla», medido después de la pantalla de bienvenida estática.⁶ Tu propio temporizador no puede ver el instante del toque, porque tu proceso aún no existe. Las herramientas de Apple sí pueden, y no añaden ninguna sobrecarga de medición a tu app.

El flujo de trabajo de energía que el equipo de verdad recomienda

El consejo procedimental más útil del lab trataba sobre cómo atrapar los problemas de energía que nunca aparecen en tu escritorio. Kaspar y Kunal volvían una y otra vez a un solo flujo de trabajo: la traza sin cable.

La mecánica, en palabras de Kaspar, consiste en desconectarte de Instruments, grabar en el dispositivo una traza que puede correr durante varias horas, y luego compartir el archivo a tu Mac y abrirlo en Instruments para analizarlo más tarde. El beneficio son las condiciones del mundo real: te mueves, atraviesas traspasos de red móvil reales, dejas que el dispositivo se caliente y capturas lo que de verdad ocurre en lugar de lo que ocurre en una sesión de escritorio controlada. Kunal lo señaló como la manera de atrapar una clase concreta de bugs, las tareas en segundo plano programadas cuando no deberían estarlo, que resultan invisibles mientras estás conectado y observando.¹

Ese flujo de trabajo es el modo Power Profiler de Performance Trace, y vale la pena ser preciso sobre su origen: es una función de iOS 26 de la WWDC25, no una novedad de iOS 27. Apple lo documenta bajo «Measuring your app’s power use with Power Profiler». Lo activas en Ajustes > Desarrollador > Performance Trace, lo disparas con un control del Centro de control, compartes el archivo .aar resultante a tu Mac y lees en Instruments el consumo desglosado por subsistema a través de los carriles de CPU, GPU, pantalla y red.⁵ El lab lo presentó como su recurso recomendado de cabecera, no como un titular de la 27. (La verdadera hermana nueva de este año es el flujo de recolección lookback y la CLI de macOS metalperftrace, que cubrí en el artículo sobre machine learning con Metal. Son herramientas distintas para tareas distintas; no las confundas.)

Hay dos técnicas más de la conversación sobre energía que vale la pena conservar:

• El modo de bajo consumo como sustituto de dispositivo modesto. Terry ofreció un truco para los desarrolladores que solo tienen hardware nuevo pero necesitan saber cómo se siente la app en hardware antiguo: activa el modo de bajo consumo. Ralentiza las CPU para ahorrar batería, lo que saca a la luz problemas que de otro modo solo verías en un dispositivo más viejo. Añadió que además sirve como buena práctica de optimización general, porque muchos usuarios activan el modo de bajo consumo por elección y tu app debería seguir sintiéndose bien ahí.¹
• Device Conditions para simular calor y red. El lab mencionó repetidamente un «condition inducer» para forzar a la app a un estado térmico elevado o a un enlace de red degradado. El nombre oficial de Apple para la función es Device Conditions; el propio ponente no estaba seguro de dónde se encuentra en Xcode 27. Históricamente ha vivido en la ventana Devices y podría integrarse en el Device Hub. El ponente del lab fue cuidadoso sobre lo que hace y lo que no hace: induce artificialmente el comportamiento de limitación (throttling) de un dispositivo caliente; no calienta realmente el hardware. Así que puedes observar cómo se comporta tu app bajo presión térmica, con más hitches y más bloqueos, sin cocinar tu teléfono.¹

Y una regla tajante que salió más de una vez: nunca perfiles en el Simulador. Kaspar señaló que el Simulador corre en tu Mac, así que su rendimiento no te dice nada sobre el rendimiento del dispositivo, sin importar qué dispositivo selecciones. Perfila en un dispositivo físico y apóyate en los datos de campo de MetricKit y Organizer para cubrir la diversidad de dispositivos que no puedes comprar.¹

Triaje de rendimiento: calor, contención con la IA y trabajo fragmentado

Cuando las preguntas giraron hacia la estrategia de triaje, destacaron tres consejos.

El manual térmico. Un desarrollador preguntó por una app de ARKit y Metal usada al aire libre, bajo luz solar directa, donde el dispositivo se calienta constantemente. La respuesta de Kunal arrancó por la API: escucha ProcessInfo.thermalState y reduce la experiencia cuando suba.¹ Las palancas concretas que ofreció el panel: pedir recursos de red más livianos para que el dispositivo pase menos tiempo decodificando y analizando, cambiar las animaciones ricas por otras más simples, y bajar la tasa de fotogramas o la resolución de renderizado bajo presión. Kunal señaló que el sistema ya limita las tasas de fotogramas de las animaciones y de la pantalla en estados térmicos más altos, así que parte del alivio es automático y tú añades el tuyo encima. La frase de cierre de Marco al respecto: empujar menos píxeles es menos trabajo, y «no hay forma de esquivar la termodinámica». Tú controlas el cómputo de tu app; no controlas la física, así que optimiza a fondo la parte que te pertenece.¹

El modelo de contención de Apple Intelligence. Una pregunta afilada planteaba cómo iOS 27 prioriza las tareas en segundo plano de una app cuando el sistema está ocupado con trabajo de Apple Intelligence. La respuesta de Terry fue tranquilizadora y precisa: muchas funciones de Apple Intelligence se ejecutan en el Neural Engine o en Private Cloud Compute, así que si tu app está usando la CPU mientras una carga de IA usa el Neural Engine, las dos a menudo pueden correr en paralelo sin disputarse el mismo recurso. La jugada defensiva que recomendó es estructural: configura las tareas en segundo plano en fragmentos pequeños para que el sistema pueda pausarlas y reanudarlas, en lugar de un único trabajo monolítico que tenga que reiniciar desde cero cada vez que se le interrumpe. El trabajo fragmentado avanza incluso cuando el planificador no te ejecuta con la frecuencia que quisieras.¹

La cardinalidad de StateReporting. La nueva función StateReporting de MetricKit te permite segmentar las métricas por estado de la aplicación, lo cual es potente y fácil de usar mal. El lab dio una regla clara sobre la cardinalidad: no reportes valores exactos que cambien con frecuencia, como el número preciso de elementos en una lista. En su lugar, agrúpalos en tramos, pequeño, mediano, grande, para luego poder preguntar «en este rango de tamaño, ¿se degradó el rendimiento?» sin pagar el costo de registrar cada conteo distinto. El ejemplo de Yanni: una lista de 1.000 elementos y una de 1.001 no marcan ninguna diferencia significativa, así que registrar el número exacto es pura sobrecarga. Define las fronteras que importan para tu análisis y reporta el tramo.

En cuanto al lanzamiento en particular, el panel convergió en un único modelo mental que ata los consejos de triaje: averigua los datos mínimos que necesitas para dibujar el primer fotograma, carga solo eso y aplaza todo lo demás. Terry advirtió contra el fallo común de lanzar un montón de trabajo en segundo plano y luego bloquear el hilo principal hasta que todo termine, lo que congela la app entera durante el lanzamiento. Para saber si ese es tu problema, Kaspar señaló la vista de hilo principal de la plantilla System Trace, donde un hilo principal bloqueado aparece directamente. El panel también describió que System Trace saca a la luz las prioridades de los hilos, la apropiación (preemption) y un histograma de cambios de contexto; sin embargo, no he podido confirmar que sean funciones documentadas de Instruments 27, así que tómalo como la descripción que el lab hace de la herramienta más que como una especificación.

Notas de herramientas: el instrumento de Foundation Models y una rampa para principiantes

Dos puntos de herramientas redondean el lab.

Para los desarrolladores que despliegan funciones de Foundation Models, Kaspar describió la herramienta de Instruments creciendo desde las simples métricas de conteo de tokens del año pasado hasta un instrumento de depuración completo que captura los prompts y las respuestas y muestra cuántos tokens se están almacenando en caché.¹ La imagen precisa a través de las sesiones de la WWDC26: el instrumento de Foundation Models captura los datos de prompt y respuesta desde el dispositivo durante toda la traza (sesión 243, que además señala que la captura puede incluir información sensible, por lo que está desactivada en producción).⁷ Los conteos de tokens en caché llegan a través de la API usage en las respuestas del modelo (sesión 241).⁸ Dos mecanismos distintos, uno para la línea de tiempo de la traza y otro para la contabilidad por respuesta, que conviene mantener bien separados al leer tus cifras.

Para principiantes, el panel fue coherente sobre por dónde empezar. Marco recomendó el Time Profiler con la vista de flame graph como primera pasada, porque un flame graph muestra de forma visual cuánto te cuesta una pila de llamadas en lugar de hacerte leer números en un esquema. Kaspar añadió el modo Top Functions como el siguiente paso, una lista plana de las funciones más pesadas para detectar a los culpables de un vistazo sin recorrer un árbol de llamadas profundamente anidado.¹ Y el metaconsejo más repetido del panel: mide antes de optimizar. El encuadre de Kunal: el escollo más común es una telemetría insuficiente, que lleva a los desarrolladores a optimizar áreas que no rinden ninguna ganancia real. El corolario de Terry sobre el lanzamiento y el trabajo en segundo plano: una petición de red enviada la mitad de veces es una ganancia de energía gratis. Mira el cuadro completo antes de zambullirte en cualquier subsistema concreto.¹

Puntos clave

Para desarrolladores iOS que publican hoy: - Migra de MXMetricManager a la nueva API de Swift MetricManager. La superficie antigua está obsoleta a partir de la 27.0, y los nuevos tipos de métricas y diagnósticos son exclusivos de la nueva API.²³ - Abre Xcode Organizer y contrasta tus Metric Goals con las referencias de apps similares para el lanzamiento, los bloqueos, la batería, los hitches, las escrituras en disco y el almacenamiento.⁴ - Deja de medir el lanzamiento con tu propio temporizador; MetricKit y Organizer miden desde el toque en el icono, algo que tu proceso no puede ver.⁶

Para el triaje de rendimiento y energía: - Usa la traza sin cable de Power Profiler (iOS 26, Ajustes > Desarrollador > Performance Trace) para atrapar los problemas de tareas en segundo plano y de energía en el mundo real que nunca se reproducen en tu escritorio.⁵ - Perfila en un dispositivo físico, nunca en el Simulador, y usa el modo de bajo consumo como sustituto del hardware antiguo que no tienes.¹ - Escucha ProcessInfo.thermalState y reduce la tasa de fotogramas, la resolución, la riqueza de las animaciones y el peso de la red bajo presión.¹

Para equipos que construyen funciones de IA: - Fragmenta el trabajo en segundo plano para que el planificador pueda pausarlo y reanudarlo; el trabajo de CPU a menudo puede correr en paralelo con las cargas de IA del Neural Engine y de Private Cloud Compute sin contención.¹ - Agrupa en tramos los valores de StateReporting (pequeño, mediano, grande); nunca reportes conteos exactos que cambian rápido.¹ - Para Foundation Models, consulta la herramienta de Instruments para la captura de prompts y respuestas (sesión 243) y obtén los conteos de tokens en caché desde la API usage de las respuestas (sesión 241).⁷⁸

Este lab combina de forma natural con los análisis más profundos de la serie: MetricKit y StateReporting en iOS 27 sobre segmentar las métricas por estado de la app, Instruments 27 y la capacidad de respuesta de las apps sobre los nuevos flujos de diffing y detección de bloqueos, y el punto ciego del rendimiento sobre por qué los datos de campo y el perfilado de escritorio discrepan. El hub completo de la serie es la Apple Ecosystem Series.

Referencias