Estupidamente Acessível
Swift Concurrency

A Única Coisa Que Precisa de Compreender

Isolamento é a chave para tudo. É a resposta do Swift à pergunta: Quem tem permissão para mexer nestes dados agora?

Porquê Não Apenas Threads?

Durante décadas, escrevemos código concorrente a pensar em threads. O problema? Threads não nos impedem de dar um tiro no pé. Duas threads podem aceder aos mesmos dados simultaneamente, causando data races - bugs que crasham aleatoriamente e são quase impossíveis de reproduzir.

Num telemóvel, pode safar-se. Num servidor a lidar com milhares de pedidos concorrentes, data races tornam-se uma certeza - geralmente a aparecer em produção, numa sexta-feira. À medida que o Swift se expande para servidores e outros ambientes altamente concorrentes, "esperar o melhor" não funciona.

A abordagem antiga era defensiva: usar locks, dispatch queues, esperar não ter esquecido nada.

A abordagem do Swift é diferente: tornar data races impossíveis em tempo de compilação. Em vez de perguntar "em que thread está isto?", o Swift pergunta "quem tem permissão para mexer nestes dados agora?" Isto é isolamento.

Como Outras Linguagens Lidam Com Isso

Swift e Rust são as únicas linguagens mainstream que detetam data races em tempo de compilação. O trade-off? Uma curva de aprendizagem mais íngreme no início. Mas assim que compreende o modelo, o compilador protege-o.

Aqueles erros chatos sobre Sendable e isolamento de actor? Estão a detetar bugs que antes seriam crashes silenciosos.

Os Domínios de Isolamento

Agora que compreende isolamento (escritórios privados), vamos olhar para os diferentes tipos de escritórios no edifício do Swift.

MainActor: A Receção

O MainActor é um domínio de isolamento especial que corre na thread principal. É onde todo o trabalho de UI acontece.

@MainActor
@Observable
class ViewModel {
    var items: [Item] = []  // Estado da UI vive aqui

    func refresh() async {
        let newItems = await fetchItems()
        self.items = newItems  // Seguro - estamos no MainActor
    }
}

Actors: Escritórios de Departamento

Um actor é como um escritório de departamento - protege os seus próprios dados e permite apenas um visitante de cada vez.

actor BankAccount {
    var balance: Double = 0

    func deposit(_ amount: Double) {
        balance += amount  // Seguro! Apenas um chamador por vez
    }
}

Sem actors, duas threads leem balance = 100, ambas somam 50, ambas escrevem 150 - você perdeu $50. Com actors, o Swift automaticamente enfileira o acesso e ambos os depósitos completam corretamente.

Nonisolated: Os Corredores

Código marcado como nonisolated é como os corredores - não pertence a nenhum escritório e pode ser acessado de qualquer lugar.

actor UserSession {
    let userId: String          // Imutável - seguro ler de qualquer lugar
    var lastActivity: Date      // Mutável - precisa proteção do actor

    nonisolated var displayId: String {
        "User: \(userId)"       // Só lê dados imutáveis
    }
}

// Uso - não precisa de await para nonisolated
let session = UserSession(userId: "123")
print(session.displayId)  // Funciona sincronamente!

Use nonisolated para propriedades computadas que só leem dados imutáveis.

Como o Isolamento Se Propaga

Quando você marca um tipo com um isolamento de actor, o que acontece com seus métodos? E os closures? Entender como o isolamento se propaga é a chave para evitar surpresas.

Classes Herdam Seu Isolamento

@MainActor
class ViewModel {
    var count = 0           // Isolado no MainActor

    func increment() {      // Também isolado no MainActor
        count += 1
    }
}

Tudo dentro da classe herda @MainActor. Você não precisa marcar cada método.

Tasks Herdam o Contexto (Geralmente)

@MainActor
class ViewModel {
    func doWork() {
        Task {
            // Isso herda MainActor!
            self.updateUI()  // Seguro, nao precisa de await
        }
    }
}

Um Task { } criado de um contexto @MainActor fica no MainActor. Isso geralmente é o que você quer.

Task.detached Quebra a Herança

@MainActor
class ViewModel {
    func doWork() {
        Task.detached {
            // NAO esta mais no MainActor!
            await self.updateUI()  // Agora precisa de await
        }
    }
}

O Que Pode Cruzar Fronteiras

Agora que você sabe sobre domínios de isolamento (escritórios) e como eles se propagam, a próxima pergunta é: o que você pode passar entre eles?

Sendable: Seguro para Compartilhar

Esses tipos podem cruzar fronteiras de isolamento com segurança:

// Structs com dados imutáveis - como fotocópias
struct User: Sendable {
    let id: Int
    let name: String
}

// Actors se protegem - eles lidam com seus próprios visitantes
actor BankAccount { }  // Automaticamente Sendable

Automaticamente Sendable:

• Tipos de valor (structs, enums) com propriedades Sendable
• Actors (eles se protegem)
• Classes imutáveis (final class com apenas propriedades let)

Não-Sendable: Devem Ficar

Esses tipos não podem cruzar fronteiras com segurança:

// Classes com estado mutável - como documentos originais
class Counter {
    var count = 0  // Dois escritórios modificando isso = desastre
}

Por que essa é a distinção chave? Porque todo erro de compilador que você encontrar se resume a: "Você está tentando enviar um tipo não-Sendable através de uma fronteira de isolamento."

Quando o Compilador Reclama

Se o Swift diz que algo não é Sendable, você tem opções:

1. Faça um tipo de valor - use struct em vez de class
2. Isole - mantenha no @MainActor para que não precise cruzar
3. Mantenha não-Sendable - apenas não passe entre escritórios
4. Último recurso: @unchecked Sendable - você promete que é seguro (cuidado)

Como Cruzar Fronteiras

Você entende domínios de isolamento, você sabe o que pode cruzá-los. Agora: como você realmente se comunica entre escritórios?

A Palavra-Chave await

Quando você chama uma função em outro actor, você precisa de await:

actor DataStore {
    var items: [Item] = []

    func add(_ item: Item) {
        items.append(item)
    }
}

@MainActor
class ViewModel {
    let store = DataStore()

    func addItem(_ item: Item) async {
        await store.add(item)  // Requisição para outro escritório
        updateUI()             // De volta ao nosso escritório
    }
}

O await significa: "Envie essa requisição e pause até terminar. Posso fazer outro trabalho enquanto espero."

Suspensão, Não Bloqueio

A chave é a diferença entre bloqueio e suspensão:

• Bloqueio: Você senta na sala de espera olhando para a parede. Nada mais acontece.
• Suspensão: Você deixa seu telefone e faz outras coisas. Eles ligam quando estiver pronto.

// Thread fica ociosa, sem fazer nada por 5 segundos
Thread.sleep(forTimeInterval: 5)

// Thread está livre para fazer outro trabalho enquanto espera
try await Task.sleep(for: .seconds(5))

Iniciando Trabalho Async de Código Síncrono

Às vezes você está em código síncrono e precisa chamar algo async. Use Task:

@MainActor
class ViewModel {
    func buttonTapped() {  // Função síncrona
        Task {
            await loadData()  // Agora podemos usar await
        }
    }
}

Padrões Que Funcionam

O Padrão de Requisição de Rede

@MainActor
@Observable
class ViewModel {
    var users: [User] = []
    var isLoading = false

    func fetchUsers() async {
        isLoading = true

        // Isso suspende - thread está livre para fazer outro trabalho
        let users = await networkService.getUsers()

        // De volta no MainActor automaticamente
        self.users = users
        isLoading = false
    }
}

Sem DispatchQueue.main.async. O atributo @MainActor cuida disso.

Trabalho Paralelo com async let

func loadProfile() async -> Profile {
    async let avatar = loadImage("avatar.jpg")
    async let banner = loadImage("banner.jpg")
    async let details = loadUserDetails()

    // Os tres rodam em paralelo!
    return Profile(
        avatar: await avatar,
        banner: await banner,
        details: await details
    )
}

Prevenindo Toques Duplos

Esse padrão vem do guia de Matt Massicotte sobre sistemas com estado:

@MainActor
class ButtonViewModel {
    private var isLoading = false

    func buttonTapped() {
        // Guard SINCRONAMENTE antes de qualquer trabalho async
        guard !isLoading else { return }
        isLoading = true

        Task {
            await doExpensiveWork()
            isLoading = false
        }
    }
}

Erros Comuns a Evitar

Esses são erros comuns que até desenvolvedores experientes cometem:

Pensar que async = segundo plano

// Isso AINDA bloqueia a thread principal!
@MainActor
func slowFunction() async {
    let result = expensiveCalculation()  // Síncrono = bloqueante
    data = result
}

Se você precisa de trabalho feito em outro escritório, envie explicitamente para lá:

func slowFunction() async {
    let result = await Task.detached {
        expensiveCalculation()  // Agora em um escritório diferente
    }.value
    await MainActor.run { data = result }
}

Criar muitos actors

// Sobre-engenheirado - cada chamada requer caminhar entre escritórios
actor NetworkManager { }
actor CacheManager { }
actor DataManager { }

// Melhor - a maioria das coisas pode viver na recepção
@MainActor
class AppState { }

Usar MainActor.run em todo lugar

// Não faça isso - caminhando constantemente até a recepção
await MainActor.run { doMainActorStuff() }

// Faça isso - apenas trabalhe na recepção
@MainActor func doMainActorStuff() { }

Fazer tudo Sendable

Nem tudo precisa ser Sendable. Se você está adicionando @unchecked Sendable em todo lugar, você está fazendo fotocópias de coisas que não precisam sair do escritório.

Ignorar warnings do compilador

Cada warning do compilador sobre Sendable é o guarda de segurança te dizendo que algo não é seguro para carregar entre escritórios. Não ignore - entenda.

Erros Comuns do Compilador

Essas são as mensagens de erro reais que você verá. Cada uma é o compilador te protegendo de um data race.

"Sending 'self.foo' risks causing data races"

Solução 1: Use uma struct em vez de uma class

Solução 2: Mantenha em um actor:

@MainActor
class MyClass {
    var foo: SomeType  // Fica na recepção
}

"Non-sendable type cannot cross actor boundary"

Solução 1: Faça uma struct:

// Antes: class (não-Sendable)
class User { var name: String }

// Depois: struct (Sendable)
struct User: Sendable { let name: String }

Solução 2: Isole em um actor:

@MainActor
class User { var name: String }

"Actor-isolated property cannot be referenced"

Solução: Use await:

// Errado - metendo a mão diretamente
let value = myActor.balance

// Certo - requisição apropriada
let value = await myActor.balance

"Call to main actor-isolated method in synchronous context"

Solução 1: Faça o chamador @MainActor:

@MainActor
func doSomething() {
    updateUI()  // Mesmo isolamento, não precisa de await
}

Solução 2: Use await:

func doSomething() async {
    await updateUI()
}

Três Níveis de Swift Concurrency

Você não precisa aprender tudo de uma vez. Progrida através desses níveis:

Esses níveis não são limites rígidos - diferentes partes do seu app podem precisar de níveis diferentes. Um app principalmente-Nível-1 pode ter uma feature que precisa de padrões de Nível 2. Tudo bem. Use a abordagem mais simples que funcione para cada parte.

Nível 1: A Startup

Todos trabalham na recepção. Simples, direto, sem burocracia.

• Use async/await para chamadas de rede
• Marque classes de UI com @MainActor
• Use o modificador .task do SwiftUI

Isso cobre 80% dos apps. Apps como Things, Bear, Flighty, ou Day One provavelmente caem nessa categoria - apps que principalmente buscam dados e os exibem.

Nível 2: A Empresa em Crescimento

Você precisa lidar com múltiplas coisas de uma vez. Hora de projetos paralelos e coordenar equipes.

• Use async let para trabalho paralelo
• Use TaskGroup para paralelismo dinâmico
• Entenda cancelamento de tasks

Apps como Ivory/Ice Cubes (clientes Mastodon gerenciando múltiplas timelines e atualizações em streaming), Overcast (coordenando downloads, reprodução e sincronização em segundo plano), ou Slack (mensagens em tempo real através de múltiplos canais) podem usar esses padrões para certas features.

Nível 3: A Corporação

Departamentos dedicados com suas próprias políticas. Comunicação inter-escritório complexa.

• Crie actors personalizados para estado compartilhado
• Entendimento profundo de Sendable
• Executors personalizados

Apps como Xcode, Final Cut Pro, ou frameworks Swift server-side como Vapor e Hummingbird provavelmente precisam desses padrões - estado compartilhado complexo, milhares de conexões concorrentes, ou código nível-framework sobre o qual outros constroem.

Glossário: Mais Palavras-Chave Que Você Encontrará

Além dos conceitos básicos, aqui estão outras palavras-chave de concorrência do Swift que você verá no mundo real:

Quando Usar Cada Um

nonisolated - Ler propriedades computadas

Por padrão, tudo dentro de um actor está isolado - você precisa de await para acessar. Mas às vezes você tem propriedades que são inerentemente seguras de ler: constantes let imutáveis, ou propriedades computadas que só derivam valores de outros dados seguros. Marcar essas como nonisolated permite que chamadores as acessem sincronamente, evitando overhead async desnecessário.

actor UserSession {
    let userId: String  // Imutável, seguro de ler
    var lastActivity: Date  // Mutável, precisa proteção

    // Isso pode ser chamado sem await
    nonisolated var displayId: String {
        "User: \(userId)"  // Só lê dados imutáveis
    }
}

// Uso
let session = UserSession(userId: "123")
print(session.displayId)  // Não precisa de await!

@Sendable - Closures que cruzam fronteiras

Quando um closure escapa para rodar mais tarde ou em um domínio de isolamento diferente, o Swift precisa garantir que não causará data races. O atributo @Sendable marca closures que são seguros de passar através de fronteiras - eles não podem capturar estado mutável de forma insegura. O Swift frequentemente infere isso automaticamente (como com Task.detached), mas às vezes você precisa declarar explicitamente ao projetar APIs que aceitam closures.

@MainActor
class ViewModel {
    var items: [Item] = []

    func processInBackground() {
        Task.detached {
            // Esse closure cruza do task detached para o MainActor
            // Deve ser @Sendable (Swift infere isso)
            let processed = await self.heavyProcessing()
            await MainActor.run {
                self.items = processed
            }
        }
    }
}

// @Sendable explícito quando necessário
func runLater(_ work: @Sendable @escaping () -> Void) {
    DispatchQueue.global().asyncAfter(deadline: .now() + 1) {
        work()
    }
}

withCheckedContinuation - Conectando APIs antigas

Muitas APIs antigas usam completion handlers em vez de async/await. Em vez de reescrevê-las completamente, você pode envolvê-las usando withCheckedContinuation. Essa função suspende o task atual, te dá um objeto continuation, e retoma quando você chama continuation.resume(). A variante "checked" detecta erros de programação como resumir duas vezes ou nunca resumir.

// API antiga baseada em callbacks
func fetchUser(id: String, completion: @escaping (User?) -> Void) {
    // ... chamada de rede com callback
}

// Envolvida como async
func fetchUser(id: String) async -> User? {
    await withCheckedContinuation { continuation in
        fetchUser(id: id) { user in
            continuation.resume(returning: user)  // Conecta de volta!
        }
    }
}

Para funções que lançam, use withCheckedThrowingContinuation:

func fetchUserThrowing(id: String) async throws -> User {
    try await withCheckedThrowingContinuation { continuation in
        fetchUser(id: id) { result in
            switch result {
            case .success(let user):
                continuation.resume(returning: user)
            case .failure(let error):
                continuation.resume(throwing: error)
            }
        }
    }
}

AsyncStream - Conectando fontes de eventos

Enquanto withCheckedContinuation lida com callbacks únicos, muitas APIs entregam múltiplos valores ao longo do tempo - métodos delegate, NotificationCenter, ou sistemas de eventos personalizados. AsyncStream conecta esses ao AsyncSequence do Swift, permitindo que você use loops for await. Você cria um stream, guarda sua continuation, e chama yield() cada vez que um novo valor chega.

class LocationTracker: NSObject, CLLocationManagerDelegate {
    private var continuation: AsyncStream<CLLocation>.Continuation?

    var locations: AsyncStream<CLLocation> {
        AsyncStream { continuation in
            self.continuation = continuation
        }
    }

    func locationManager(_ manager: CLLocationManager,
                        didUpdateLocations locations: [CLLocation]) {
        for location in locations {
            continuation?.yield(location)
        }
    }
}

// Uso
let tracker = LocationTracker()
for await location in tracker.locations {
    print("Nova localização: \(location)")
}

Task.isCancelled - Cancelamento cooperativo

Swift usa cancelamento cooperativo - quando um task é cancelado, ele não para imediatamente. Em vez disso, uma flag é definida, e é sua responsabilidade verificá-la periodicamente. Isso te dá controle sobre limpeza e resultados parciais. Use Task.checkCancellation() para lançar imediatamente, ou verifique Task.isCancelled quando quiser lidar com cancelamento graciosamente (como retornando resultados parciais).

func processLargeDataset(_ items: [Item]) async throws -> [Result] {
    var results: [Result] = []

    for item in items {
        // Verifica antes de cada operação cara
        try Task.checkCancellation()  // Lança se cancelado

        // Ou verifica sem lançar
        if Task.isCancelled {
            return results  // Retorna resultados parciais
        }

        let result = await process(item)
        results.append(result)
    }

    return results
}

Task.detached - Escapando do contexto atual

Um Task { } regular herda o contexto atual do actor - se você está no @MainActor, o task roda no @MainActor. Às vezes isso não é o que você quer, especialmente para trabalho intensivo de CPU que bloquearia a UI. Task.detached cria um task sem contexto herdado, rodando em um executor de fundo. Use com moderação - na maioria das vezes, Task regular com pontos await apropriados é suficiente e mais fácil de raciocinar.

@MainActor
class ImageProcessor {
    func processImage(_ image: UIImage) {
        // NÃO FAÇA: Isso ainda herda o contexto do MainActor
        Task {
            let filtered = applyFilters(image)  // Bloqueia main!
        }

        // FAÇA: Task detached roda independentemente
        Task.detached(priority: .userInitiated) {
            let filtered = await self.applyFilters(image)
            await MainActor.run {
                self.displayImage(filtered)
            }
        }
    }
}

@preconcurrency - Vivendo com código legado

Silencia warnings ao importar módulos ainda não atualizados para concorrência:

// Suprime warnings desse import
@preconcurrency import OldFramework

// Ou em uma conformance de protocolo
class MyDelegate: @preconcurrency SomeOldDelegate {
    // Não avisa sobre requisitos não-Sendable
}

Leitura Adicional

Este guia destila os melhores recursos sobre concorrência em Swift.