Swiftは、常にOSの一部になる予定だった

• SwiftをOSに含めることは、開発者にとってより悪い状況をもたらしたという不満がSwiftフォーラムで提起された
• これに対する反応として、OSとともに提供されるライブラリの世界へようこそ、という皮肉な意見があった
• この記事はAppleでSwiftを開発していたときの経験をもとに、SwiftがOSの一部になった背景と問題点を説明する

OS依存性

• かつてはパーソナルコンピュータが実行中のプロセスにマシン全体の制御を許していたが、現在ではオペレーティングシステムのカーネルが常に実行され、基本的なOSサービスを提供している
• ほとんどの現代的なOSは、システムコールインターフェースを通じて特定の特権操作を要求できるプログラムを作成できるようにしている。
• 今日のApple OSでは、システムコールインターフェースがOSのバージョンごとに安定していないため、基本的な処理を行うにはC/POSIX標準ライブラリとその拡張を使う必要がある。

Appleのモデル（Swift以前）

• Swift以前、Appleの公開APIの大半はCまたはObjective-Cで書かれ、ネイティブコードの形で提供されていた。
• 新しいOSバージョンは既存ライブラリの新しいバイナリ互換版を含み、以前のバージョンのAPIを含む上位集合を提供していた。
• このモデルの主な欠点は、新機能と新しいAPIが新しいOSバージョンにひも付けられていることだった。

Swift "ベータ" 1〜5

• Swift 1からSwift 5にかけて多くの変更があり、ABI安定性は常にSwiftの目標だった。
• Swift 5への移行にあたって大半の問題は解決されたが、SwiftがOSに含まれる際に既存のアプリやプロジェクトへ影響を与えない方法を見つける必要があった。

移行

• SwiftをOSに含める過程では、既存に構築されたアプリやプロジェクトを壊さない方法を見つける必要があった。
• rpathという機能を使い、実行ファイルがハードコードされたパスではなく一連のディレクトリを検索して動的ライブラリを見つけられるようにした。

私たちが失ったもの

• SwiftがOSに含まれたことで、アプリはもはやSwiftを同梱する必要がなくなり、SwiftとObjective-Cランタイムが一緒に提供されることで性能向上も可能になった。
• しかし外部のSwiftコントリビューターは、新しいAPIが新しいOSにしか存在しないという問題に直面した。

代替案

• 開発者により良い状況を提供するためにAppleが取り得る合理的な方法はいくつかあるが、Appleがそれを実行するかどうかは不確かだ。

結論

• SwiftがOSに含まれることはアプリ開発者にとって悪い取引だったかもしれないが、AppleはシステムライブラリをSwiftで書けるという選択肢を捨てることはできなかった。

Swiftに特有の新しい話ではない

• Swiftに関する多くの問題は、OSとともに提供されるライブラリの結果である。
• Swiftの技術的変化と社会的変化の両方が、こうした問題に影響している。

GN⁺の見解

• SwiftがOSの一部になることは開発者により大きな制約を課すが、これはAppleのライブラリ配布モデルの必然的な結果である。
• この記事は、SwiftがOSに統合される過程で生じた技術的・運用的な課題とその解決策を探ることで、ソフトウェア開発の複雑さとライブラリ管理の重要性を強調している。
• SwiftのOS統合はアプリ開発者にとってはファイルサイズの増大や互換性の問題をもたらしたが、AppleにとってはシステムライブラリをSwiftで記述し更新する能力を提供し、システム全体の一貫性とセキュリティの維持に役立った。