Swiftのバイナリフレームワーク

(音楽)

(拍手と歓声) こんにちは　ハーランです このセッションでは Xcode 11がどのようにして― Swiftでバイナリフレームワークを 作成 配信するかを話します しかし その前に Swift Packagesに触れておきます Xcode 11内のSwift Packagesは 新たにサポートされ― プロジェクトの作成や使用 他への配信が容易になりました

Swift Packagesは コードの配信に適しています Xcodeは それらの依存関係の 管理方法を知っており― どのパッケージを使うべきか 自動的に判断するからです

それらは ソースの形式で配信されるので― クライアントとのバイナリ互換性を 維持するための要件がありません プロジェクトのソースコードを 出荷できれば― Swift Packagesは すばらしいものになります

しかしライブラリのソースを 出荷できない場合 Xcode 11は― 新しいXCFrameworksフォーマットを使い バイナリライブラリの配信を助けます (拍手) そのXCFrameworksを紹介します バイナリフレームワークの配信のため 新たにサポートされた方法です 第三者のコードを使った場合に 考慮すべき点についても説明します

XCFrameworkの内部や プロジェクト用の作成方法にも触れます 最後には同僚のジョーダンに 登場してもらい― フレームワークをスムーズに 使うべきだという話をしてもらいます

XCFrameworksは フレームワークの バリアントをまとめる新たな方法で― 今後のXcodeのバージョンを通し 機能します

単一のXCFrameworkは― シミュレータ用とデバイス用の バリアントを含めることができます (拍手) XCFrameworksが含むバリアントは― Xcodeがサポートする どんなプラットフォームでも対応します (拍手) AppKitやUIKitを使用するMacの アプリケーション用のものもあるので クライアントがどのAPIを使っても フレームワークを効果的に使用できます

またXCFrameworksは フレームワークをまとめるだけでなく 静的ライブラリと対応するヘッダを まとめることもできます またXcodeはクライアントの 検索パッドを自動的に設定します そして もちろん… (拍手) XCFrameworksは― SwiftとＣ言語のコードの バイナリ配信をサポートします

XCFrameworkの使用が いかに簡単かをお見せします

iOSのシンプルなアプリケーションです Runをクリックし iPadのシミュレータ上で実行します 青い起動ボタンがありますが クリックしても何も起こりません

それは このlaunchメソッドにつながり ボディが空っぽだからです そこでFlightKitという すばらしいXCFrameworkの登場です

このアプリケーションで お見せしたいUIを与えてくれます FlightKitのXCFrameworkを使う 手順をお見せします “Project Navigator”内の “Project”をクリックし― “General”タブを選びつつ ターゲットを選択 “Frameworks, Libraries, and Embedded Content”までスクロール

そしてXCFrameworkをドラッグ ターゲットに依存するものとして 自動的につなげられました コードに戻り 実際に使ってみましょう

これまでのフレームワーク同様に 最初はimportをします

ここでFlightKitのAPIを いくつか使ってみます ドキュメンテーションから 見てもいいですし― FlightKitの部分を コマンド＋クリックし― “Jump to Definition”を クリックしてもいい これでFlightKitのために生成された インターフェイスが見られます パブリックタイプなど すべてのパブリックAPIを示し― FlightKitのインポートで使用できます

UIViewControllerのサブクラスである LaunchViewControllerがあります これは お見せしたいUIの 一部になります さて これらを作成する方法ですが― インターフェイスにはSpaceshipという イニシャライザがあります これもFlightKitの一部になります “Jump to Definition”を選び インターフェイスのさらに下へ行き― Spaceship内で利用できるものが 見られます

パブリックに格納された “name”というプロパティがあります “name”を取るパブリックの イニシャライザもあります これでSpaceshipを作り― LaunchViewControllerを作成し お見せすることができます

コードに戻り 実演しましょう まずはshipを作成 FlightKit内に何があるかは― auto completionが 示唆してくれています これまでのフレームワークと同様です auto completionを受け入れ shipの名前を選んでいきます shipの名前の配列は いいものが すでにあります shipの名前の配列から ランダムな要素を選びましょう

LaunchViewControllerを作成し―

そこへ今 作ったshipを渡します

最後はコントローラに 私が送信者だということを示します

shipとUIを作成したので 今度はそれをお見せしましょう シミュレータ内でプログラムをビルドし 実行します Launchをクリックすると ランダムな名前が選ばれUIが起動します

クリックするたびに 別の名前が選択されていきます これは１つのプラットフォームで XCFrameworkを使う方法ですが― XCFrameworksでは 同じバンドルに 複数のバリアントを入れられます XCFrameworkをドラッグするだけで ビルドし 実行できるだけではない

“Generic iOS Device”を選択してから “ProductのArchive”を選べば― App Store用のアーカイブを ビルドすることもできます

コードからXCFrameworkを使用するのは とても簡単でしたね (拍手) フレームワークを使おうと思った時― 第三者のコードで 何ができるか知っておくことは重要です 大切なのはフレームワークのソースを 信頼することです アプリケーションにバグが生じたり 不安定にならないこと ユーザのプライバシーを 尊重するものだと信じることです

アプリケーションで エンタイトルメントを与えられたなら そこで使うフレームワークにも エンタイトルメントが与えられます ユーザによる許可も同様です

特定のエンタイトルメントを想定した フレームワークを採用した場合は― それをアプリケーションに追加するかは あなたの責任になります

もう１点 フレームワークを 使用する際に考慮すべきは― 依存関係が伴うということです 依存関係のあるもの自体にも また別の依存関係がある それらをプロジェクトに追加することも あなたの責任になりますし― そこまで信頼を広げていく必要もある

こうした信頼は Swift Packagesの使用時も必要です バイナリフレームワークを越えた パッケージの利点の１つが― デバッグしている間に コードを調べられることです XcodeでSwift Packagesを 使用する方法は― 他のセッションもご覧ください

しかしパッケージでも バイナリフレームワークでも― Xcode 11では信頼する第三者のコードを 簡単に使用できます

それでは XCFrameworkの 作成方法についてお話ししましょう まずは配信したいソースコードを 用意しましょう

先程のFlightKitのソースコードを 見てみましょう これはFlightKitのオブジェクトの サブセットの一例です 先程 見たSpaceshipのタイプです “Speed”という この列挙型は 空間内で物が動く速度を示しています “Location”という構造体は 空間内のオブジェクトの位置を表します

こうしたコードになります 配信のためには ライブラリを どうビルドすればいいでしょう Xcode 11には ビルド用の新設定があります “Build Libraries for Distribution”です その名が示すとおり― 配信でライブラリをビルドするのに 必要なすべての機能を有効にします その機能の１つについて説明します

ビルド済みのSwift Frameworkを 誰かに送った際― このエラーのバリアントを見たことが あるかもしれません

“コンパイル済みモジュールは 新バージョンのコンパイラで作成”

このエラーは何なのでしょう？ Swiftのコンパイラが モジュールをインポートしようとすると “Compiled Module”というファイルを ライブラリのために探します

これらのファイルの１つを 見つけると― 呼び出しできるパブリックAPIの マニフェストを読み上げ― 使用が可能になります

“Compiled Module”のフォーマットは バイナリのフォーマットで― 基本的に内部コンパイラの データ構造を含んでいます それらは単に 内部のデータ構造なので― Swiftのコンパイラのバージョンごとに 変わる可能性があります 仮に あるバージョンのSwiftで インポートされたモジュールがあり― そのモジュールを 別バージョンのSwiftで作成するとする すると そのコンパイラは理解ができず 使うことができなくなります

Xcode 11ではこのバージョンロックを 解決するために― “Swift Module Interfaces”という 新フォーマットが導入されました

これは“Compiled Module Format”同様― モジュールの全パブリックAPIを リストアップします しかしテキスト形式では ソースコードのように動作します ソースコードのように動作するため― おそらく Swiftのコンパイラの 今後のバージョンでは― 旧バージョンのモジュールの インターフェイスもインポートできます

“Build Libraries for Distribution”を有効にすると― コンパイラに指示し― フレームワークをビルドする際は 安定したインターフェイスを生成します

そうしたインターフェイスは どのようなものなのでしょう FlightKitのソースを 再び見てみましょう

これがFlightKitのソースです 右にはFlightKit用の Module Interfaceがあります たくさんあるので 少しずつ見ていきます

まずはメタデータがある このセクションを見ましょう ここにはインターフェイスを作成した コンパイラのバージョンのほか― コマンドラインフラグの サブセットも含まれています Swiftコンパイラがモジュールとして インポートするのに必要なものです

このフレームワークがインポートする すべてのモジュールの後―

インターフェイスのタイプが出てきます これはSpaceshipクラスの パブリックAPIです ここで留意点が３つ

“name”のパブリックなプロパティが インターフェイスに含まれることが１つ プライベートな位置のプロパティは 含まれていません

これはパブリックAPIには 含まれないのです

次にパブリックイニシャライザと flyメソッドが― インターフェイスに含まれていること しかしパブリックAPIに属さないため それらのボディは含まれていません

またこのクラスのインターフェイスには 初期化解除の方法がありますが― 元のソースコードで書かれたものは ないということも挙げられます Swiftでクラスを書き込む際 系統立って初期化解除をしないと― コンパイラが自動的に生成してくれます

これはModule Interfaceの 基本原則の１つです このフォーマットがコンパイラの バージョン間で安定していた場合― コンパイラは 基礎となるソースコードを仮定しません Module Interfaceに含めます

次に“Speed”の列挙型を見ましょう ここには列挙型の２つのケースが 含まれています それらはパブリックAPIの一部です

しかしインターフェイスには “Hashable”への明示的な適合がある これと“Equitable”に適合させるため 必要なメソッドをリストにします Swiftでは関連する値のないまま 列挙型を作成すると― コンパイラはそれを暗黙のうちに “Equitable”“Hashable”に適合させ 必要なメソッドを 自動的に引き出すのです 明示的であり 仮定をしないという状況で― 列挙型はModule Interfaceに 含まれているわけです

Location構造体も そのまま含まれています パブリックに格納された プロパティだけがあり― いかなる適合性も 宣言していないためです

以上がFlightKitの Module Interfaceの話です

これまでフレームワークの 中身に触れましたが― 配信可能なバイナリXCFrameworkを ビルドする方法も見ましょう

最初のステップは アーカイブをビルドすることです “Archiving Your Framework”が リリースモードにビルドされ― 配信のためにパッケージ化され Organizerウインドウで見られます このアーカイブにはデバッグの情報が 含まれるのも利点です それはフレームワークの ビルドに対応します フレームワークが原因のクラッシュや 不安定性があると― 情報が送られてくるのでシンボルを見て デバッグできるようになります

フレームワークのアーカイブには xcodebuild archiveコマンドを使います プロジェクトのフレームワークの スキームを渡し― それをコンパイルする先を リストにしてください iOS用にビルドしているなら １つはシミュレータ用になります デバイス用のもの UIKitを実行するMac用のものもあります

“Skip Install”のビルド設定を渡し “No”に設定する必要があります フレームワークのインストールの指示が xcodebuildアーカイブに伝わります

これでフレームワークの各バリアントの アーカイブをビルドできます これらは“Xcode Locations”タブの アーカイブディレクトリにあります “Preferences”ウインドウ内ですね

アーカイブをビルドしたら フレームワークを引き抜き― １つのXCFrameworkに まとめることができます そのために“xcodebuild -create -xcframework”コマンドを実行 ディスク上の各フレームワークに パスを渡し― output XCFrameworkの出力先となる パスを指定します

以上がXCFrameworkを ビルドする方法ですが― “Build Libraries for Distribution”は有効にしておきたい

xcodebuildアーカイブを実行して フレームワークのアーカイブをビルドし 最後に“xcodebuild -create -xcframework”を実行します 配信用にパッケージ化するためです それをクライアントに送れば 採用を始めてもらえます

以上がXCFrameworksの話です ここでジョーダンに登場してもらい― フレームワークをスムーズに使う方法を 考えましょう (拍手と歓声) ありがとう　ハーラン ご覧いただいたように XCFrameworksを― アプリケーションに取り込むのは 簡単でした XCFrameworkの作成に 必要な手順も見ました しかし それは第一歩です フレームワークの作り手は 毎年のように新機能を開発し― どんどんクライアントの 役に立っています ここでは主に３点 お話しします フレームワークを リリースのたびに進化させることと Swiftがクライアントのために 与えてくれる柔軟性を交換すること そしてクライアントのスムーズな経験を 手助けする話です

まずはフレームワークの進化の話です フレームワークの進化とは何でしょう 先程も触れたように― フレームワークの新バージョンを リリースするたびに― 新機能や新しいAPI 新たなバグ修正が発生します それはソースやバイナリの互換性を 損なうことなく実行したい バイナリの互換性が 重要となってくるのは― クライアントが誰になるかが 必ずしも分からないからです 多くの場合は単に アプリケーションのターゲットです 彼らは あなたのフレームワークを 入手し まとめ Storeに送ります 自身がバイナリフレームワークである クライアントもあります あなたの仲間であっても なくてもです この場合は おそらく互いに別の リリーススケジュールを持っています 最新バージョンに取り組んでいる時に 相手はバージョン2.1かもしれない あなたがバージョン1.1を リリースする時― その採用で 相手に余分な努力を させたくはありません ２つのバイナリフレームワークが バージョンロックされた状況は避けたい 使用しているアプリケーションが 更新をしない可能性もあるからです

だからフレームワークのバージョンは 重要なのです それらはWebサイトや ドキュメンテーションだけでなく― フレームワーク自体にも含めるべきです それを行う場所が― “Information Property List”内の “Bundle version string”です ここでのバージョンナンバーは 人が読めるもので― 前回のリリース以降の変更内容を クライアントに知らせることができます

それはSemantic Versioningを使って 行うことをお勧めします Semantic Versioningとは何かを 簡単にお見せします

最小のコンポーネントである Patch Versionは― クライアントに影響がないよう いつバグ修正などを行ったかを表します

中間のコンポーネントは― 下位互換性のあるエディションや 新しいAPI 新機能のためのものです

メジャーなコンポーネントは ブレークを伴う変更のためのものです ソースやバイナリ セマンティクスが ブレークした場合などです 再ビルドやクライアントコードの やり直しを求められ― クライアントが新しいフレームワークの 採用を迫られる場合です

FlightKitのモデルオブジェクトを使い 実際に見てみましょう 左側は以前のものと同じですが― 右側は このフレームワークに たくさんの変更を加えたものです フレームワークのバージョンナンバーに 変更がどう影響するかを見てみます まず最上部から Spaceshipクラスに― 新たなプライベート プロパティを 追加しました 使っているのは Spaceshipのイニシャライザ内です Module Interfaceに これらは出てきません フレームワークのパブリックAPIの 一部ではないのです この種の変更には― マイナー またはPatch Versionの コンポーネントの更新のみが必要です

イニシャライザの動作を変更したことは 覚えておいてください 以前に記録された動作の場合― セマンティクスのブレークの変更となり クライアントには更新の検討が必要に ここでメジャーなバージョンナンバーを 代わりに変更するのです

次の変更は Spaceshipクラスに 新メソッドを追加したことです これは新しいパブリックメソッドで クライアントも使うことになります ここですべきことは マイナーな バージョンナンバーを増やすことです Patch Versionは ゼロにリセットしています

最後に flyメソッドには 新しいパラメータも追加しました デフォルトを指定したので ユースサイトの変更の必要はありません しかしSwiftでは 関数は 名前とパラメータで識別されます 引数のラベルと型の両方でです ここでソースとバイナリの互換性の 両方をブレークし― メジャーなバージョンナンバーの更新と クライアントの再コンパイルを求めます 新たな負荷を 用意すべきだったかもしれません

これらはSpaceshipクラスへの 変更ですが― 私はFlightKitの値型も いくつか同様に変更しました “Speed”列挙型に新たなケースを追加 クライアントがセットを持てるよう 位置は“Hashable”に この変更はお気に入りです Location構造体に ストアドプロパティを追加しました ソースやバイナリの互換性を 損なうことなくです (拍手) Swiftでは これらの変更には 下位互換があるため― マイナーなバージョンさえ 上げればいい

この柔軟性は フレームワークの APIの設計にも影響します 最も重要なのは 小さい状態から始めることです 必要な時に新機能を追加するのは 簡単です クライアントがフィードバックで より多くの機能を求める場合もです しかし何かを削除するのは難しいです ソース またはバイナリの互換性を 何かしら壊してしまうからです

型の名前のように 後から変更できないものは― 将来のリリース時も理にかなうよう 慎重に検討してください

そして拡張性は 早く追加しすぎないでください クラスをオープンにしたり― フレームワークの最初のバージョンでの 任意のコールバックの提供は不要です フレームワークの動作の理由付けが 難しくなるからです その時は同時に クライアントの動作も 考慮しなければならない クラスは将来 いつでも オープンにできます 追加のコールバックを表すプロパティも いつでも追加できます しかしデフォルトで入れた柔軟性は 取り除くことができません

これが どう機能するかというと… Indirectionです どういうことか見てみましょう 左側のModule Interfaceに 省略されたSpaceshipクラスがあります 右側ではflyメソッドを使っています FlightKitフレームワークの外側にある クライアントコードからきたものです 実行時には ここで― どのメソッドがflyメソッドなのかを クライアントが尋ねます

そしてフレームワークは “２番目です”と答える

Swiftはこの方法で バイナリの互換性を保証するのです 新たなメソッドを クラスに追加してもです これはObjective-Cが メッセージを送るのと同じ方法で― ライブラリからライブラリへ 呼び出しをするものです しかしSwiftでは― クライアントのフレームワークの 境界を越えた時にだけ行います

他の形式のIndirectionは クライアントが― フレームワークで定義された 構造体や列挙型を使っている時です flyメソッドに関し 論点となるのは Speed列挙型の速い例です 先に触れたとおり― 列挙型はバイナリ互換性を壊すことなく 新しいケースを追加できます 列挙型がどれだけメモリを占めるかを クライアントは予測できません そこで 列挙型のデータ量について クライアントがフレームワークに尋ねる そうするとフレームワークが “ちょうど１バイトです”と答えます

他に考えられるのが― 今後の新しいケースが 関連する値を持つ可能性があることです そうした値はある種のクリーンアップを 必要とするかもしれません クライアントが終了後 列挙型の値の クリーンアップを指示すれば― フレームワークはそれに従います

ソワソワされている方もいると思います でも クライアントとフレームワークの コミュニケーションの話をするのは― パフォーマンスに敏感な フレームワークがあるからです そこで次は― Swiftが与えてくれている柔軟性を 交換することについて話します

これぞまさに交換条件です フレームワークの作り手としては 変更 追加 改善を柔軟に行いたい ソースやバイナリの互換性を 損なうことなくです しかしクライアントコードを コンパイラが速くするためには― フレームワークの中身が何かを 仮定をする必要があります

そのためSwiftは スペクトルの両側を 処理する必要があります

これを機能させる設定が“Build Libraries for Distribution”です Module Interfaceのファイルの 生成以外にも効果はありますが その１つが デフォルトを Flexibilityの側に設定することです

しかしSwiftは これらのユースケース すべてを処理できないといけない ここでは何ができるかをお話しします フレームワークの動作を外側から プロファイルしたら― 追加のパフォーマンスが必要です 方法は３つあります Inlinable関数と― フリーズされた列挙型 および構造体です

昨年 Swift 4.2で導入された Inlinable関数から話しましょう ここにある Spaceshipクラスの CargoShipサブクラスには― “canCarry”というメソッドがあります これはCargoShipが貨物を運べるかを 決定するだけのものです

クライアントのパフォーマンスのため これをインライン化してみました メソッドはパブリック インターフェイスの一部になります 宣言だけでなくボディも含めてです ボディはModule Interfaceの ファイルにコピーしたい

読み込みが速い場合― このメソッドは CargoShipクラスの 内部のプロパティを参照します

これはプロパティをインラインで 使えるものとしたから可能なのです 両方の長所も生かせます このプロパティは フレームワークの― パブリックインターフェイスの 一部として利用可能です しかしそれはinlinableコードでのみ 利用でき― 外部のクライアントが 読み書きできなくなっています 内部的ですが インラインからは使えます これは宣言ごとの決定である点にも 注意が必要です 内部の貨物の特性は Module Interfaceには含まれていません

そのためModule Interfaceに “canCarry”メソッドのボディがある クライアントがインターフェイスに対し コンパイルをする際は― ボディを自分のコードに 直接コピーすることができます チェックされた貨物の情報があれば それをさらに最適化するでしょう

しかし フレームワークの所有者が メソッドのボディを変更し― クライアントが 再コンパイルをしない場合は？

放射性貨物は運搬できないという CargoShipの新ルールがあるとします

この場合は問題発生です このメソッドが何をすべきか プログラム内部で考えが割れるのです いくつかの入力では 通常の貨物の運搬は許可され― クライアントとフレームワークの双方が 同意するはずです

しかし放射性の貨物を試す際 同意を得られるのは― コンパイル時にModule Interfaceに 表示されるものだからです フレームワークには新バージョンの メソッドがあるので許可はされません これはプログラムの重大な ロジックエラーの可能性があります したがって作り手として 関数をインライン化するなら― 出力や観察可能な動作は 変更しないように注意してください より良いアルゴリズムや速いパッドを 追加するのは構いません しかし関数の 観察可能な動作を変えると― 実行時にしか見えない微妙な問題に 遭遇する可能性があります 実行するなら すべてのクライアントが 再コンパイルする必要があります

次に列挙型の話です Swiftの列挙型は すばらしいんです 列挙型に新しいケースを 追加できるという話もしましたね ソースやバイナリの互換性を 損なうことなくです クライアントが列挙型を切り替える際は デフォルトのケースが必要になります 今回はunknown defaultシンタックスを 使うことにしました Swift 4.2でも導入されたものです

これは列挙型の中の既知のケースを すべて処理したということですが― 今後追加されるケースも 処理していきます これはＣの列挙型を 切り替える際に必要です バイナリフレームワークに組み込まれた 列挙型も必要になります

他の効果については 先程 話したとおりです クライアントとフレームワークが ある意味で握手をし― 列挙型の大きさや クリーンアップの必要性を話し合います

ここで選んだ例はフライトプランです フライトには 片道か往復しかありません この列挙型をフリーズした属性で マークすると― フレームワークの作り手として 約束ができるようになります 将来のフレームワークのリリース時に 追加されるケースがないことをです クライアントはそのデフォルトケースを 書き出す必要がありません 放置すればいいのです

そしてコンパイラはそれを より効率的にコンパイルできます クライアントは想定が可能になります この列挙型には追加のケースはなく クリーンアップも不要だと いいことですね

しかし１点 忘れています multiHopという 別のフライトプランがあるのです そのクライアントコードには すでに デフォルトのケースがないことから― フリーズした列挙型へのケースの追加は ソースとバイナリを損ない― メジャーバージョンの増加や すべての クライアントに再コンパイルを求めます

列挙型がフリーズすると 構造体もほとんど同じになります バイナリフレームワークの構造体は 新しいプロパティを追加するか― 問題なく並べ替えられた 既存のものを追加します しかし それは先程の握手のように 余分なコミュニケーションを要します

そのためフリーズしたレイアウトを持つ 構造体については― 格納されたプロパティの変更はないと 保証するために使用できます 追加 並べ替え 削除はされません

また格納されたプロパティはすべて 型を持つことを要求します これはパブリックであるか インラインから使用できます 目標を思い出しましょう クライアントコードを扱う際は コンパイラが欲しいです 構造体が格納されたプロパティを 直接操作できるようにし― より効率的なコードをクライアント側で 生成できるようにします

作り手は インライン化された イニシャライザの書き込みもできます イニシャライザは構造体に格納された 全プロパティの設定で必要ですが― コンパイラは 将来のバージョンでも そうなることが分かっています

最後に柔軟性が デフォルトであることについて話します 変化のブレークは クライアントには不便なことです フレームワークの新バージョンを 利用すべきか検討する必要があります ブレークの可能性があるからです バイナリフレームワークが 別のものに依存すると問題も起きやすい これらはクライアントコードにのみ 影響を与えることにも注意してください コンパイラの最適化のためのパワーは まだフルで得られます フリーズ状態になるか インライン化される前に― フレームワークの動作が外側から プロファイリングされており― 追加のパフォーマンスで必要なものが 示されているかを確認しましょう そうでなければ 柔軟性は維持しておいてください

最後に話したいのは― クライアントの経験を 最高なものにしようということです 前半のハーランの話も 大いに反映した内容です まずはエンタイトルメントの話から 仕事で必要なエンタイトルメントが フレームワークにあるなら― 基本から始めましょう それらは潜在的なクライアントのために 記録をし― あなたのフレームワークを採用する際 何が必要かを知らせましょう

また特定のフレームワークの エンタイトルメントの要求は最小限にし より多くのコンテクストで 適用可能にしましょう そうすれば あなたのフレームワークは より多くのクライアントに使われます

最後に覚えておいてください フレームワークもアプリケーションも ユーザの許可を求められますが― 許可するかどうかは 最終的にはユーザが決めます 拒否された場合も フレームワークが 適切に処理できるようにしてください アプリケーションのクラッシュも 動作停止も避けましょう フレームワーク使用を断念されないよう 有用なことは続けてください

依存関係にも エンタイトルメント同様の懸念が フレームワークの依存関係は アプリケーションの依存関係になります これらも 記録化することから始め― 潜在的なクライアントに 何をしているのか知らせましょう 質問を減らすため 依存関係も最小限に抑えるべきです 信頼の拡大や― 依存関係によって占められる コードサイズのような問題もです

そして最後に 依存関係は“Build Libraries for Distribution”でビルドします バイナリの互換性を保証するためです

バイナリフレームワークは パッケージには依存できないのです 依存関係のグラフを見てみましょう フレームワークの依存関係は アプリケーションの依存関係になります パッケージのビルド時は特定のタグを 選択する必要がありますが― あなたのフレームワークのバージョンと 互換性がない可能性もあります それにフレームワークは必ずしも― “Build Libraries for Distribution”と互換性はない なので このコンフィギュレーションは サポートされていません

Objective-Cの インターフェイスの話もしましょう Swiftフレームワークの作り手なら 持っていますよね Xcodeのデフォルトの テンプレートは― 混合のソースフレームワーク用に 設定されています そこには Objective-Cの アンブレラヘッダと― SwiftのObjective-Cの部分を含み 生成されたヘッダがあります

Swiftコードが 公開しようとしている Objective-C APIを持っていなければ ２番目のヘッダは インストールする必要はありません Install Objective-C Compatibility Headerがオフにしてくれるからです

もし あなたのフレームワークに Objective-C APIがないのなら― Objective-C Importシンタックスを サポートする理由はなく― “Defines Module Build”設定で 無効にすることもできます “No”と設定すれば 有効なObjective-Cコードにもならない 済んだらXcodeが生成した アンブレラヘッダを削除できます

話をまとめましょう 今日の話で最も重要だった XCFrameworksは― 複数のフレームワークバリアントを 配信するための新たな形式です XCFrameworkをビルドするためには― “Build Libraries for Distribution”のビルド設定はオンに バイナリ互換フレームワークを適正にし 必要なもの活性化させるためです クライアントにベストを提供できるよう ご自身の責任は認識しましょう

ハーランと私はこの後 ラボへ行きます 皆さん どうもありがとうございました (拍手と歓声)