WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Distribute binary frameworks as Swift packages

Distribute binary frameworks as Swift packages

WWDC 2020SwiftSwift Package ManagerXCFramework
元の動画を見る

ハイライト

Xcode 12 により、Swift Package Manager が次の経由で利用可能になります。.binaryTargetプリコンパイル済みの配布.xcframework、ユーザーはソース コード パッケージを追加するのと同じように依存関係を宣言し、発行者は HTTPS URL とチェックサムを使用してダウンロードされたバイナリ ファイルを検証します。

主要内容

Xcode 11 より前は、Swift Package Manager が主にソース コード ライブラリの配布を解決していました。オープンソース ライブラリはソース コードをパッケージに入れることができ、ユーザーは Xcode に依存関係を追加し、バージョンの更新とビルドはツール チェーンによって処理されます。クローズドソース SDK のエクスペリエンスは異なります。通常、作成者はコンパイルされたフレームワークのみを提供し、ユーザーはそれを手動でダウンロードし、プロジェクトにドラッグし、プラットフォーム スライスを処理して、バージョンが一致するかどうかを確認する必要があります。

Xcode 11 で導入された XCFramework は、バイナリ形式の問題を解決します。 XCFramework は、さまざまなプラットフォームやターゲット環境のフレームワークやライブラリを組み合わせることができ、各サブディレクトリはターゲット トリプルに対応します。クローズド ソース ライブラリの配布には適していますが、Swift パッケージの依存関係解決プロセスにはまだ入っていません。

Xcode 12 はこれら 2 つの行を接続します。 Swift ツール バージョン 5.3 新規binaryTarget、パッケージ作成者は、Package.swiftここでプリコンパイルされた XCFramework を宣言します。ユーザーは引き続き、[ファイル] > [Swift パッケージ] > [パッケージの依存関係の追加] を使用してウェアハウスとバージョンを追加します。 Xcode はバイナリ製品をダウンロードし、チェックサムを検証してから、モジュールをアプリ コードに公開します。

このセッションでは、クローズド ソース フレームワークを Swift パッケージ配布モデルに組み込むことに焦点を当てます。作成者が取得するのは、ウェアハウス、バージョン制約、HTTPS アーティファクト、およびチェックサムで構成されるリリース契約です。ユーザーが取得するのは、基本的にソース コード パッケージと同じ統合エントリです。

詳細

バイナリパッケージの依存関係を使用する

(01:01) スピーチはユーザー側から始まります。開発者は、Xcode で [ファイル] > [Swift パッケージ] > [パッケージ依存関係の追加] を選択し、BinaryEmoji パッケージのバージョン 1.0 を選択して、バイナリ依存関係をアプリにリンクします。 [参照バイナリ] グループがプロジェクト ナビゲーションに表示され、XCFramework が含まれます。

(02:37) 同じ依存関係をパッケージ マニフェストに記述することもできます。公式コード スニペットは、通常のパッケージの依存関係を記述する方法を示しています。

// swift-tools-version:5.3

import PackageDescription

let package = Package(
    name: "package",
    products: [
        .library(
            name: "package",
            targets: ["package"]),
    ],
    dependencies: [
        .package(url: "https://github.com/JohnnyAppleseed2020/BinaryEmoji", from: "1.0.0"),
    ],
    targets: [
        .target(
            name: "package",
            dependencies: ["Emoji"]),
    ]
)

キーポイント:

  • // swift-tools-version:5.3このマニフェストが Xcode 12 に対応する SwiftPM 機能を使用することを示します。 -.package(url:from:)このバイナリ フレームワークを配布するパッケージ リポジトリを指定し、最小バージョンを設定します。 -.target(... dependencies: ["Emoji"])現在のターゲットをインポート可能にするEmojiモジュール。
  • ユーザーはバイナリ フレームワークのソース コードを見ることはできませんが、モジュールのインポート、ジャンプ定義、および SwiftUI プレビューの更新のためのエントリ ポイントは、ソース コード パッケージの場合と同じです。

binaryTarget を使用して XCFramework を配布する

(03:04) 作成者側の主要な API は新しいターゲット タイプですbinaryTarget。その名前は XCFramework のモジュール名に対応しており、リモート配布には HTTPS URL とチェックサムが必要です。

// swift-tools-version:5.3

import PackageDescription

let package = Package(
    name: "Emoji",
    products: [
        .library(name: "Emoji", targets: ["Emoji"])
    ],
    dependencies: [
    ],
    targets: [
        .binaryTarget(
            name: "Emoji",
            url: "https://example.com/Emoji/Emoji-1.0.0.xcframework.zip",
            checksum: "6d988a1a27418674b4d7c31732f6d60e60734ceb11a0ce9b54d1871918d9c194"
        )
    ]
)

キーポイント:

  • .library(name:targets:)バンドルEmojiターゲットはパッケージ製品としてクライアントに公開されます。 -.binaryTarget(name:url:checksum:)このターゲットが縮小された XCFramework から取得されることを宣言します。 -urlHTTPS である必要があり、ウェアハウス履歴に大きなバイナリ ファイルが書き込まれるのを避けるために、ダウンロード アクションは Git チェックアウトから独立しています。 -checksumこれはマニフェストの整合性制約です。 Xcode は、アーティファクトをダウンロードした後、再計算して比較します。
  • 逐語的には、パスベースのバイナリ ターゲットについても言及しています。これは開発段階で使用され、パッケージ内の XCFramework ファイルを指すことができます。

チェックサムは出版契約の一部です

(05:43) チェックサムは SwiftPM コマンドによって計算されます。作成者はまず XCFramework を zip 圧縮し、次にこの zip に対してコマンドを実行しました。

swift package compute-checksum Emoji-1.0.0.xcframework.zip

キーポイント:

  • コマンドで出力された値がコピーされます。Package.swiftのchecksum分野。
  • クライアントがパッケージを使用すると、Xcode はダウンロードされたファイルのチェックサムを再計算します。
  • チェックサムが一致しない場合、クライアントがマニフェストと矛盾するバイナリ ファイルを取得するのを防ぐために、Xcode はダウンロード結果を拒否します。
  • アーティファクト ファイル名のバージョン番号は、パッケージのリリース リズムと一致する必要があります。逐語的なドラフトでは、バイナリ ターゲットもセマンティック バージョニングに準拠することが推奨されています。

XCFramework は依然として基礎となる形式です

（06:16）binaryTarget配布されているのはXCFrameworkです。逐語的なドラフトでは、XCFramework には複数のプラットフォーム バリアントを含めることができ、フレームワーク、動的ライブラリ、静的ライブラリをサポートし、各 XCFramework には 1 つのモジュールのみが含まれることが強調されています。

XCFramework の作成プロセスはここでのみ要約されています。フレームワークまたはライブラリ ターゲットで配布用のビルド ライブラリを開き、各バリアントを個別にアーカイブしてから、xcodebuild -create-xcframeworkマージ。講演者は、より完全な作成とバージョンの進化の詳細について、WWDC 2019 の「Swift のバイナリ フレームワーク」を指摘しました。

(07:00) 最後の選択も非常に実用的です。バイナリの依存関係により、デバッグがより困難になります。ユーザーはソース コードを直接変更することはできず、作成者がすでにサポートしているプラ​​ットフォームのみを使用できます。クローズドソースの SDK を Swift パッケージに組み込んだ後、依存関係の管理はよりスムーズになりますが、サードパーティのコンポーネントを評価する責任がなくなるわけではありません。

重要ポイント

  • 内容: クローズド ソース SDK を配布用の Swift パッケージに変換します。 実行する価値がある理由: Xcode 12 のサポート.binaryTarget、ユーザーはパッケージの依存関係を通じてプリコンパイルされた XCFramework を取得できます。 開始方法: まず、物流のみを担当するパッケージ倉庫を準備します。Package.swiftでのステートメント.library製品と.binaryTarget(name:url:checksum:)。

  • 内容: 内部チーム向けにプライベート バイナリ コンポーネントをリリースします。 実行する価値がある理由: HTTPS アーティファクトは Git チェックアウトの外部でダウンロードされるため、大きなファイルによってパッケージ リポジトリの履歴が汚染されることはありません。 開始方法: 圧縮された XCFramework を会社がアクセスできる HTTPS アドレスに配置し、チェックサムを計算し、パッケージ タグを成果物のバージョンと照合します。

  • 何をすべきか: バイナリ SDK のアップグレード ルールを確立します。 実行する価値がある理由: 逐語的なドラフトでは、バイナリ ターゲットがソース ターゲットと同様にセマンティック バージョニングに従うこと、および破壊的な API 変更ではメジャー バージョンを上げる必要があることが明示的に推奨されています。 開始方法: パブリック API の変更、XCFramework バンドルのバージョン、およびパッケージ タグを同じリリース チェックリストに追加します。

  • 内容: バイナリ依存関係に統合の受け入れを追加します。 実行する価値がある理由: ユーザーはバイナリ ソース コードを変更できず、問題はアクセス境界で事前に発見される方が適しています。 開始方法: 新しいサンプル アプリまたはテスト パッケージを作成し、クライアント パスに従ってパッケージの依存関係を追加し、確認します。import、メイン API 呼び出し、およびターゲット プラットフォームが利用可能かどうか。

関連セッション

コメント

GitHub Issues · utterances