Swift 6: A Migração da Indústria para a Segurança Concorrente sem Data Races

Apresentadora: Juliana Santos Convidado: Rafael Costa (Engenheiro de Software Senior e Especialista em iOS) Apresentadora: E aí, pessoal, bem-vindos de volta ao Allur! Eu sou a Juliana Santos e hoje a gente vai mergulhar em um assunto que está tirando o sono — e ao mesmo tempo trazendo um alívio enorme — para a comunidade de desenvolvimento mobile. Vamos falar sobre o Swift 6. Apresentadora: E para desbravar esse novo mundo comigo, eu trouxe um cara que manja muito de ecossistema Apple. Ele é Tech Lead, já passou por grandes empresas enfrentando codebases gigantescas e está na linha de frente dessa migração para o Swift 6. Seja muito bem-vindo ao Allur, Rafael Costa! Tudo certo, Rafa? Convidado: Tudo ótimo, Ju! Valeu demais pelo convite. É um prazer estar aqui no Allur. Esse assunto do Swift 6 é tipo aquele "divisor de águas", né? A gente estava acostumado com um jeito de fazer as coisas e agora o jogo mudou de patamar. Apresentadora: Com certeza! E olha, vamos começar do básico porque nem todo mundo é especialista em concorrência. A grande promessa do Swift 6 é acabar com os *data races* em tempo de compilação. Mas, explica pra gente: na prática, o que é esse "fantasma" do *data race* que tanto assombra os desenvolvedores? Convidado: Cara, o *data race* é o pesadelo de qualquer dev. Basicamente, ele acontece quando dois fios de execução — as threads — tentam acessar e modificar o mesmo pedaço de memória ao mesmo tempo. Imagina dois garçons tentando escrever em cima da mesma comanda ao mesmo tempo. No final, ninguém entende o que foi pedido, a conta vem errada e o cliente fica bravo. No app, isso se traduz em valores bizarros, variáveis que mudam do nada e, claro, o crash inesperado. O pior é que ele é não-determinístico. Ele funciona na sua máquina, mas trava no celular do cliente porque o timing das threads foi diferente. É muito traiçoeiro. Apresentadora: Nossa, e quem nunca passou horas num *debug* infinito tentando achar isso, né? E aí entra o Swift 6. Pelo que eu li, agora existe um modo "opt-in" de segurança. O compilador virou um fiscal de trânsito? Convidado: Exatamente isso! O Swift 6 introduziu o modo de concorrência estrita. Quando você ativa essa flag no projeto, o compilador para de ser só aquele cara que transforma código em binário e vira um auditor proativo. Ele olha pro seu código e fala: "Opa, Juliana, você está tentando acessar esse array aqui de dois lugares diferentes sem proteção. Não vou deixar você compilar até que você resolva isso". Ele elimina o erro antes mesmo do app rodar. É uma mudança de paradigma: a gente para de caçar bug em produção e começa a resolver no design do código. Apresentadora: Massa! Mas imagino que para isso funcionar, a gente precise de ferramentas novas, certo? No post que a gente baseou este episódio, fala-se muito de *Actors* e do protocolo *Sendable*. Como que esses dois trabalham juntos? Convidado: Essa é a "dupla dinâmica" do Swift 6. O *Actor* é tipo um segurança de uma sala VIP. Se você tem um estado mutável — tipo um cache ou uma lista de usuários — você coloca ele dentro de um *Actor*. O diferencial é que o *Actor* garante que apenas uma tarefa por vez possa acessar o que está lá dentro. Ele serializa o acesso. Se dez threads pedirem algo pro *Actor*, ele vai atender uma por uma, organizadinho. Apresentadora: Ah, entendi! Então ele resolve aquele problema dos garçons que você citou. Agora só um garçom escreve na comanda por vez. Convidado: Perfeito! E aí entra o *Sendable*. Ele é um protocolo que diz pro compilador: "Ei, esse dado aqui é seguro para atravessar a fronteira entre threads". Se você tem um objeto que pode ser alterado de qualquer lugar, o Swift vai dizer que ele não é *Sendable* e vai te dar um erro se você tentar passar ele para um *Actor*. Agora, se for uma *Struct* simples, que é copiada e não referenciada, ela é *Sendable* por natureza. É como se o *Sendable* fosse o passaporte carimbado que permite que a informação viaje com segurança pelo app. Apresentadora: Cara, faz muito sentido, mas eu fico pensando no mundo real. A gente sabe que a maioria das empresas não está começando um app do zero hoje. Tem muito código legado por aí, usando *DispatchQueue*, *locks* manuais... Como é que faz essa migração sem quebrar tudo? Deve ser um desafio gigante, né? Convidado: Putz, é o grande desafio do momento! Migrar uma codebase legada para o Swift 6 não é apertar um botão e pronto. É uma maratona. Se você ativar a concorrência completa hoje num projeto grande, prepare-se para ver milhares de avisos e erros. O segredo que a gente tem usado é a migração gradual. O Swift permite que você ative essas verificações módulo por módulo. Você começa protegendo seus *Singletons* globais, transforma os caches em *Actors*, e vai limpando os erros aos poucos. Tem umas ferramentas como o `@preconcurrency import` que ajudam a lidar com bibliotecas que ainda não se atualizaram. É um trabalho de formiguinha, mas que paga muito a conta lá na frente. Apresentadora: E você acha que esse esforço todo vale a pena? Digo, comercialmente falando, para as empresas. Porque refatorar consome tempo e dinheiro. Convidado: Sem dúvida nenhuma! A longo prazo, o custo de manutenção cai drasticamente. Menos tempo depurando bugs impossíveis significa mais tempo criando funcionalidades novas. Além disso, a performance melhora porque o modelo de concorrência do Swift é muito otimizado. A indústria está caminhando para um nível de robustez que a gente não via antes. O desenvolvedor que dominar Swift 6 agora vai estar muito à frente, porque isso vai se tornar o padrão ouro de qualidade. Apresentadora: É o fim da era do "na minha máquina funciona", pelo menos para concorrência (risos). Convidado: (Risos) Exatamente! Agora é "se o compilador deixou, eu confio". Apresentadora: Sensacional, Rafa! Pra gente fechar, qual dica você dá para quem está ouvindo e quer começar a se aventurar no Swift 6 hoje? Convidado: Minha dica é: não se assuste com os erros de compilação. Eles são seus amigos. Comecem lendo a documentação oficial sobre *Structured Concurrency* e tentem aplicar os *Actors* em projetos pequenos. Tem muito conteúdo bom saindo, inclusive no blog da Apple e em fóruns da comunidade. E, claro, ativem a flag de *Strict Concurrency* no modo "targeted" primeiro, para sentir o drama antes de ir pro "complete". Apresentadora: Dicas de ouro! Bom, chegamos ao fim de mais um Allur. Rafa, valeu demais por compartilhar sua experiência com a gente. Foi um papo muito esclarecedor, cara! Convidado: Eu que agradeço, Ju! Foi massa demais. Valeu pessoal, e boa sorte nas migrações! Apresentadora: Valeu por sintonizar o Allur, pessoal! Hoje aprendemos que o Swift 6 não veio para complicar, mas para nos proteger de nós mesmos e desses bugs chatos de concorrência. Se você quer saber mais sobre Swift, desenvolvimento mobile ou as tendências de Go e PHP, não esquece de seguir a gente nas redes sociais e conferir os links na descrição do episódio. Até a próxima e... código seguro para todo mundo!