O que o time de performance da Apple disse no lab da WWDC26

Na WWDC26, a Apple colocou cinco de seus próprios engenheiros de Power & Performance na frente das câmeras por uma hora de Q&A ao vivo com desenvolvedores e respondeu às perguntas que os desenvolvedores realmente fazem: por que uma tela ociosa do SwiftUI ainda drena a bateria, como simular um dispositivo antigo que você não possui, e qual é, de fato, o maior erro de consumo de energia em apps publicados. As sessões caprichadas explicam como um framework funciona. O Group Lab mostrou como os próprios times da Apple o usam. Este post reúne a orientação de campo que vale a pena guardar.

Uma observação sobre a fonte: a Apple publicou este vídeo do lab sem legendas. Eu o transcrevi localmente com o Whisper, então toda citação do lab abaixo é uma paráfrase dessa transcrição, e não um transcript literal da Apple. Atribuo as falas pelos nomes e papéis dados nas apresentações do lab, inferidos pelo contexto da conversa: Terry em performance, Yanni no MetricKit, Kaspar no Instruments, Kunal no CoreOS Power e Marco no pipeline de renderização, com Cole na moderação.¹ Quando a orientação do lab toca algo que a Apple documenta formalmente, cito o documento ou a sessão correspondente e sinalizo isso.

O fluxo de trabalho de power-trace untethered que sustenta boa parte dos conselhos do lab começa por volta de 11:42.

TL;DR

• A antiga superfície Objective-C do MetricKit está a caminho da aposentadoria: o MXMetricManager está formalmente obsoleto (deprecated) a partir do 27.0, e os novos tipos de métrica e diagnóstico chegam exclusivamente na nova API Swift.²³
• O Xcode Organizer agora oferece Metric Goals: linhas de base extraídas do seu próprio histórico e de apps que a Apple julga semelhantes ao seu, cobrindo launch, taxa de hangs, gravações em disco, bateria, armazenamento e hitches.⁴
• O fluxo de trabalho de energia que o time recomenda é o modo Power Profiler do Performance Trace: grave um trace .aar untethered no dispositivo, compartilhe-o com o seu Mac e leia as lanes de energia de CPU, GPU, display e rede no Instruments. O recurso chegou com o iOS 26, não com o iOS 27.⁵
• O trabalho do Apple Intelligence roda majoritariamente no Neural Engine e no Private Cloud Compute, então o trabalho do app limitado por CPU muitas vezes pode rodar ao lado dele sem disputa por recursos. Divida as tarefas em segundo plano em pedaços para que o sistema possa pausá-las e retomá-las.¹
• O maior erro de energia que o time observa é telemetria insuficiente: os desenvolvedores otimizam a coisa errada porque nunca mediram a coisa certa.¹

Por que um lab vale a pena transcrever

As sessões gravadas da Apple são roteirizadas, ensaiadas e editadas. Um Group Lab não é nada disso. São engenheiros reagindo em tempo real a perguntas de desenvolvedores que estão na ativa, e as respostas carregam a textura da experiência de campo: as histórias de guerra, o reconhecimento de padrão do tipo “vemos isso o tempo todo”, as pequenas admissões sobre o que é difícil. Essa textura é exatamente o que uma sessão caprichada lixa fora.

O problema é que a Apple publicou o lab sem legendas. Para conseguir citá-lo, rodei o vídeo por reconhecimento de fala local, o que significa que nomes próprios e grafias de API saem aproximados. Reconciliei cada afirmação técnica com a documentação da Apple ou com a sessão correspondente da WWDC antes de declará-la como fato, e mantenho as próprias palavras do lab como paráfrase claramente marcada. Trate o enquadramento dos engenheiros como autoridade sobre intenção e prioridade, e trate as citações como a fonte de registro sobre os detalhes.

A história dos dados de campo: o MetricKit está sendo reconstruído

Yanni, que trabalha no MetricKit, chamou este de um ano muito grande para o framework e descreveu uma reconstrução do zero em torno de uma nova API Swift-first. A motivação que ele deu: a API Swift é construída para Swift concurrency e foi projetada para uma nova granularidade de dados, em que os desenvolvedores obtêm não apenas o relatório diário de métricas, mas recortes menores em intervalos mais curtos. Crucialmente, ele observou que os novos tipos de diagnóstico e métrica chegam apenas na nova API, o que ele enquadrou como o verdadeiro motivo para migrar.¹

A documentação da Apple sustenta a parte mais dura dessa afirmação. O MXMetricManager, o ponto de entrada que os desenvolvedores usam desde que o MetricKit foi lançado, agora está formalmente obsoleto: a página de referência da Apple o marca como deprecated no 27.0 e orienta os desenvolvedores a usar o MetricManager no lugar.² A sessão 222 da WWDC26 deixa a exclusividade explícita: os novos tipos de métrica e diagnóstico vivem na nova API Swift e não são retroportados para a antiga.³ Se você ainda chama o MXMetricManager, não está apenas usando um estilo mais antigo; está cortado de tudo o que a Apple adicionar daqui para frente.

O lab também trouxe à tona uma confusão recorrente sobre de onde vêm os dados de campo e como lê-los. Kunal e Yanni traçaram a linha com clareza: o Instruments dá a você profiling local profundo em um dispositivo na sua mesa, enquanto o Xcode Organizer e o MetricKit dão telemetria de campo agregada de usuários reais em dispositivos reais. Os dois frequentemente discordam, e essa discordância é o ponto. Kunal descreveu desenvolvedores que perseguem um hang que conseguem reproduzir no Instruments enquanto o Organizer mostra que a real principal causa de hangs é algo completamente diferente, algo que nunca se reproduz na mesa.¹

A nova alavanca do lado do Organizer são as Metric Goals. Kunal as destacou como o único recurso que ele mais queria que os desenvolvedores experimentassem antes de deixar a WWDC. A sessão 258 detalha o que são: metas recomendadas que o Organizer deriva “com base em semelhanças técnicas e funcionais entre o seu app e outros apps”, combinadas com as suas próprias linhas de base históricas, abrangendo tempo de launch, taxa de hangs, gravações em disco, bateria, armazenamento e hitches.⁴ O lab enquadrou o valor em termos humanos. Cole descreveu um desenvolvedor segurando um app de vídeo e perguntando se o alto consumo de energia dele é um problema ou apenas o custo de reproduzir vídeo o dia todo. Antes das Metric Goals, ninguém conseguia responder. Agora o Organizer compara você com apps semelhantes e lhe dá uma linha de base a partir da qual raciocinar.¹

Mais um item de higiene dos dados de campo apareceu, e vale a pena declarar com clareza porque os desenvolvedores continuam errando: não crie o seu próprio cronômetro de launch. O lab relatou desenvolvedores inspecionando APIs do kernel para o horário de criação do processo e usando isso como marco de launch. A resposta de Yanni foi que o MetricKit e o Organizer deliberadamente não medem o launch desse jeito; eles medem o intervalo que o usuário de fato sente. A documentação da Apple confirma a definição: o tempo de launch é “o número de milissegundos entre o toque do usuário no seu ícone e o momento em que a sua primeira tela é desenhada”, medido depois da splash screen estática.⁶ O seu próprio cronômetro não consegue ver o momento do toque, porque o seu processo ainda nem existe. As ferramentas da Apple conseguem, e não adicionam nenhum overhead de medição ao seu app.

O fluxo de trabalho de energia que o time de fato recomenda

O conselho procedimental mais útil do lab foi sobre como flagrar problemas de energia que nunca aparecem na sua mesa. Kaspar e Kunal voltavam o tempo todo a um fluxo de trabalho: o trace untethered.

A mecânica, no enquadramento de Kaspar, é que você desconecta do Instruments, grava um trace no dispositivo que pode rodar por várias horas, depois compartilha o arquivo com o seu Mac e o abre no Instruments para analisá-lo mais tarde. O benefício são as condições do mundo real: você se desloca, passa por handoffs reais de rede móvel, deixa o dispositivo esquentar e captura o que de fato acontece em vez do que acontece numa sessão controlada de mesa. Kunal apontou isso como a forma de flagrar uma classe específica de bug, tarefas em segundo plano agendadas quando não deveriam, que é invisível enquanto você está conectado (tethered) e observando.¹

Esse fluxo de trabalho é o modo Power Profiler do Performance Trace, e vale ser preciso sobre a sua procedência: é um recurso do iOS 26 vindo da WWDC25, não uma novidade do iOS 27. A Apple o documenta em “Measuring your app’s power use with Power Profiler”. Você o habilita em Ajustes > Developer > Performance Trace, dispara-o com um controle da Central de Controle, compartilha o arquivo .aar resultante com o seu Mac e lê a energia detalhada por subsistema nas lanes de CPU, GPU, display e rede no Instruments.⁵ O lab o apresentou como a opção recomendada de referência, e não como manchete do 27. (O irmão genuinamente novo deste ano é o fluxo de trabalho de lookback collection e a CLI de macOS metalperftrace, que abordei no post Metal machine learning. São ferramentas diferentes para trabalhos diferentes; não as confunda.)

Mais duas técnicas da discussão sobre energia valem a pena guardar:

• Low Power Mode como proxy de dispositivo fraco. Terry ofereceu um truque para desenvolvedores que só têm hardware novo mas precisam saber como o app se comporta em hardware antigo: ligue o Low Power Mode. Ele desacelera as CPUs para economizar bateria, o que faz emergir problemas que você de outra forma só veria num dispositivo mais antigo. Ele acrescentou que isso também serve como boa prática geral de otimização, porque muitos usuários rodam o Low Power Mode por escolha e o seu app ainda deveria parecer bom ali.¹
• Device Conditions para simulação térmica e de rede. O lab mencionou repetidamente um “condition inducer” para forçar o app a um estado térmico elevado ou a um link de rede degradado. O nome oficial da Apple para o recurso é Device Conditions; o próprio palestrante não tinha certeza de onde ele fica no Xcode 27. Historicamente ficou na janela Devices e pode ser incorporado ao Device Hub. O palestrante do lab tomou cuidado sobre o que ele faz e o que não faz: induz artificialmente o comportamento de throttling de um dispositivo quente; ele não aquece de fato o hardware. Assim você pode observar como o seu app se comporta sob pressão térmica, mais hitches, mais hangs, sem assar o seu telefone.¹

E uma regra direta que apareceu mais de uma vez: nunca faça profiling no Simulator. Kaspar observou que o Simulator roda no seu Mac, então a performance dele não diz nada sobre a performance do dispositivo, independentemente de qual dispositivo você selecione. Use um dispositivo físico para profiling e apoie-se nos dados de campo do MetricKit e do Organizer para cobrir a diversidade de dispositivos que você não pode comprar.¹

Triagem de performance: térmica, disputa com IA e trabalho em pedaços

Quando as perguntas se voltaram para a estratégia de triagem, três orientações se destacaram.

O playbook térmico. Um desenvolvedor perguntou sobre um app de ARKit e Metal usado ao ar livre, sob luz solar direta, onde o dispositivo fica quente o tempo todo. A resposta de Kunal começou pela API: escute o ProcessInfo.thermalState e recue na experiência quando ele subir.¹ As alavancas específicas que o painel ofereceu: solicitar recursos de rede mais leves para que o dispositivo gaste menos tempo decodificando e fazendo parsing, trocar animações mais ricas por outras mais simples e reduzir a taxa de quadros ou a resolução de renderização sob pressão. Kunal observou que o sistema já reduz as taxas de quadros de animação e de display em estados térmicos mais altos, então parte do alívio é automática e você sobrepõe a sua própria por cima. A frase final de Marco sobre isso: empurrar menos pixels é menos trabalho, e “não dá para fugir da termodinâmica”. Você controla a computação do seu app; você não controla a física, então otimize com força na parte que é sua.¹

O modelo de disputa do Apple Intelligence. Uma pergunta incisiva indagou como o iOS 27 prioriza tarefas em segundo plano do app quando o sistema está ocupado com trabalho do Apple Intelligence. A resposta de Terry foi tranquilizadora e específica: muitos recursos do Apple Intelligence rodam no Neural Engine ou no Private Cloud Compute, então, se o seu app está usando a CPU enquanto uma carga de trabalho de IA usa o Neural Engine, os dois muitas vezes podem rodar concorrentemente sem disputar o mesmo recurso. A jogada defensiva que ele recomendou é estrutural: configure as tarefas em segundo plano em pequenos pedaços para que o sistema possa pausá-las e retomá-las, em vez de um único job monolítico que tem de recomeçar do zero toda vez que é interrompido. O trabalho em pedaços avança mesmo quando o escalonador não está rodando você com a frequência que você gostaria.¹

Cardinalidade do StateReporting. O novo recurso StateReporting do MetricKit permite fatiar métricas por estado da aplicação, o que é poderoso e fácil de usar mal. O lab deu uma regra clara sobre cardinalidade: não reporte valores exatos que mudam com frequência, como o número preciso de itens em uma lista. Em vez disso, coloque-os em buckets, pequeno, médio, grande, para que você possa depois perguntar “nessa faixa de tamanho, a performance regrediu?” sem pagar o custo de registrar cada contagem distinta. O exemplo de Yanni: uma lista de 1.000 itens e uma de 1.001 não fazem nenhuma diferença significativa, então registrar o número exato é puro overhead. Defina os limites que importam para a sua análise e reporte o bucket.¹

Sobre launch especificamente, o painel convergiu para um único modelo mental que amarra os conselhos de triagem: descubra o mínimo de dados de que você precisa para desenhar o primeiro quadro, carregue só isso e adie todo o resto. Terry alertou contra a falha comum de disparar uma pilha de trabalho em segundo plano e então bloquear a main thread até que tudo termine, o que congela o app inteiro durante o launch. Para ver se esse é o seu problema, Kaspar apontou para a visão de main thread do template System Trace, onde uma main thread bloqueada aparece diretamente. O painel também descreveu o System Trace expondo prioridades de thread, preempção e um histograma de troca de contexto, embora eu não tenha conseguido confirmar isso como recursos documentados do Instruments 27, então tome isso como a descrição da ferramenta feita pelo lab, e não como especificação.

Notas de ferramentas: o instrument do Foundation Models e uma rampa de entrada para iniciantes

Dois itens de ferramentas arrematam o lab.

Para desenvolvedores publicando recursos de Foundation Models, Kaspar descreveu a ferramenta do Instruments crescendo das métricas básicas de contagem de tokens do ano passado para um instrument completo de depuração que captura prompts e respostas e mostra quantos tokens estão sendo armazenados em cache.¹ O quadro preciso ao longo das sessões da WWDC26: o instrument do Foundation Models captura dados de prompt e resposta do dispositivo durante o trace (sessão 243, que também observa que a captura pode incluir informações sensíveis, por isso fica desligada em produção).⁷ As contagens de tokens em cache chegam pela API usage nas respostas do modelo (sessão 241).⁸ São dois mecanismos diferentes, um para a linha do tempo do trace e outro para a contabilidade por resposta, que vale a pena manter separados quando você lê os seus números.

Para iniciantes, o painel foi consistente sobre por onde começar. Marco recomendou o Time Profiler com a visão de flame graph como primeira passada, porque um flame graph mostra visualmente quanto uma call stack custa a você, em vez de fazer você ler números num outline. Kaspar acrescentou o modo Top Functions como o próximo passo, uma lista plana das funções mais pesadas para que você identifique os culpados num relance sem percorrer uma árvore de chamadas profundamente aninhada.¹ E o meta-conselho mais repetido do painel: meça antes de otimizar. O enquadramento de Kunal foi que a armadilha mais comum é telemetria insuficiente, o que leva os desenvolvedores a otimizar áreas que não rendem nenhum ganho real. O corolário de Terry sobre launch e trabalho em segundo plano: uma requisição de rede enviada na metade da frequência é um ganho de energia de graça.¹ Olhe o quadro completo antes de mergulhar em qualquer subsistema isolado.

Principais Conclusões

Para desenvolvedores iOS publicando hoje: - Migre do MXMetricManager para a nova API Swift MetricManager. A superfície antiga está obsoleta a partir do 27.0, e os novos tipos de métrica e diagnóstico são exclusivos da nova API.²³ - Abra o Xcode Organizer e confira as suas Metric Goals contra as linhas de base de apps semelhantes para launch, hangs, bateria, hitches, gravações em disco e armazenamento.⁴ - Pare de medir launch com o seu próprio cronômetro; o MetricKit e o Organizer medem a partir do toque no ícone, que o seu processo não consegue ver.⁶

Para triagem de performance e energia: - Use o trace untethered do Power Profiler (iOS 26, Ajustes > Developer > Performance Trace) para flagrar problemas de tarefas em segundo plano e de energia do mundo real que nunca se reproduzem na sua mesa.⁵ - Faça profiling em um dispositivo físico, nunca no Simulator, e use o Low Power Mode como substituto para hardware antigo que você não possui.¹ - Escute o ProcessInfo.thermalState e recue na taxa de quadros, resolução, riqueza de animação e peso de rede sob pressão.¹

Para times construindo recursos de IA: - Divida o trabalho em segundo plano em pedaços para que o escalonador possa pausá-lo e retomá-lo; o trabalho de CPU muitas vezes pode rodar ao lado das cargas de IA do Neural Engine e do Private Cloud Compute sem disputa.¹ - Coloque os valores do StateReporting em buckets (pequeno, médio, grande); nunca reporte contagens exatas que mudam rápido.¹ - Para Foundation Models, leia a ferramenta do Instruments para captura de prompt e resposta (sessão 243) e puxe as contagens de tokens em cache da API usage da resposta (sessão 241).⁷⁸

Este lab combina naturalmente com os mergulhos mais profundos da série: MetricKit e StateReporting no iOS 27 sobre fatiar métricas por estado do app, Instruments 27 e responsividade do app sobre os novos fluxos de diffing e detecção de hangs, e o ponto cego de performance sobre por que dados de campo e profiling de mesa discordam. O hub completo da série é a Apple Ecosystem Series.

Referências