Ao longo do último ano, o Swift no Windows provou sua eficácia em produção. Equipes estavam lançando aplicações para AMD64 e ARM64 — desde clientes com interface gráfica intensa até aplicativos de linha de comando que exercitavam grandes partes da pilha. Algumas implantações usaram C++ para rede, enquanto outras confiaram diretamente na Foundation’s URLSession. Essas cargas de trabalho do mundo real expuseram problemas sutis que ajudaram a impulsionar melhorias de estabilidade, embora ainda restassem alguns detalhes ásperos.
No entanto, ‘funcionar’ não é o mesmo que ser previsível — e a previsibilidade é o que torna um sistema viável em escala. Os últimos doze meses não foram sobre adicionar novos recursos chamativos, mas sim sobre refinamento: reduzir a fragilidade, melhorar a experiência de desenvolvimento e diminuir o custo da adoção.
Este post percorre as principais melhorias do ano: reconstruindo o sistema de construção do runtime para estabelecer uma base confiável, criando o Experimental Swift SDK com vários modelos de distribuição, implementando vinculação estática para implantações autônomas e validando a abordagem com ferramentas em produção.
O trabalho deste ano abordou três problemas interconectados: surpresas na seleção do runtime, configurações de construção frágeis e desacordos no vinculamento. Esses tiveram que ser resolvidos em ordem de dependência, tornando as suposições de construção, embalagem e vinculação explícitas em cada etapa.
Inicialmente, reconstruímos o sistema de construção do runtime ao redor do moderno CMake, porque os aprimoramentos na embalagem e no vinculamento da SDK só fazem sentido se a construção do runtime for reprodutível entre variantes.
Sobre essa base, definimos o Experimental Swift SDK como um único entregável bem especificado para que os modelos de distribuição e vinculação fossem codificados, não dependendo do ambiente. Com a disposição da SDK em lugar, corrigimos a semântica de entrada e importação/exportação dos DLLs Windows. Uma configuração dinâmica apenas poderia funcionar apesar das desacordos, mas pagava por essa conveniência com extra thunks e saída do vinculador barulhenta. O vinculo estático força a cadeia de ferramentas a modelar essas decisões explicitamente.
Finalmente, validamos essa abordagem ao lançar e executar ferramentas reais em ambientes multi-cadeias de ferramentas, onde confusões no runtime acontecem sob configurações normais do desenvolvedor/CI.
Antes desse trabalho, o Swift no Windows estava pronto para produção mas era caro. As lacunas estavam na ergonomia e nas surpresas específicas da plataforma que elevaram o custo de adoção. Um exemplo concreto: ferramentas construídas com a cadeia de ferramentas X se vinculariam ao runtime Y no tempo de execução porque a descoberta de DLLs dependia do Path. Aqui, “runtime” inclui a biblioteca padrão, os DLLs do núcleo do runtime e corelibs (Foundation, Dispatch). Em ambientes multi-cadeias de ferramentas, isso não era hipotético — era rotineiro.
O runtime e o compilador estão profundamente entrelaçados, construídos usando um sistema personalizado que acumulou lógica específica da plataforma ao longo de uma década. Funcionava, mas não expressava claramente como o runtime deveria ser construído.
No início do último outono, engenheiros da The Browser Company começaram a colaborar com a Apple e a comunidade mais ampla para reescrever o sistema de construção usando CMake moderno. Com suporte adequado ao idioma Swift agora disponível no CMake, poderíamos construir o runtime de maneira autônoma usando o modelo baseado em alvo do CMake moderno.
A configuração da construção importa aqui: remover uma bandeira do vinculador ou compilador pode alterar o comportamento da otimização (incluindo LTO) de formas que só aparecem em algumas configurações. Porque a migração ainda está em andamento em várias plataformas, mantemos a legado e construção CMake semanticamente alinhadas conforme as mudanças no runtime são implementadas.
Nós atingimos isso diretamente durante a transição: uma configuração acidentalmente deixou uma opção de depuração que destrói memória habilitada, e os runtimes imediatamente ficaram mais lentos — tão lento que não precisamos de benchmarks para saber que algo estava errado. Essa experiência reforçou por que a reescrita do sistema de construção importava: não é apenas sobre “podemos construir isso”, é sobre tornar a configuração do runtime inspecionável para que mudanças sutis não sejam enviadas silenciosamente.
A reescrita também tornou configurações anteriormente desconfortáveis práticas, incluindo compilação cruzada. A construção CMake agora suporta hosts Darwin e Windows, e usamos isso para construir o runtime Android no Windows. O resultado é uma construção mais fácil de auditar e menos propensa a esconder deslizamentos na configuração.
Sob essa base, criamos o Experimental Swift SDK para Windows — uma nova versão do Windows Swift SDK que embala o runtime, bibliotecas básicas e metadados de integração como um único artefato suportando vários modelos de distribuição: distribuição estática, instalação ao lado a lado ou empacotamento de uma cópia privada do runtime compartilhado.
O SDK é a camada Swift que complementa o Windows SDK com tudo necessário para construir e executar código Swift:
Bibliotecas básicas da linguagem:
Swift,_Concurrencye_StringProcessingServiços de nível superior: as implementações corelibs de Foundation e Dispatch
Bibliotecas de teste: XCTest e Swift Testing
Glue de integração: APINotes, módulo maps e outros metadados
O Swift SDK é o runtime e seu ecossistema imediato, mais a estrutura conectiva necessária para se posicionar naturalmente acima do sistema SDK.
Uma mudança significativa no Experimental Swift SDK é que não construímos mais o runtime com o modo de evolução da biblioteca habilitado. O sistema anterior ativava a evolução da biblioteca incondicionalmente, mesmo sem estabilidade ABI; na plataforma Windows isso nos trouxe principalmente indireção ao restringir o código gerado a um modelo de compatibilidade que não correspondia à plataforma, enquanto ainda não fornecia um contrato de superfície ABI estável. Desabilitá-lo vincula o código mais firmemente à versão do runtime com a qual foi construído, remove alguma indireção relacionada ao ABI (com pequenas vantagens de desempenho) e reflete o status atual da plataforma: Windows não oferece estabilidade ABI para Swift no momento.
Na prática, isso muda a história de compatibilidade de “preservar uma superfície ABI estável” para “vincular a uma versão do runtime explícita”, o que se alinha naturalmente com a instalação ao lado a lado e evita limitar prematuramente o runtime a uma superfície ABI congelada.
A etiqueta “experimental” reflete a expectativa de iteração. Este SDK é destinado para uso real, mas sua estrutura e conteúdo podem evoluir à medida que adquirimos experiência e conforme a plataforma circundante muda.
Com as builds do runtime e o embalamento do SDK em vigor, pudemos abordar o link estático do Swift runtime no Windows. O modelo anterior supunha que tudo se ligava dinamicamente ao runtime. Essa suposição estava incorporada na geração de IR e metadados de módulo, e se propagou através da mecânica de ligação e auto-ligação da ferramenta. Suportar o link estático significou tornar essas suposições explícitas e configuráveis.
O link estático cria um binário autossuficiente com um conjunto conhecido de código, tornando a distribuição mais confiável porque a versão do runtime é fixada no momento da build.
Além dos benefícios de distribuição, o link estático também habilita uma otimização de programa completo mais ampla: otimização em tempo de ligação, remoção de código morto e inlining transversal às fronteiras das bibliotecas. A sobrecarga de relocação e lookup de símbolos ao iniciar pode ser reduzida à medida que o código é internalizado no módulo.
Esses benefícios vêm com trade-offs: os binários são maiores; o uso de memória em muitos processos pode ser maior porque as bibliotecas ligadas dinamicamente podem compartilhar páginas; rebuilds são mais lentos; e a distribuição de patches de segurança requer rebuilds e redistribuições para cada consumidor, ao invés de atualizar uma única biblioteca compartilhada.
Por esses motivos, o link estático funciona bem para ferramentas independentes e distribuições unibinárias. O link dinâmico geralmente funciona melhor para grandes bibliotecas do sistema, ecossistemas de plugins e ambientes que se beneficiam da patchagem centralizada. A chave é ter ambas as opções disponíveis para que os desenvolvedores possam fazer a escolha adequada ao contexto de distribuição.
Implementar isso corretamente no Windows exigiu mudanças em várias camadas.
O Windows faz a separação entre interface e implementação explícita, e o SDK precisa embarcar artefatos que refletem essa divisão limpa. Uma biblioteca ligada dinamicamente é conceitualmente dividida em duas partes:
A parte do runtime: A DLL contendo a implementação real, carregada no momento da execução
A parte do linker: A biblioteca de importação, que descreve os símbolos disponíveis na DLL mas não contém nenhuma implementação
- Bibliotecas estáticas usam um prefixo
libcom o sufixo.lib(por exemplo,libswiftCore.lib) - Import libraries usam apenas o sufixo
.libsem o prefixo (por exemplo,swiftCore.lib) Várias versões do tempo de execução podem coexistir em uma única máquina sem forçar todas as ferramentas e aplicativos a compartilhar exatamente uma versão.
Os tempos de execução podem ser instalados globalmente e compartilhados entre usuários, enquanto ainda permite que ferramentas específicas se vinculem a versões específicas.
As atualizações podem ser incrementais. Ferramentas podem adotar novos tempos de execução sem uma migração global imediata.
Constrói contra o SDK do Windows e o Experimental Swift SDK
Passa pelo conjunto de testes no Windows, estabelecendo um nível básico de confiança
A diagnóstica e a relatoria são idênticas entre macOS e Windows para entradas idênticas
Depuração: Fazendo a depuração do Swift no Windows se sentir natural e totalmente capaz
Servidor de símbolos público: Fornece símbolos para habilitar rastreamentos de pilha de alta qualidade e diagnósticos sem gerenciamento manual de símbolos
Desempenho: Endereçando preocupações específicas do Windows em termos de desempenho, abrangendo compilador, runtime e interações da plataforma
Cada um desses aspectos é substancial e será discutido separadamente, construindo sobre a base descrita aqui.
Em um ano, o Swift no Windows evoluiu de comportamentos implícitos para modelos de construção e implantação especificados. Na prática, isso reduz falhas dependentes do ambiente em máquinas de desenvolvedores e CI. Em ambientes com várias ferramentas instaladas, as ferramentas não precisam mais “ter sorte” com a ordem da Path
para executar contra o runtime com o qual foram construídas. E quando você deseja uma ferramenta de único binário que carrega seu próprio runtime — formatters, linters, utilitários do desenvolvedor — o link estático é agora uma configuração suportada nos casos em que a distribuição de um único binário é a troca correta.Essas mudanças já estão sendo exercidas por software real e uso contínuo em ferramentas reais continua a expor e impulsionar correções para as lacunas restantes, particularmente em torno da depuração e do desempenho específico do Windows. O trabalho do ano ajuda a estabelecer o Swift como uma linguagem e ecossistema estáveis, confiáveis e prontos para produção no Windows.
–
Saleem Abdulrasool é membro da equipe Swift Core e a força motriz por trás do Swift cross-platform. Ele tem trabalhado há anos para tornar o Swift pronto para produção fora do ecossistema Apple.
Esta divisão não é um truque do Windows; é a mesma separação entre interface e implementação que outras plataformas expressam de formas diferentes. As plataformas da Apple distribuem stubs para o linker (arquivos TBD) separadamente das implementações em tempo de execução.
Plataformas baseadas em ELF tradicionalmente não exibem essa dicotomia, mas o LLVM já possui a infraestrutura (IFS) para representar a mesma separação em ELF. Isso oferece um caminho para SDKs que carregam definições de ABI independentemente das implementações em tempo de execução que as satisfazem.
No Windows, tanto as bibliotecas estáticas quanto as import libraries usam a extensão de arquivo
.lib. Para evitar colisões, adotamos uma convenção de nomenclatura da Microsoft:Isto torna a distinção óbvia ao inspecionar a SDK e permite que ambas as formas coexistam no mesmo diretório. Essa divisão entre implementação e interface é o motivo pelo qual a SDK precisa fornecer um conjunto claro, sem colisões de importações e bibliotecas estáticas: o linker deve ser capaz de selecionar o modelo correto deterministicamente.
A vinculação estática nos forçou a tornar a origem das importações/exportações explícita na geração do IR. Agora marcamos os pontos de entrada do tempo de execução como importados ou exportados com base no contexto, então o compilador emite chamadas que correspondem aos semânticos dos DLLs Windows, reduzindo ruído durante a vinculação e evitando thunk desnecessários.
No Windows, essa origem é expressa através de anotações de armazenamento de DLL nos símbolos: uma função está definida no módulo atual ou importada de outro módulo? Quando o compilador sabe que um símbolo foi importado, ele pode emitir a chamada indireta correta diretamente.
Anteriormente, efetivamente assumimos que o tempo de execução Swift sempre seria vinculado dinamicamente. Essa suposição estava codificada na geração do IR, o que significava que as chamadas emitidas e o modelo de vinculação esperado poderiam divergir. Em uma configuração apenas dinâmica, o linker frequentemente podia cobrir desalinhamentos, mas o resultado era implícito e frágil - especialmente quando a vinculação estática entrou em cena.
A implementação da vinculação estática exigiu alterações coordenadas em vários componentes.
A restrição-chave é a consistência: o modelo de vinculação do compilador, os metadados swiftmodule, as diretivas de auto-vinculação e o linker devem todos concordar sobre estático versus dinâmico, ou os modos de falha se tornam sutis e difíceis de diagnosticar.
O compilador e o tempo de execução precisavam de um modelo explícito para um tempo de execução Swift vinculado estáticamente no Windows, e esse modelo tinha que ser serializado nos swiftmodules para que a geração do IR, carregamento de módulos e o linker façam as mesmas decisões sobre estático versus dinâmico.
A geração do IR precisava entender onde as funções do tempo de execução estão “homed” - qual módulo fornece a definição - para atribuir corretamente o armazenamento de DLL às chamadas intermódulares sob ambos os modos de vinculação.
A auto-vinculação precisou ser atualizada para refletir o novo esquema de nomenclatura e modelo de vinculação. A funcionalidade de auto-vinculação do Swift incorpora dependências de bibliotecas diretamente nos swiftmodules, permitindo que o compilador emita diretrizes corretas do linker automaticamente com base nas declarações import. A auto-vinculação evita linhas de vinculação manuais e propensas a erros, mas requer um modelo preciso da nomenclatura das bibliotecas e do tipo de vinculação.
Para suportar coexistência estática e dinâmica, estendemos tanto a auto-vinculação quanto os metadados swiftmodule para refletir o esquema de nomenclatura e o tipo de vinculação necessário.
Com essas peças em lugar, o Experimental Swift SDK pode agora distribuir uma versão estática do tempo de execução. Desenvolvedores que desejam explorar essa rota podem especificar -static-stdlib para construir contra a biblioteca padrão e as bibliotecas principais estáticas.
Nas plataformas não Darwin, o Swift depende de um registrador para tornar os metadados visíveis ao tempo de execução. Se o registrador estiver errado ou ausente, conformidade e descoberta de tipo podem falhar em tempo de execução - manifestando-se como falhas na pesquisa de conformidade, anomalias de casting ou reflexão que são difíceis de diagnosticar.
O registrador é um pequeno trecho de código injetado em todos os códigos Swift; ele registra cada módulo (seja uma execução ou uma biblioteca dinâmica) para que tipos, protocolos e conformidades a protocolos possam ser enumerados. Este código roda extremamente cedo na inicialização do programa, antes de qualquer runtime da linguagem estar totalmente configurado, então deve ser implementado com cuidado para evitar depender de suporte à linguagem ou até mesmo chamadas ao sistema.
Este tipo de mecanismo de inicialização precoce não é exclusivo do Swift. C e C++ têm padrões semelhantes. No entanto, o registrador do Swift é necessário apenas em plataformas não-Darwin. Em Darwin, o carregador dinâmico fornece um gatilho que notifica o runtime conforme os módulos são carregados, permitindo ao runtime escanear por metadados em vez de exigir que cada módulo se registre.
A nova configuração de vinculação estática não mudou a finalidade do registrador, mas adicionou um novo modo de vinculação que o registrador precisava suportar. Como o registrador é vinculado em todos os módulos, ele deve ser construído adequadamente para o tipo de saída sendo produzida—biblioteca dinâmica, execução dinâmica ou executável estático—e para como o runtime próprio é vinculado.
Para suportar isso, adicionamos um novo build do registrador ao SDK e atualizamos a ferramenta de cadeia para aplicar consistentemente o esquema de nomenclatura e selecionar a variante adequada do registrador para vinculação estática versus dinâmica. Isso garante que a registro de metadados permaneça correto independentemente de como o runtime é vinculado.
No Windows, as ferramentas Swift dependem do runtime Swift. A descoberta de DLLs de runtime depende da variável de ambiente Path. Quando várias cadeias de ferramentas estão instaladas, é fácil para uma ferramenta construída contra um runtime acidentalmente pegar outro em tempo de execução, o que é especialmente problemático nos ambientes de teste e bootstrap.
A autocomposição—construir a cadeia de ferramentas Swift usando Swift mesmo—impõe maturidade porque testa caminhos reais de distribuição e descoberta de runtime sob otimizações Release. A autocomposição também reduz a dependência em ambientes bootstrap de casos especiais. Se a plataforma não pode construir e executar suas próprias ferramentas confiavelmente, os casos de borda tendem a aparecer mais tarde—e em formas menos diagnósticas.
Alçando o baseline do bootstrap para uma cadeia de ferramentas que entende vinculação estática, poderíamos construir o swift-driver para Windows como um binário estáticamente vinculado usando os mesmos mecanismos expostos no Experimental Swift SDK. Isso torna a dependência do runtime explícita e estável do driver e previne “qualquer runtime que venha primeiro em Path” de se tornar uma variável oculta na construção.
O trabalho fundamental acima—sistema de build, SDK, vinculação estática—tratou da correção dos semânticos de vinculação e desbloqueou novos trabalhos de embalagem e distribuição. Em seguida, focamos em tornar a cadeia de ferramentas mais conveniente para uso diário e habilitando desenvolvedores a fazer trade-offs.
O instalador que construímos para os desenvolvedores na The Browser Company agora fornece uma variante Asserts (com asserções do compilador ativadas) e uma variante NoAsserts (aproximadamente 20% mais rápida em alguns testes, mas com menor capacidade de capturar malcompilações precocemente).
Empacotar ambos permite que a troca entre desempenho versus asserções seja feita no ponto de uso. Um desenvolvedor iterando rapidamente pode usar NoAsserts para compilações mais rápidas; CI pode usar Asserts para capturar malcompilações. Hoje, este instalador dual-mode está disponível através dos builds da cadeia de ferramentas da The Browser Company, com builds semelhantes esperados em futuras distribuições do swift.org.
Também reconstruímos a cadeia de ferramentas contra o mimalloc, resultando em uma melhoria aproximada de 4% no desempenho para cargas de trabalho de compilação. Embora 4% pareça modesto, ele se acumula em cada build incremental ao longo do dia de um desenvolvedor.
Com o Windows carecendo da estabilidade Swift ABI atualmente, a instalação lado-a-lado é o mecanismo de compatibilidade prática: versão explicitamente o runtime em vez de limitar a implementação a uma superfície de ABI congelada prematuramente.
Outro aspecto do trabalho envolveu o suporte à instalação lado a lado (SxS) da pilha de tempo de execução Swift. O Windows permite a instalação de várias versões do mesmo DLL e a seleção da versão correta no momento da carga. Integrar o Swift neste modelo oferece três vantagens:
O suporte ao SxS requer o embedding de metadados adicionais nos DLLs do tempo de execução durante a construção. Embora isso exija intervenção do desenvolvedor para fornecer os dados, o linker pode inseri-los automaticamente quando estiver construindo a biblioteca.
No entanto, injetar esse metadado requer que o sistema de build acomode bandeiras adicionais e manipulação de metadados. A construção legada tornou isso inviável. A construção baseada em CMake abriu a possibilidade de gerar e inserir manifestos SxS nos tempos de execução.
A construção compartilhada do tempo de execução no Experimental Swift SDK agora possui o manifesto SxS necessário embutido durante a construção, permitindo que os autores de pacotes vinculem à versão específica da construção necessária.
Combinado com a desativação do modo de evolução de bibliotecas em Windows, o SxS fornece vinculação versionada por design. Aplicativos se vinculam a um tempo de execução específico, múltiplas versões podem coexistir e as atualizações tornam-se uma distribuição controlada.
Essas mudanças arquiteturais são exercidas por software real. Várias ferramentas - incluindo as seguintes - serviram como adotantes iniciais e testes de estresse para o modelo de vinculação e distribuição.
nv é um visualizador Ninja que transforma logs de construção em uma imagem mais clara da programação e onde o tempo é gasto. vigil é uma ferramenta para usuários avançados inspirada por caffeinate, projetada para manter um computador Windows acordado durante tarefas longas.
Essas ferramentas frequentemente executam em máquinas com várias cadeias de ferramentas Swift instaladas. Em ambientes multi-ferramenta ou multi-tempo-de-execução, o modelo padrão de vinculação dinâmica cria um problema recorrente. DLLs são descobertas via a variável de ambiente Path, então uma ferramenta construída contra um tempo de execução Swift pode se vincular ao tempo de execução presente no sistema durante a execução.
A exigência para essas ferramentas é simples: elas devem funcionar exatamente com a versão Swift que foram construídas. A recompilação de nv e vigil usando vinculação estática atinge isso. As ferramentas carregam seu tempo de execução esperado, e o comportamento é determinado pela configuração da construção. O caminho de vinculação estática é exercitado sob condições realistas multi-ferramenta.
Muitos projetos confiam em SwiftFormat para manter o estilo de código ao longo do repositório com suas extensas regras de formatação. Como outras ferramentas na comunidade Swift, ela é escrita em Swift e depende do tempo de execução Swift. Em Windows, múltiplas cadeias de ferramentas mais um Path compartilhado tornaram fácil para um formatador construído com uma cadeia de ferramentas rodar contra o tempo de execução de outra cadeia.
A migração do SwiftFormat para vinculação estática via Experimental Swift SDK resolve o problema da incompatibilidade de versão. A versão do tempo de execução torna-se parte do binário. A ferramenta pode ser atualizada ou revertida independentemente das cadeias de ferramentas instaladas. Máquinas CI e desenvolvedores comportam-se consistentemente com a mesma construção do formatador.
Embora tenhamos distribuído anteriormente um Microsoft Merge Module no instalador que poderia embalar o tempo de execução em distribuições de ferramentas, isso não era sempre ideal. Se a ferramenta foi adicionada ao caminho e construída contra uma diferente cadeia de ferramentas, a consulta baseada no Path poderia potencialmente carregar o tempo de execução errado para a ferramenta ou outro aplicativo, incluindo componentes da própria cadeia. Com vinculação estática, podemos agora construir e distribuir a ferramenta sem essas preocupações. Hoje, você pode simplesmente baixar e executar a ferramenta das últimas versões.
SwiftLint é agora uma ferramenta de primeira classe em Windows.
Essa consistência é importante para fluxos de trabalho modernos. A CI não deve depender do sistema operacional de construção, equipes devem impor as mesmas regras em todos os ambientes e o suporte ao Windows não deve exigir ramificações ou comportamentos divergentes. O SwiftLint no Windows tanto se beneficia quanto ajuda a validar as decisões sobre runtime, SDK e ferramentas descritas acima.
A melhoria da experiência do desenvolvedor também significou abordar como o Swift importa APIs do Windows. O uso de UNICODE no Windows impulsionou uma grande melhoria no Clang Importer.
Muitas APIs Win32 são expostas como variantes A e W para versões ANSI e wide-character, respectivamente. O UNICODE macro seleciona qual forma é visível sob o nome não sufixado. Em C, chamando CreateFile mapeia transparentemente para CreateFileA ou CreateFileW com base na configuração da macro.
Historicamente, o Swift não refletiu essa conduta. O código tinha que chamar a variante explicitamente sufixada como CreateFileW, pois o importador não replicava aliasing controlado por macros.
Uma nova funcionalidade experimental do importador resolve isso. Com -enable-experimental-feature ImportMacroAliases, o Swift pode importar esses aliases controlados por macro, tornando o nome não sufixado como CreateFile disponível e resolvendo para a variante subjacente correta, correspondendo ao modelo do C.
Isso melhora a fidelidade da API e reduz a gestão de sufixos no Swift. Também facilita a portagem de exemplos e documentação existentes em C. A funcionalidade é experimental e opcional para que os desenvolvedores possam avaliá-la e relatar casos de borda.
O processo de construção da ferramenta agora produz um software bill of materials descrevendo os componentes que compõem a ferramenta. Isso melhora a segurança da cadeia de fornecimento e torna mais fácil verificar a origem. Também fornece informações claras para organizações avaliando a confiabilidade da ferramenta e pode facilitar a adoção em ambientes orientados à conformidade.
Embora grande parte do trabalho descrito acima tenha começado na The Browser Company, o Swift no Windows está se tornando cada vez mais um esforço colaborativo com contribuições da comunidade Swift em geral.
O framework de teste Swift fornece um exemplo notável. Ao longo do ano, a equipe de Testes do Swift trabalhou conosco para melhorar o suporte ao Windows. O quadro ganhou suporte melhorado para anexos, tornando mais fácil incluir informações diagnósticas nos resultados dos testes. A manipulação de imagens foi melhorada para funcionar naturalmente no Windows. A equipe também identificou e ajudou a melhorar o bridge de tipos fundamentais do Windows, como lidar corretamente com GUID tipos ao cruzar entre Swift e APIs do Windows.
Essas melhorias foram além das correções de bugs. A equipe de Testes do Swift tratou o Windows como uma plataforma de primeira classe, garantindo que novos recursos funcionassem corretamente em todos os sistemas suportados desde o início. Esse tipo de consciência multiplataforma é essencial para que o Swift no Windows se sinta um cidadão igual na ecossistema do Swift e não uma adição posterior.
À medida que a plataforma Windows amadurece, esperamos ver mais desse padrão: equipes da comunidade Swift contribuindo com suporte ao Windows não porque são especialistas em Windows, mas porque estão construindo ferramentas e bibliotecas que naturalmente abrangem todas as plataformas do Swift.
Além das melhorias no runtime e SDK, vários tópicos permanecem ativos: