Swift sempre ia fazer parte do sistema operacional (2022)

Artigo original ↗ Discussão no Hacker News ↗

A decisão da Apple de integrar fortemente o Swift aos seus sistemas operacionais gera debate sobre as trocas entre runtimes empacotados com o sistema e frameworks enviados pelo próprio app. Os comentaristas comparam a abordagem da Apple com .NET, Android e COM, ponderando benefícios como desempenho, consistência e upgrades automáticos de UI contra desvantagens como adoção mais lenta de novos recursos, menor compatibilidade retroativa e o risco de piora da UX quando frameworks como SwiftUI evoluem por baixo dos panos. O debate também aborda as características de desempenho do Swift, a estabilidade da ABI e como a estratégia de plataforma da Apple influencia a longevidade do hardware e as escolhas do ecossistema de desenvolvedores.

Swift vs .NET e estratégia de plataforma

  • Swift é posicionado pela Apple como um sucessor de C/Obj‑C/C++ para o próprio sistema operacional, ao contrário da visão original do .NET de “Java melhor / serviços web / substituto do COM”.
  • O caminho da Microsoft foi do .NET Framework preso ao sistema operacional para runtimes lado a lado, empacotados com os apps (.NET Core/5+), eliminando o Global Assembly Cache e grande parte da velha maquinaria de “DLL hell”.
  • Sistemas de pesquisa como Singularity e Midori influenciaram C#/.NET, mas nunca se tornaram mainstream; houve alguns experimentos de C# no nível do kernel fora da Microsoft.

Inclusão de Swift/SwiftUI no sistema operacional

  • Pro: Bibliotecas compartilhadas do sistema oferecem melhor desempenho, apps menores, UI consistente e melhorias “gratuitas” quando os componentes de UI do sistema evoluem. Em espírito, é parecido com JavaScript nos navegadores.
  • Pro: A abordagem da Apple pode reduzir encargos de compatibilidade e manutenção de longo prazo, potencialmente levando a sistemas melhores no geral.
  • Contra: As bibliotecas não podem ser atualizadas independentemente, o que desacelera a adoção de novos recursos da linguagem/framework; os desenvolvedores precisam esperar a adoção no sistema operacional.
  • Contra: O acoplamento estreito incentiva o abandono do suporte a versões mais antigas do sistema operacional e, indiretamente, acelera a obsolescência de hardware.
  • Alguns sugerem um modelo híbrido em que versões específicas do Swift são baixadas sob demanda por app, mas outros destacam preocupações de armazenamento, linker, memória, DRM e complexidade.

Qualidade do software da Apple e UX

  • Vários comentários criticam apps recentes do macOS escritos com SwiftUI (por exemplo, Ajustes do Sistema, Música) como regressões em UX e confiabilidade.
  • Outros argumentam que a linguagem/framework não é o problema central; problemas organizacionais, falta de QA e ritmo insustentável são os culpados.
  • Há discordância sobre o quanto o próprio Swift/SwiftUI contribui para esse declínio percebido.

Design da linguagem, desempenho e gerenciamento de memória

  • Swift é elogiado como uma combinação rara de bom desempenho (AOT, ARC), segurança (optionals, verificação de limites) e relativa facilidade de uso.
  • Alguns veem o acoplamento forte à Apple como algo que limita a adoção mais ampla do Swift, em paralelo ao Windows-centrismo do C# inicial.
  • Vários comentários debatem desempenho: o Swift muitas vezes fica atrás de C#/Java/Rust em microbenchmarks, com a contagem de referências (ARC) citada como um overhead significativo; outros dizem que ele está dentro de um pequeno fator constante e é “rápido o suficiente” para apps típicos.
  • A contagem de referências é defendida como uma boa opção para dispositivos com memória limitada e alimentados por bateria, trocando overhead de CPU por heaps menores e coleta mais determinística.

Compatibilidade, ABI e evolução

  • Levantam-se preocupações sobre linkagem dinâmica de ABIs que não sejam C; alguns gostariam de interfaces estáveis em estilo C para frameworks da Apple (tipo COM) para ajudar bindings entre linguagens.
  • O Swift agora tem uma história de ABI em evolução, incluindo documentação de library evolution e trabalho de interoperabilidade (por exemplo, com .NET).
  • Alvo de implantação: os apps definem um sistema operacional mínimo; alguns recursos do Swift exigem runtimes mais novos e não fazem back-deploy, mas a ABI pretende permanecer compatível (por exemplo, até o Swift 6).
  • Novos atributos como @backDeployed são comparados a polyfills, permitindo que métodos de API mais novos rodem com implementações padrão em sistemas operacionais antigos.

Notas de ecossistema e ferramentas

  • As experiências de construir apps em Swift costumam ser positivas (rápido, bonito com pouco esforço), embora o Core Data seja visto como complicado em comparação ao mais novo SwiftData.
  • Alguns elogiam distribuições Linux e gerenciadores de pacotes como um modelo contrastante para distribuição e atualização de bibliotecas.