Entrevistas de iOS testam o sistema de tipos do Swift, como o ARC gerencia memória, e se você consegue raciocinar sobre o estado da UI — além de pelo menos uma pergunta em que um retain cycle está escondido bem à vista. Abaixo estão as perguntas mais feitas, cada uma com uma resposta modelo. Middle: compreensão mais profunda, otimização e situações reais de trabalho.
@State é um valor que a view possui e altera. @Binding é uma referência ao @State de outra parte, passada para baixo para que uma view filha possa escrevê-lo. @ObservedObject observa um tipo de referência que publica mudanças e é possuído em outro lugar. O erro relacionado é usar @ObservedObject onde era preciso @StateObject — o objeto então é recriado a cada re-render.
Os dois expressam a mesma suspensão, mas await mantém o código linear e deixa os erros viajarem com throws em vez de um parâmetro de erro que dá para esquecer de checar. O compilador também garante concorrência estruturada: os filhos de uma task são cancelados junto com ela. A armadilha da migração é chamar uma função async a partir de um contexto síncrono, o que exige um Task explícito.
Que o código anotado roda na thread principal, verificado pelo compilador e não por convenção. Trabalho de UI precisa estar na main thread, e antes dos actors isso era uma verificação em runtime que você só descobria ao crashar. Marcar uma view model com @MainActor costuma ser mais simples do que fazer dispatch em cada ponto de chamada.
Porque uma table ou collection view mantém um pool pequeno de células e as reaproveita conforme você rola a tela, em vez de alocar uma por linha. O que quebra é o estado deixado na célula pelo ocupante anterior — uma imagem da linha três aparecendo na linha quarenta. prepareForReuse e cancelar a requisição de imagem em andamento resolvem isso.
O memory graph debugger mostra o que ainda está vivo e quem está segurando, o que geralmente já aponta o ciclo diretamente. Leaks e Allocations do Instruments respondem à mesma pergunta ao longo do tempo. Os culpados frequentes são closures capturando self fortemente, um delegate declarado como strong em vez de weak, e observers que nunca foram removidos.
Não fazer nada custoso na thread principal durante o scroll: decodificar imagens fora da main, guardar em cache o resultado já decodificado em vez dos dados brutos, e evitar layout que é recalculado a cada frame. Renderização off-screen de sombras e máscaras é o vilão silencioso — um corner radius com masksToBounds em muitas células custa mais do que parece.
Modele-os: um erro tipado que distingue falta de conectividade, um 5xx do servidor, um 4xx causado por você, e uma falha de decodificação — porque cada um merece uma mensagem e uma política de retry diferentes. Tentar de novo um 400 para sempre é o modo de falha errado. Erros de decodificação especialmente deveriam ser barulhentos em desenvolvimento e nunca engolidos silenciosamente.
Numa entrevista de verdade você fala sob pressão. O Cam faz essas mesmas perguntas, avalia cada resposta e mostra exatamente o que melhorar.
Praticar entrevista de Middle iOS (Swift) →