Toda vez que sai conversa sobre uma versão “7” de uma linguagem, a gente já fica meio desconfiado: será que é mudança de verdade ou só número novo para gerar barulho? No caso do Swift 7, o ponto interessante é outro. Não é tanto uma lista de recursos novos, e sim a sensação de que várias decisões que a Apple vinha empurrando aos poucos desde o Swift 6 finalmente deixam de ser opcionais. Para quem mantém app em produção, isso muda o jogo bem mais do que qualquer açúcar sintático bonito.
Antes de tudo, um aviso honesto: até o momento em que escrevo este texto, o Swift 7 ainda não foi lançado oficialmente, e não existe data confirmada pela Apple. O que dá para fazer — e é o que vou fazer aqui — é olhar para a direção que a linguagem vem tomando no Swift 6.2 e 6.3, ler os documentos de visão do Swift Evolution e separar o que já é concreto do que ainda é expectativa. Spoiler: o tema central é segurança contra data races, e ele toca em quase tudo que a gente escreve.
Por que esse assunto importa agora
O Swift sempre foi uma linguagem em movimento, mas o que está em jogo aqui não é estética. É o tipo de mudança que faz um projeto que compilava ontem parar de compilar amanhã, com o terminal cheio de vermelho. Se você abrir um projeto antigo com o modo de linguagem mais novo ligado e levar um susto, saiba que não é bug seu: é o compilador finalmente cobrando coisas que ele antes só sussurrava em forma de warning.
Esse movimento importa porque mexe com a base. Não é uma API nova que você adota quando quiser. É o modelo de concorrência inteiro virando padrão, com o compilador deixando de pedir licença. Quem entender isso cedo migra com calma; quem ignorar vai descobrir na marra no dia em que atualizar o Xcode.
O contexto: a estrada que leva até aqui
Para entender o Swift 7, vale lembrar de onde a gente veio. O Swift 6 introduziu o conceito de segurança completa contra data races (complete data-race safety), só que de um jeito opcional: você ligava o “modo de linguagem Swift 6” e o compilador começava a apontar acessos perigosos a estado compartilhado entre threads. Quem não ligava, continuava no modo antigo, com a vida de sempre.
O problema é que esse rigor todo, no início, virou sinônimo de dor de cabeça. Muita gente reclamou que precisava espalhar anotações de concorrência por todo canto, mesmo em código que nem tentava ser paralelo — tela de UI, scriptzinho, coisa simples. Foi aí que apareceu o documento de visão “Improving the Approachability of Data-Race Safety”, com uma ideia central: a maioria do código deveria ser tratada como single-threaded por padrão, e você opta por concorrência quando realmente precisa, em vez do contrário.
O Swift 6.2 já trouxe várias peças dessa visão de forma opcional: isolamento padrão no @MainActor por módulo, o atributo @concurrent para marcar o que deve sair da thread principal de propósito, melhorias no nonisolated, e por aí vai. O Swift 6.3 refinou os diagnósticos, reduzindo falsos positivos. O Swift 7, dentro dessa lógica, é o ponto em que esses comportamentos deixam de ser “ligue se quiser” e passam a ser o default. É menos uma revolução e mais uma cobrança de fatura.
O que está em jogo no Swift 7
A leitura mais honesta é agrupar as mudanças em coisas que são de fato da linguagem e coisas que são do ecossistema (SwiftUI, frameworks da Apple, design do iOS). Muita matéria mistura tudo, e isso confunde. Vamos por partes.
1. Concorrência estrita deixa de ser opcional. Os warnings de data race que o Swift 6 mostrava tendem a virar erros de compilação. Na prática, o que antes era “atenção, talvez isso dê problema” passa a ser “não compila”. Se houver corridas de dados escondidas no seu código — aquele singleton mutável acessado de vários lugares, por exemplo — elas vão aparecer todas de uma vez.
2. Macros mais integradas. As macros existem desde o Swift 5.9, então não são novidade absoluta. O que muda é o grau de integração: elas aparecem cada vez mais na biblioteca padrão e no próprio SwiftUI, virando uma ferramenta comum de metaprogramação em vez de recurso experimental.
3. Fluxo de dados do SwiftUI com @Observable. O @Observable (também de 5.9) se consolida como o padrão recomendado, no lugar do velho combo ObservableObject + @Published na maioria dos casos.
4. Liquid Glass e iOS 26. O novo design Liquid Glass do iOS 26 muda como a gente empilha views e aplica materiais. Importante: isso é do sistema e do SwiftUI, não da linguagem Swift em si.
5. APIs de IA no dispositivo. A Apple vem expondo modelos no próprio aparelho via framework de Foundation Models, permitindo resumo, classificação e ferramentas de texto sem mandar dado para a nuvem. Também é ecossistema, não linguagem — e ainda está amadurecendo.
Repare que, dos cinco pontos, só o primeiro é uma mudança profunda da linguagem. Os outros já existiam ou pertencem ao redor do Swift. Isso não diminui a importância deles, mas ajuda a calibrar a expectativa: o coração do “Swift 7 parece outra linguagem” é a concorrência.
Impacto técnico: o que muda no código do dia a dia
Vamos sair do abstrato. O cenário mais comum de quebra é estado mutável compartilhado sem proteção. Um exemplo clássico que hoje passa com warning e, na direção do Swift 7, vira erro:
// Shared mutable state touched from different tasks.
final class Counter {
var value = 0
}
let counter = Counter()
// Today: a concurrency warning. In Swift 7's direction: a hard error.
// 'Counter' is not Sendable and crosses an isolation boundary here.
Task.detached {
counter.value += 1
}A boa notícia é que a solução também fica mais simples com a visão de “concorrência acessível”. Quando o módulo usa isolamento padrão no @MainActor, um tipo como esse já nasce preso à thread principal, sem você anotar nada, e o acesso deixa de ser uma corrida:
// With module default isolation set to @MainActor (opt-in today, the
// expected default tomorrow), this type lives on the main actor.
final class ProfileModel {
var name = ""
func update(_ value: String) {
name = value // runs on the main actor — no data race possible
}
}E quando você quer sair da thread principal de propósito — um parsing pesado, uma leitura de disco —, marca isso explicitamente. A intenção vira parte do código, não um acidente:
// @concurrent makes "leave the main actor" an explicit, reviewable choice.
@concurrent
func parseLargeFile(_ url: URL) async throws -> [Record] {
let data = try Data(contentsOf: url)
return decode(data)
}No lado do SwiftUI, o ganho de trocar ObservableObject por @Observable é concreto e fácil de ver. O modelo antigo dependia de @Published e reanalisava boa parte da árvore de observação; o novo rastreia exatamente quais propriedades a view leu no corpo dela:
// Old pattern
class CartViewModel: ObservableObject {
@Published var items: [CartItem] = []
}
// Swift 7 way — SwiftUI re-renders only views that actually read 'items'
@Observable
class CartViewModel {
var items: [CartItem] = []
}Quem é afetado por tudo isso? Basicamente todo mundo que mantém app iOS em produção. Mas a dor não é distribuída por igual: ela se concentra em singletons, caches globais, managers compartilhados e qualquer estado mutável que viaja entre actors. É ali que mora a maior parte do trabalho de migração.
Pontos de atenção (e onde a propaganda exagera)
Aqui é onde vale segurar o hype. O artigo que serviu de ponto de partida para este texto trazia algumas impreciões que é melhor corrigir, para não sair plantando informação errada:
- Swift 7 ainda não existe oficialmente. Não há data confirmada nem release notes finais. Tudo que se fala sobre “o que será obrigatório” é projeção baseada na trajetória do 6.2/6.3 e nos documentos de visão.
- Macros e @Observable não são novidade do 7. Os dois chegaram no Swift 5.9. O que muda é o grau de adoção, não a existência.
- Liquid Glass e Apple Intelligence não são a linguagem. São sistema operacional e frameworks. Misturar isso com “Swift 7” infla a sensação de mudança.
- O nome real do framework de IA é Foundation Models, e não um
import AppleIntelligencemágico. O código desse tipo que circula por aí costuma ser ilustrativo, não a API de verdade.
Além disso, há um custo real de migração que ninguém deveria varrer para baixo do tapete. Transformar warnings em erros significa que projetos grandes podem simplesmente parar de compilar até você resolver cada ponto. Bibliotecas de terceiros que ainda não se adaptaram viram gargalo. E há o risco clássico de gente sair usando escapes como @unchecked Sendable ou nonisolated(unsafe) só para calar o compilador — o que recria exatamente o perigo que a feature queria eliminar.
Oportunidades para quem se antecipa
Apesar do incomodo, esse tipo de mudança abre espaço para ganho real. Quem encara a migração agora, com calma, sai na frente:
- Código mais previsível. Race condition é o tipo de bug que aparece “de vez em quando” e some quando você vai investigar. Resolver isso em tempo de compilação tira uma classe inteira de problemas da produção.
- Menos boilerplate com macros. Vale aprender a escrever as suas próprias para eliminar código repetitivo — rotas de API, chaves de configuração, mapeamentos — sem perder legibilidade.
- SwiftUI mais leve. Migrar para @Observable tende a reduzir re-render desnecessário, o que aparece direto em telas complexas e listas grandes.
- Preparação gradual. Dá para ligar o modo de linguagem mais rigoroso módulo por módulo, em vez de tudo de uma vez. Comece pelos pontos críticos de estado compartilhado e avance aos poucos.
Um caminho prático que funciona bem: criar um app pequeno, ou um módulo interno isolado, e reescrever com a mentalidade nova. As mensagens de erro do compilador, que melhoraram bastante no 6.3, viram um guia honesto do que precisa mudar no resto do código.
Conclusão
O Swift 7, do jeito que dá para enxergar hoje, não é sobre encher a linguagem de recurso novo. É sobre a Apple parar de pedir licença no tema de concorrência. O que era opcional vira padrão, o que era warning vira erro, e o compilador passa a exigir que a gente seja explícito sobre onde o código roda. Isso dói na migração, mas empurra todo mundo para código mais seguro.
Minha leitura, sem exagero, é esta: o “parece uma linguagem nova” vem muito mais da quebra de hábitos antigos do que de mil novidades. Se você já vinha tratando concorrência a sério desde o Swift 6, a transição vai ser suave. Se vinha empurrando com a barriga, esse é o momento de começar — auditando estado compartilhado e adotando @Observable antes de ser obrigado.
De olho daqui para frente: acompanhe os documentos de visão e as propostas no Swift Evolution, porque é lá que o “Swift 7 oficial” está sendo desenhado de verdade. Quando a data sair, quem já estiver com o estado compartilhado em ordem vai só apertar um botão. O resto vai passar um fim de semana inteiro encarando terminal vermelho. 🚀