O que há de novo no Swift (2026): a atualização da WWDC26

A Apple lançou duas versões do Swift em um único ciclo da WWDC: a 6.3 e a 6.4 chegaram juntas, e a sessão “What’s new in Swift” cobriu ambas como um único arco de trabalho¹. O enquadramento importa porque as mudanças se dividem claramente em dois públicos. A maioria dos desenvolvedores recebe ergonomias menores, de uso diário (dispensar os parênteses em torno de opcionais any, condensar uma dúzia de nomes de plataforma @available em um único anyAppleOS, silenciar um aviso de descontinuação em exatamente uma declaração). Um grupo menor que escreve código sensível ao desempenho recebe uma recompensa que levou anos para acontecer: o sistema de propriedade agora alcança os laços for, as propriedades computadas e a própria biblioteca padrão.

O Swift em 2026 também é visivelmente um projeto multiplataforma e multilinguagem. A Apple anunciou um SDK oficial do Swift para Android, distribuído via swift.org⁶, uma ponte mais rápida com JavaScript por meio do WebAssembly, a capacidade de exportar funções Swift de volta para C com um novo atributo @C e um backend Swift Build que agora alimenta o Swift Package Manager por padrão¹. Este post percorre as quatro sessões que definem a história do Swift em 2026: as atualizações de linguagem e biblioteca (262), o caminho de migração para o Swift Testing (267), serviços em tempo real com gRPC (265) e computação numérica com MLX Swift (328).

TL;DR

• O Swift 6.3 e o 6.4 foram lançados juntos na WWDC26. Ergonomias diárias: any/some opcional sem parênteses, disponibilidade anyAppleOS, o atributo @diagnose para controle de avisos por declaração e seletores de módulo (::) para colisões de nomes¹.
• O sistema de propriedade alcançou o código comum: um novo protocolo Iterable permite que os laços for peguem emprestados (borrow) os elementos em vez de copiá-los, e os acessadores borrow/mutate substituem get/set para evitar a cópia de valores grandes em propriedades computadas¹.
• Novos tipos da biblioteca padrão trazem as versões seguras de antigos padrões inseguros: UniqueArray, UniqueBox, uma Continuation de retomada única e Ref/MutableRef para guardar um empréstimo ou uma mutação em uma variável¹.
• O Swift Testing agora interopera com o XCTest nas duas direções, com quatro modos (limited, complete, strict, none); o Xcode 27 habilita a interoperabilidade por padrão². A superfície @Test, @Suite, #expect e #require está documentada na referência do Swift Testing da Apple⁵.
• O gRPC Swift chegou ao ponto em que você gera um cliente tipado a partir de um arquivo .proto e obtém RPCs unários mais streaming bidirecional, implantáveis em contêineres Linux na nuvem³.
• O MLX Swift traz a computação de arrays no estilo NumPy para o Swift, com execução automática na GPU e diferenciação automática via grad, compartilhando um único motor entre os front-ends Swift, Python, C++ e C⁴.

Ergonomia de linguagem: as irritações desaparecem

A sessão abre com mudanças que “você talvez mal perceba, exceto como pequenas irritações desaparecendo”¹. Vale nomeá-las porque removem o atrito que se acumulou ao longo de uma década da linguagem.

Becca e Evan, da equipe do Swift, percorrem o Swift 6.3 e o 6.4. A seção de linguagem começa por volta de 0:45.

Agora você pode escrever any P? sem envolvê-lo em parênteses. Você recebe um aviso quando uma tarefa do Swift Concurrency descarta silenciosamente um erro lançado, sugerindo que você o trate na tarefa ou salve a tarefa e verifique mais tarde. A antiga restrição de chamar funções async a partir de um bloco defer acabou, então a limpeza assíncrona é executada da mesma forma que a limpeza síncrona adiada sempre funcionou (SE-0493, Swift 6.4)⁷. Uma classe que só precisava de @unchecked Sendable por causa de uma propriedade weak var pode trocar essa propriedade por weak let e se qualificar para a verificação Sendable adequada. Um tipo que não deve ser Sendable pode declará-lo explicitamente com a nova sintaxe ~Sendable, que não impede que subclasses sejam Sendable¹.

Duas mudanças que você certamente vai notar. A primeira é a disponibilidade: a Apple alinhou os números de versão de seus sistemas operacionais no ano passado, e o Swift vai além ao permitir que você condense todos os nomes de plataforma em um só, anyAppleOS. Quando a disponibilidade se alinha entre as plataformas que importam para você, você as especifica todas de uma vez; quando há exceções, você define anyAppleOS como padrão e adiciona atributos específicos de plataforma para as exceções. O mesmo nome funciona em condições #if os(...)¹.

A segunda é o atributo @diagnose, que altera o comportamento de avisos específicos dentro de uma única declaração. Você pode dizer ao Swift para ignorar o grupo de avisos deprecated declaration em uma função enquanto migra para uma nova API, sem silenciá-lo em todo o projeto. Você também pode usá-lo na direção oposta: ativar a segurança de memória estrita dentro de uma função crítica para a segurança, ou promover um aviso de erro futuro a erro imediatamente¹. Holly Borla, gerente de engenharia da equipe do Swift, o apontou como seu destaque ao encerrar a WWDC26: “Um dos meus novos recursos favoritos é o atributo @Diagnose, que permite controlar o comportamento dos avisos no seu código; isso permite fazer coisas como suprimir descontinuações, mas também permite fazer coisas como optar pela segurança de memória estrita ou por diagnósticos de concorrência estrita de forma mais granular, o que ajuda, por exemplo, na migração para o modo de linguagem do Swift 6.”⁸ Ela enquadrou todo o lançamento da 6.4 da mesma maneira: as atualizações estão “removendo coisas que são pontos de atrito” para que os desenvolvedores possam se concentrar em expressar suas ideias em código claro e bonito⁸.

Depois há os seletores de módulo. Quando dois módulos importados declaram um tipo chamado View, a antiga solução era a sintaxe de ponto (Rocket.SaturnV), que falha quando um módulo chamado Rocket também contém um tipo chamado Rocket, porque o Swift prefere o tipo e então não encontra o membro. O Swift 6.3 introduz ::, em que o nome à esquerda é sempre o nome de um módulo, então Rocket::SaturnV vai direto para o módulo. O seletor também funciona em nomes de métodos e propriedades. A orientação da Apple é direta: use-o para conflitos entre módulos que você não controla, e defensivamente em código gerado por macros, mas não projete APIs que colidam intencionalmente para depois se apoiar em seletores para desambiguar¹.

Biblioteca padrão e Foundation

A biblioteca padrão recebeu acréscimos pontuais. Um escudo de cancelamento de tarefa (withTaskCancellationShield, SE-0504, Swift 6.4) executa uma pequena região em que as verificações de cancelamento sempre retornam false, de modo que a limpeza assíncrona, como finalizar uma escrita em disco, ainda seja executada depois que a tarefa ao redor foi cancelada⁷. O mapKeyedValues passa tanto a chave quanto o valor antigo para o closure de mapeamento, substituindo a reconstrução manual de dicionário que o mapValues forçava quando você precisava da chave. Um novo tipo de caminho de arquivo, baseado no do Swift System, lida com as diferenças de plataforma na representação de caminhos¹.

O Foundation continuou sua migração de vários anos do Objective-C para o Swift. A Apple modernizou mais partes de Data (acessos a spans, verificações de igualdade, iteração e mutação mais rápidos) e unificou NSURL e CFURL em uma única implementação Swift que é mais rápida e usa menos memória. O ProgressManager é um novo tipo de relato de progresso construído para async/await, e o pacote Subprocess chegou à versão 1.0 com um tipo de execução simplificado, saída transmitida como AsyncBufferSequence e um método strings() que lê a saída linha por linha respeitando os limites dos clusters de grafemas¹.

A propriedade alcança o código comum

A história de desempenho é a que merece leitura atenta, porque representa o momento em que um projeto de compilador de vários anos se torna algo que você pode usar em tipos do dia a dia. O problema central é a cópia: você tem dados em um lugar, precisa deles em outro, então o programa os copia. Quando o armazenamento permanece alocado e ambos os lados seguem as regras de exclusividade do Swift, a cópia é desnecessária. Um borrow concede acesso de leitura ao armazenamento existente sem copiá-lo; um mutate concede acesso de escrita exclusivo. O compilador verifica ambos em tempo de compilação, o que é o que torna a técnica segura onde o UnsafePointer cru não era¹.

A seção de propriedade e ajuste de desempenho começa por volta de 19:55, cobrindo o controle de inlining, a especialização e os novos acessadores.

Vários protocolos agora funcionam sem cópia. Equatable, Comparable e Hashable podem ser usados em tipos não copiáveis, e Equatable e Comparable se estendem a tipos não escapáveis. Os tipos associados agora podem ser não copiáveis ou não escapáveis, o que é o que torna possível o recurso de destaque: um novo protocolo Iterable que os laços for suportam diretamente¹.

O protocolo Sequence, que todos conhecem, copia os elementos para fora à medida que itera. O Iterable permite que o laço os pegue emprestados (borrow), o que significa que ele funciona com elementos não copiáveis e dispensa a contagem de referências em objetos e tipos copy-on-write. Ele pode lançar erros durante a iteração, da mesma forma que um AsyncSequence pode. Como o empréstimo proíbe a mutação, a verificação de exclusividade impede que você mute a coleção enquanto faz o laço sobre ela (uma armadilha de desempenho frequente com Sequence). Um laço for prefere Sequence quando disponível e recorre a Iterable, e o iterador de Iterable retorna os elementos em lotes de spans em vez de um de cada vez, o que torna o laço mensuravelmente mais eficiente para tipos que conseguem devolver tudo em um único span¹.

Os acessadores receberam o mesmo tratamento. O exemplo da Apple é um UniqueBox contendo um InlineArray de 256 Ints, uma struct de dois kilobytes em um dispositivo de 64 bits. Com get/set, alterar um elemento copia o array inteiro para fora e de volta. Trocar a propriedade computada por um acessador borrow (acesso somente leitura sem cópia) e um acessador mutate (modificação exclusiva no local) permite que o Swift altere um elemento no local e permite que o tipo guarde valores não copiáveis¹.

Vários novos tipos da biblioteca padrão trazem as substituições seguras para padrões que antes exigiam código inseguro:

• UniqueArray se comporta como Array, mas é não copiável, então armazena elementos não copiáveis e evita a sobrecarga de contagem de referências sem se comprometer com um tamanho fixo.
• UniqueBox é um tipo real da biblioteca padrão usando os novos acessadores.
• Continuation verifica em tempo de compilação que você a retoma exatamente uma vez, tornando-a mais segura que CheckedContinuation e tão eficiente quanto UnsafeContinuation.
• Ref e MutableRef agem como um Span para um único valor: um contêiner para um empréstimo ou uma mutação que você pode armazenar em uma variável, passar, retornar e usar em tipos genéricos. Você constrói um MutableRef a partir de um acesso de escrita com um prefixo &, e como as refs são não escapáveis, o Swift sabe que o acesso termina quando a variável sai de escopo¹.

O UniqueArray e o RigidArray de capacidade fixa vivem em um novo módulo Containers (SE-0527, aceito em princípio), e você pode usar ambos hoje por meio do swift-collections 1.3 antes de se acomodarem na biblioteca padrão⁷.

Para controle do otimizador, o Swift 6.4 adiciona @inline(always) para fazer par com o já antigo @inline(never) (combine-o com final em métodos de classe, já que um método sobrescrevível pode ainda assim não ser inlined), e o Swift 6.3 adiciona @specialized, em que uma cláusula where diz ao compilador para pré-gerar uma versão especializada de uma função genérica para os tipos concretos que você mais usa¹. Você raramente vai precisar deles. Quando precisar, como diz a sessão, “você vai ficar feliz de tê-los”¹.

Swift Testing: a migração agora é bidirecional

O Swift Testing foi lançado no Xcode 16 como a biblioteca de testes moderna, baseada em macros e paralela por padrão². A história de 2026 é a migração, e o acréscimo central é a interoperabilidade entre frameworks de teste: a capacidade de chamar a API de um framework dentro de um corpo de teste do outro, nas duas direções².

Jerry, da equipe do Swift Testing, demonstra como chamar auxiliares do XCTest a partir de testes do Swift Testing. O passo a passo de interoperabilidade começa por volta de 5:48.

A estratégia de migração que a Apple recomenda não mudou: deixe a maioria dos XCTests no lugar, escreva novos testes no Swift Testing e migre aqueles que você mais toca. Ambos os frameworks já coexistem em um único alvo. A novidade é que você pode reutilizar o código auxiliar que construiu sobre o XCTest. Quando um teste do Swift Testing chama um auxiliar assertUnique que envolve XCTFail, isso produz uma issue entre frameworks, e o Xcode agora a trata com quatro modos²:

• Limited: as issues entre frameworks vindas do XCTest são avisos. Planos de teste criados antes do Xcode 27 herdam esse modo, e pacotes Swift em swift-tools-version: 6.3 o usam por padrão.
• Complete: essas mesmas issues permanecem como erros. O Xcode 27 usa o modo complete para novos projetos; pacotes Swift optam por ele ao subir para swift-tools-version: 6.4 ou mais recente.
• Strict: as issues entre frameworks vindas do XCTest interrompem o teste com um erro fatal, apontando para cada ponto onde a API do XCTest deve ser substituída.
• None: desativa por completo (use apenas temporariamente, já que essas issues podem sinalizar bugs reais).

As issues entre frameworks vindas do Swift Testing permanecem como erros em todos os modos, então você pode chamar #expect e #require com segurança de dentro de um XCTestCase. Você sobrescreve o padrão em um pacote com a variável de ambiente SWIFT_TESTING_XCTEST_INTEROP_MODE (nome do modo em minúsculas)². A sessão 262 do XCTest confirma o lado correspondente da biblioteca padrão: as falhas de asserção do XCTest agora aparecem como issues de teste quando chamadas a partir do Swift Testing, então você migra sem perder cobertura silenciosamente¹.

O livro de receitas da migração cobre os padrões comuns. XCTSkip se torna Test.cancel (ou, melhor, uma trait .enabled/.disabled que move a lógica de habilitação para fora do corpo do teste). continueAfterFailure = false se torna #require, que lança em caso de falha e interrompe o teste, deixando você escolher por expectativa quais falhas param a execução². A interoperabilidade suporta um conjunto de API limitado, mas prático: todas as asserções do XCTest, ambos os macros de expectativa (#expect e #require), a API de issue conhecida para marcar falhas do XCTest como conhecidas, e Test.cancel para pular casos do XCTest².

Para a superfície da API em si (os macros, o vocabulário de traits, o que permanece no XCTest), o post complementar sobre Swift Testing vs. XCTest cobre o modelo mental. Dois pontos seguem dali: a automação de UI e os testes de desempenho permanecem exclusivos do XCTest, e o código que lança exceções do Objective-C deve permanecer em XCTests escritos em Objective-C, porque o código Swift não consegue tratar essas exceções com segurança². Uma vez migrado, você obtém testes parametrizados (cada argumento um caso separado, todos rodando em paralelo) e exit tests que executam código que se espera que trave em um processo filho para verificar o encerramento, disponíveis no macOS, Linux, FreeBSD e Windows².

gRPC Swift: serviços tipados em tempo real

A história do servidor é a demonstração mais clara de que o Swift agora abrange cliente e backend com uma única linguagem. A sessão de gRPC constrói um app iOS conversando com um servidor Swift, gerado inteiramente a partir de uma especificação .proto³.

George, da equipe do Swift Server, explica os quatro tipos de RPC. A seção de streaming, incluindo o streaming bidirecional, começa por volta de 11:06.

O gRPC é um projeto da Cloud Native Computing Foundation em que você define APIs como funções com entradas e saídas tipadas, em vez de endpoints HTTP, e gera o código do cliente a partir da especificação³. O fluxo de trabalho: defina o serviço em um arquivo .proto, adicione grpc-swift-nio-transport (rede sobre o SwiftNIO) e grpc-swift-protobuf (o plugin de build) como dependências do pacote, anexe o plugin run-build-tool GRPCProtobufGenerator e recompile para gerar o cliente tipado.

Um RPC unário como ListRaces envia uma requisição e recebe uma resposta. A demo de kart da sessão o conecta a uma view SwiftUI com withGRPCClient, depois é refatorada para compartilhar um único cliente por meio do environment do SwiftUI, de modo que as views reutilizem conexões, e desconecta quando a cena entra em segundo plano³. O Protobuf serializa as mensagens em binário, indexadas pelo número do campo em vez do nome do campo, o que torna uma mensagem “aproximadamente metade do tamanho da mensagem JSON equivalente”³, uma vitória real em redes móveis ruins. A Apple observa que a mesma eficiência impulsiona sua própria infraestrutura: o gRPC Swift alimenta a comunicação entre processos no framework de código aberto Containerization e sustenta o Private Cloud Compute, o iCloud Keychain e o Fotos, e o compartilhamento de arquivos do SharePlay³.

O suporte a streaming é o que viabiliza o tempo real. Além dos RPCs unários, há o client-streaming (muitas requisições, uma resposta), o server-streaming (uma requisição, muitas respostas, como um feed de comentários ao vivo) e o streaming bidirecional. A demo usa streaming bidirecional para atualizações de corrida ao vivo: o cliente transmite quais tipos de evento ele quer enquanto o servidor transmite os eventos correspondentes. No lado do servidor, isso vira uma função async cujo parâmetro de requisição é um AsyncSequence de mensagens e cujo parâmetro de resposta é um writer, tratado com um task group e um conjunto, protegido por mutex, de tipos de evento assinados³. A implantação é um Containerfile de múltiplos estágios (build com swift:latest, copia o binário de release para swift:slim), executado no Google Cloud Run com HTTP/2, e então o cliente troca a segurança de seu transporte de texto puro para TLS³.

MLX Swift: computação numérica que se lê como matemática

A sessão de MLX visa um desenvolvedor inteiramente diferente: qualquer pessoa que escreva simulações, processamento de sinais, renderização ou treinamento de modelos. O MLX Swift usa arrays n-dimensionais como sua abstração central, do jeito que o NumPy faz, então “a maior parte do código NumPy pode ser traduzida para MLX Swift com alterações mínimas”⁴.

David Koski percorre o exemplo de Mandelbrot. A comparação de computação de arrays contra o Swift puro começa por volta de 4:28.

O MLX fica ao lado da pilha numérica existente da Apple, em vez de substituí-la: o Accelerate para primitivas vetoriais de CPU ajustadas à mão, o BNNS para blocos de construção de redes neurais, o Metal Performance Shaders para kernels de GPU diretos e o Swift Numerics para o tipo Complex. Você recorre ao MLX Swift quando o objetivo é “escrever código matemático com um olho no desempenho” e você quer que o código se pareça com a matemática⁴.

Dois recursos tornam isso possível. A avaliação preguiçosa (lazy evaluation) constrói um grafo de computação à medida que você escreve operações de array e não executa nada até que você chame eval ou leia um valor, e é por isso que um laço chama eval a cada passo para manter o grafo pequeno. A avaliação preguiçosa também impulsiona a execução automática na GPU e a diferenciação automática por meio da transformação de função grad⁴. O exemplo de Mandelbrot colapsa um laço escalar por pixel em duas linhas (z = z * z + c aplicado à grade inteira, depois uma contagem das iterações limitadas), roda na GPU por padrão, e a sessão observa que “10x mais rápido é certamente possível”⁴. Um resolvedor de distribuição de calor expressa a iteração de Jacobi como uma única chamada conv2d. O exemplo de ajuste de curva usa grad para calcular gradientes exatos sem derivadas escritas à mão, a mesma ideia por trás do treinamento de todo modelo de ML⁴.

O MLX Swift é de código aberto sob licença MIT, instalável por meio do Swift Package Manager, e é um front-end entre quatro (Swift, Python, C++ e C) que compartilham as mesmas operações e o mesmo modelo de avaliação preguiçosa, então você pode “prototipar em Python e entregar em Swift”⁴. O ecossistema inclui mlx-swift (o framework central), mlx-swift-lm (implementações de modelos de linguagem) e mlx-swift-examples (exemplos executáveis de LLM, difusão e treinamento)⁴. Para o contexto de ML no dispositivo ao redor disso, veja MLX on-device ML on Apple Silicon.

O que adotar primeiro

Ordene o trabalho conforme quem você é.

Se você publica apps e raramente mexe nos botões de desempenho do compilador, adote as ergonomias agora e ignore o sistema de propriedade. Substitua linhas @available empilhadas por anyAppleOS onde suas plataformas se alinham, use @diagnose para silenciar avisos de descontinuação exatamente onde você está no meio de uma migração, e recorra aos seletores de módulo (::) na próxima vez que uma dependência colidir com o SwiftUI em um nome como View¹.

Se você mantém uma grande suíte de XCTest, ative a interoperabilidade e comece a escrever novos testes no Swift Testing hoje. Mova os planos de teste existentes para o modo complete para que as issues entre frameworks sejam erros que você não pode deixar passar, reutilize seus auxiliares do XCTest por meio da interoperabilidade em vez de reescrevê-los de antemão, e migre os arquivos que você mais toca. Mantenha a automação de UI, os testes de desempenho e os testes de exceções do Objective-C no XCTest¹².

Se você escreve código sensível ao desempenho, os acréscimos de propriedade são o destaque. Audite as propriedades computadas quentes que guardam valores grandes e troque-as de get/set para borrow/mutate. Onde antes você descia para UnsafePointer, olhe para Ref/MutableRef, UniqueArray e a Continuation de retomada única. Meça antes de recorrer a @inline(always) ou @specialized, porque o otimizador geralmente está certo e forçá-lo pode tornar o binário maior e mais lento¹.

Se o seu trabalho é do lado do servidor ou numérico, os novos pacotes são pontos de entrada prontos para produção: o gRPC Swift lhe dá um cliente tipado e streaming bidirecional a partir de um arquivo .proto, e o MLX Swift lhe dá computação de arrays acelerada por GPU e diferenciação automática que se lê como a matemática³⁴.

FAQ

Qual é a diferença entre o Swift 6.3 e o Swift 6.4?

A Apple desenvolveu e lançou ambos no mesmo ciclo da WWDC26 e os apresentou juntos. Em linhas gerais, o Swift 6.3 introduziu os seletores de módulo (::) e o atributo @specialized, e entregou o primeiro SDK oficial do Swift para Android. O Swift 6.4 adicionou a disponibilidade anyAppleOS, any/some opcional sem parênteses, o protocolo Iterable para laços for, os acessadores borrow/mutate, @inline(always), o atributo @C para exportar funções Swift para C, e as melhorias de depuração do embedded Swift. A sessão cobre os dois como um único corpo contínuo de trabalho¹.

Eu preciso migrar do XCTest para o Swift Testing?

Não. O XCTest continua disponível e continua funcionando, e a recomendação da Apple é incremental: escreva novos testes no Swift Testing e migre os antigos à medida que os toca. A interoperabilidade entre frameworks de teste permite que os dois coexistam em um único alvo e chamem a API um do outro, então você pode reutilizar auxiliares do XCTest a partir de testes do Swift Testing. A automação de UI, os testes de desempenho e o código que lança exceções do Objective-C permanecem no XCTest¹².

O que o novo protocolo Iterable faz que o Sequence não faz?

O Sequence copia os elementos para fora à medida que itera. O Iterable permite que o laço for pegue emprestados (borrow) os elementos, então ele funciona com elementos não copiáveis e dispensa a contagem de referências em objetos e tipos copy-on-write. Ele retorna os elementos em lotes de spans em vez de um de cada vez, o que é mais eficiente, e pode lançar erros durante a iteração. Como o empréstimo proíbe a mutação, você não pode mutar a coleção enquanto faz o laço sobre ela. Um laço for prefere Sequence quando disponível e recorre a Iterable¹.

Quando devo usar o MLX Swift em vez do Accelerate ou do Metal Performance Shaders?

Use o MLX Swift quando seu objetivo principal for escrever código matemático com um olho no desempenho e você quiser que o código se leia como a matemática, com execução automática na GPU e diferenciação automática por meio do grad. O Accelerate continua sendo a escolha para primitivas vetoriais de CPU ajustadas à mão, o BNNS para blocos de construção de redes neurais, e o Metal Performance Shaders para acesso direto a kernels de GPU. O MLX fica ao lado deles, em vez de substituí-los⁴.

O gRPC Swift é só para serviços de backend?

Não. A sessão da WWDC constrói um app iOS como cliente gRPC, gerando um cliente tipado a partir de um arquivo .proto, e mostra RPCs unários mais streaming bidirecional dirigindo atualizações de UI ao vivo. A codificação binária do Protobuf produz mensagens aproximadamente metade do tamanho do JSON equivalente, o que ajuda em redes móveis ruins. A Apple também usa o gRPC Swift para comunicação entre processos e em serviços incluindo o Private Cloud Compute, o iCloud Keychain e o Fotos, e o compartilhamento de arquivos do SharePlay³.

O cluster do Apple Ecosystem

A atualização de 2026 do Swift atravessa o restante da série Apple Ecosystem: o detalhamento de Swift Testing vs. XCTest sobre o modelo de testes, os internals do Observable no SwiftUI que as mudanças de concorrência tocam, do que o SwiftUI é feito no nível do framework, e MLX on-device ML on Apple Silicon para o contexto de computação numérica. O hub para tudo isso é a Série Apple Ecosystem. Para construir apps iOS com agentes de IA no laço, veja o guia de Desenvolvimento de Agentes iOS.

Referências