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. Senior: arquitetura, trade-offs, mentoria e tomada de decisão.
Pela complexidade real do app. O MVC da Apple é suficiente para uma tela que mostra e edita uma única coisa; o MVVM se justifica quando o estado da view é complexo o bastante para valer a pena testar separadamente; uma arquitetura unidirecional compensa quando o estado é compartilhado entre muitas telas e os bugs são sobre esse estado saindo de sincronia. Escolher logo a opção mais pesada custa velocidade por anos.
Meça primeiro — o resumo de tempo de build mostra quais arquivos dominam, e geralmente é um punhado com inferência de tipos pesada. Depois: tipos explícitos onde a inferência é cara, modularização para que uma mudança recompile apenas um módulo, e menos otimizações whole-module no debug. Conselho genérico sem medir geralmente não muda nada.
Comece pela frequência e pelo agrupamento no relatório de crash — quais versões de sistema, quais dispositivos, qual versão do app, e o que o usuário estava fazendo. Adicione logging de breadcrumbs em volta do caminho suspeito e publique, porque a forma mais rápida de reproduzir algo raro é instrumentar a população que está sofrendo com isso. Adivinhar um conserto e publicar não ensina nada se a taxa não mudar.
A migração leve resolve mudanças aditivas automaticamente; qualquer coisa que transforme dados precisa de um mapping model e de um caminho testado a partir de cada versão que ainda está em uso. A restrição que as pessoas esquecem é que usuários pulam versões — alguém atualiza a partir de um release de dois anos atrás, então a cadeia de migração precisa funcionar a partir de cada uma delas, não só da última.
Partindo do princípio de que versões antigas vão viver indefinidamente: a API precisa continuar compatível com versões anteriores, funcionalidades que exigem mudança no cliente precisam de uma flag do lado do servidor, e tudo que for removido precisa ser tolerado por clientes que ainda o chamam. Vale a pena ter um kill switch antes do release que vai precisar dele. Rollout em fases limita o alcance do erro que você ainda não encontrou.
Lógica de negócio e qualquer coisa com uma regra — preços, validação, máquinas de estado — como testes unitários, porque são rápidos e estáveis. Um número pequeno de testes de UI cobrindo os caminhos críticos que nunca podem quebrar, aceitando que são lentos e ocasionalmente flaky. Testar que um botão é azul é o ponto em que os conjuntos de teste viram só manutenção.
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 Senior iOS (Swift) →