Swiftの大きな設計目標のひとつとして，ロード時の実装抽象化とコードの効率的な実行を両立することがある – 作業中のAppleの文書には，このように記されている。この資料はSwiftの標準ライブラリを含む，ライブラリ設計に関する情報を提供する。
ライブラリ設計が直面している主要な要件として，将来のクライアントと現行バージョンのライブラリとの互換性(前方互換性)，既存クライアントとライブラリの将来バージョンとの互換性(後方互換性)がある。
基盤となる実装を変更した場合にも，変更前のインターフェースを満足することで，公開されたインターフェースを使用して記述されたコードが引き続き機能することが保証できれば，これらの条件は満足することができる。
ライブラリの発展についてAppleが問いかけている議論は，ロード時チェックに極端な負荷を課すことなく前方および後方互換性を実現する，という目標に適するように，Swiftの設計と機能に影響を与えることが目的だ。
この目標を達成するためにAppleの資料には，ライブラリ設計者に対して，次のようなプラクティスを定義する試みが行われている。
- 特定バージョンのAPIを必要とするクライアントが，そのバージョンの利用可能な場合にのみ動作可能とするために，バージョン管理されたAPIを使用すること。
- 互換性を棄損しないことを保証されている変更のみを可能とすること。この目的のためにAppleは，ライブラリの新バージョンのリリースする際に安全な変更を，すべて文書化しようとしている。そのような変更の例としては，関数本体の修正，内部のパラメータ名の変更，パラメータへのデフォルト値の追加などがある。一方で，関数の一般的要件の変更やパラメータ順序の変更といった修正は除外される。Appleの資料は関数以外にも，構造体や列挙型，プロトコル，クラス，拡張機能など，他のタイプにも同様の保証を行なおうとしている。
ロード時の抽象化を追求することは，最適化の面でもコストを課すことになる可能性がある，とAppleは指摘する。実際に最適化の多くの部分は，グローバルメモリへのアクセスの有無やstructのメンバ数などといった機能の実装に依存している。従って前方および後方互換性を必要とするクライアントは，このような面での最適化を避ける必要がある。
その他の懸念点としては，インライン可能なコード – これは最終的にクライアントモジュールに含まれることになるので，現在のモジュールの外部と考えるべきである，ローカルアベイラビリティコンテキスト – これは‘#available’構成の関数本体への適用方法に影響する，promiseと型 – 型の‘trivial’指定や最大‘size_in_bits’宣言など，が挙げられる。
前述のように資料は現在作成中であるため，基本な部分で変更される可能性がある。興味のある向きは，今後の動向に引き続き注目する価値があるだろう。