- Houve reclamações nos fóruns do Swift de que incluir o Swift no OS acabou criando uma situação pior para os desenvolvedores
- Em resposta, houve um comentário sarcástico dando as boas-vindas ao mundo das bibliotecas fornecidas junto com o OS
- Este texto, com base na experiência de desenvolver o Swift na Apple, explica o contexto e os problemas por trás de o Swift ter se tornado parte do OS
Dependência do OS
- No passado, computadores pessoais permitiam que o processo em execução controlasse a máquina inteira, mas hoje o kernel do sistema operacional está sempre em execução e fornece os serviços básicos do OS
- A maioria dos OS modernos permite criar programas que podem solicitar certas operações privilegiadas por meio de uma interface de chamadas de sistema.
- Nos OS da Apple de hoje, como a interface de chamadas de sistema não é estável entre versões do OS, é necessário usar a biblioteca padrão C/POSIX e suas extensões para realizar tarefas básicas.
O modelo da Apple (antes do Swift)
- Antes do Swift, a maior parte das APIs públicas da Apple era escrita em C ou Objective-C e fornecida na forma de código nativo.
- Novas versões do OS incluíam novas versões compatíveis em binário das bibliotecas existentes, oferecendo um superconjunto que também continha as APIs das versões anteriores.
- A principal desvantagem desse modelo é que novos recursos e APIs ficam atrelados a novas versões do OS.
Swift "beta" 1 a 5
- Do Swift 1 ao Swift 5 houve muitas mudanças, e a estabilidade de ABI sempre foi um objetivo do Swift.
- Na transição para o Swift 5, a maior parte dos problemas foi resolvida, e foi preciso encontrar uma forma de incluir o Swift no OS sem afetar apps e projetos existentes.
A transição
- No processo de incluir o Swift no OS, foi necessário encontrar uma forma de não quebrar apps e projetos já existentes.
- Foi usado um recurso chamado
rpath, permitindo que executáveis procurassem bibliotecas dinâmicas em uma série de diretórios, em vez de um caminho fixo embutido.
O que perdemos
- Com o Swift incluído no OS, os apps deixaram de precisar empacotar o Swift, e a disponibilização conjunta dos runtimes de Swift e Objective-C tornou possíveis melhorias de desempenho.
- Porém, contribuidores externos do Swift passaram a enfrentar o problema de novas APIs existirem apenas em novos OS.
Alternativas
- Existem algumas maneiras razoáveis pelas quais a Apple poderia oferecer uma situação melhor para os desenvolvedores, mas não está claro se a empresa fará isso.
Conclusão
- Incluir o Swift no OS pode ter sido um mau negócio para desenvolvedores de apps, mas a Apple não podia abrir mão da opção de escrever bibliotecas de sistema em Swift.
Isso não é novidade relacionada ao Swift
- Muitos dos problemas relacionados ao Swift são consequência de bibliotecas fornecidas junto com o OS.
- Tanto as mudanças técnicas quanto as mudanças sociais do Swift influenciam essas questões.
Opinião do GN⁺
- Tornar o Swift parte do OS impõe restrições maiores aos desenvolvedores, mas isso é um resultado inevitável do modelo de distribuição de bibliotecas da Apple.
- Ao explorar os desafios técnicos e operacionais surgidos no processo de integrar o Swift ao OS e as soluções para eles, este texto destaca a complexidade do desenvolvimento de software e a importância do gerenciamento de bibliotecas.
- A integração do Swift ao OS trouxe para desenvolvedores de apps maiores tamanhos de arquivo e problemas de compatibilidade, mas deu à Apple a capacidade de escrever e atualizar bibliotecas de sistema em Swift, ajudando a manter a consistência e a segurança de todo o sistema.
Ainda não há comentários.