Habilidade de Especialista em SwiftUI

Quando Usar

Use ao escrever, revisar ou refatorar código SwiftUI para iOS ou macOS, incluindo gerenciamento de estado e fluxo de dados @Observable, composição e invalidação/desempenho de views, listas e identidade ForEach, uso de ambiente, localização, animações, adoção de Liquid Glass, migração...

Regras de Operação

• Consulte references/latest-apis.md no início de cada tarefa para evitar APIs depreciadas
• Prefira APIs nativas do SwiftUI em vez de ponte UIKit/AppKit, a menos que o ponte seja necessário
• Concentre-se na correção e no desempenho; não imponha arquiteturas específicas (MVVM, VIPER, etc.)
• Incentive a separação da lógica de negócios das views para testabilidade sem ditar como
• Siga as Diretrizes de Interface Humana e os padrões de design de API da Apple
• Adote o Liquid Glass apenas quando explicitamente solicitado pelo usuário (veja references/liquid-glass.md)
• Apresente otimizações de desempenho como sugestões, não como requisitos
• Use o gating #available com fallbacks sensatos para APIs específicas de versão

Fluxo de Tarefas

Revisar código SwiftUI existente

• Leia o código sob revisão e identifique quais tópicos se aplicam
• Sinalize APIs depreciadas (compare com references/latest-apis.md)
• Execute o Topic Router abaixo para cada tópico relevante
• Valide o gating #available e os caminhos de fallback para recursos do iOS 26+

Melhorar código SwiftUI existente

• Audite a implementação atual contra os tópicos do Topic Router
• Substitua APIs depreciadas por equivalentes modernos de references/latest-apis.md
• Refatore hot paths para reduzir atualizações de estado desnecessárias
• Extraia corpos de views complexos em subviews separadas
• Sugira downsampling de imagem quando UIImage(data:) for encontrado (otimização opcional, veja references/image-optimization.md)

Implementar novo recurso SwiftUI

• Projete o fluxo de dados primeiro: identifique o estado próprio vs. injetado
• Estruture views para diffing otimizado (extraia subviews cedo)
• Aplique padrões de animação corretos (implícito vs. explícito, transições)
• Use Button para todos os elementos clicáveis; adicione agrupamento de acessibilidade e rótulos
• Gate APIs específicas de versão com #available e forneça fallbacks

Gravar um novo trace do Instruments

Acione quando o usuário pedir para "gravar um trace", "perfilar o app", "capturar uma sessão", etc. Referência completa: references/trace-recording.md.

1. Confirmar alvo — anexar a um app em execução, iniciar um app ou gravar todos os processos? Se o usuário não disse, pergunte. Liste dispositivos conectados quando útil:

   python3 "${SKILL_DIR}/scripts/record_trace.py" --list-devices
   

2. Escolher um template baseado no tipo de alvo — o template SwiftUI preenche a linha do SwiftUI em qualquer dispositivo real: um dispositivo físico iOS/iPadOS ou o Mac host. A única exceção é o Simulador iOS, onde a linha do SwiftUI volta vazia — mude para --template "Time Profiler" nesse caso (ainda fornece Time Profiler + Hangs + Animation Hitches). Sempre verifique --list-devices: tipo simulators → Time Profiler; tipo devices (dispositivos reais e o Mac host) → padrão SwiftUI. Tabela de decisão completa em references/trace-recording.md.
3. Iniciar a gravação. Para sessões controladas por agente onde o usuário diz "Eu avisarei quando terminar", comece em segundo plano e use um arquivo de parada:

   python3 "${SKILL_DIR}/scripts/record_trace.py" \
       --device "<name|udid>" --attach "<AppName>" \
       --stop-file /tmp/stop-trace --output ~/Desktop/session.trace
   

   Para sessões interativas, apenas diga ao usuário para pressionar Ctrl+C quando terminar.
4. Sinalizar parada — quando o usuário disser que terminou de usar o app, touch /tmp/stop-trace. O script faz SIGINT no xctrace de forma limpa e espera até 60s para finalização.
5. Analisar o trace resultante (fluxo para o fluxo "Melhoria baseada em trace" abaixo).

Melhoria baseada em trace (.trace do Instruments fornecido)

Acione sempre que a solicitação do usuário referenciar um arquivo de código-fonte SwiftUI .trace. Um arquivo de código-fonte SwiftUI alvo é opcional — se fornecido, cite linhas específicas; se não, recomende onde procurar com base nos nomes de views e símbolos que o trace já revela.

Referência completa: references/trace-analysis.md. Resumo do padrão de composição:

1. Escopo da análise. Pergunte a si mesmo: o usuário quer o trace inteiro ou uma fatia?
   • "focar em X / depois de X / entre X e Y / durante X" → resolver para uma janela primeiro (veja passo 2).
   • Nenhuma pista de escopo → analisar o trace inteiro.
2. Resolver uma janela (apenas se o usuário escopou). O parser expõe dois modos de descoberta:

…