Swiftパッケージを作成する

(音楽)

(拍手) Xcodeチームのボリスです Xcodeのサポートは ご存じのようですが このCreating Swift Packagesでは 自分で作る方法を学びます

主に話す項目は５つです ローカルパッケージの作り方 公開の方法

パッケージマニフェストAPIの話 編集の方法 オープンソースプロジェクトについても お話をします

既にAdopting Swift Packagesを 開催しました 関連情報があるので そちらもご覧ください 例えばパッケージの問題を 解決する方法や― パッケージの基本を 詳しく説明しています ご存じなければ ぜひ

オープンソースコミュニティや ワークスペースでコードを共有する際に パッケージが役立つのです

まずローカルパッケージの作り方です

サブプロジェクトと同様に プラットフォーム非依存なので―

どのAppleのプラットフォームでも そのままコードを使えます

そしてコードを再利用できます

バージョン名の割り当てはなく 準備が整えば簡単に公開できます

では ローカルパッケージの 作り方を実演しましょう ランチメニューが見られる アプリケーションを例にします iOS用とwatchOS用の 両バージョンがあり Target Membershipで データモデルを共有しています これではアプリケーション開発の際に 少し面倒なので― リファクタリングして ローカルパッケージにしたい 初めに“File”の“New”から “Swift Package”を選択

パッケージ名は“food and stuff”

既存のプロジェクトとルートグループに 追加したら“Create”をクリック READMEのマニフェストファイル ソース そしてテストを含む― 基本的な構成が Xcodeによって作成されます

アプリケーションからパッケージへ データモデルのコードを移動して―

アプリケーションにリンクしたい パッケージ構成が書かれた マニフェストファイルにあるのは― アプリケーションにリンクできる ライブラリを定義したプロダクトです マニフェストとプロダクトの詳細は 後ほど触れるので― プロジェクトエディタに切り替えます iOS用のターゲットを開いて― フレームワークや ライブラリなどのセクションへ “Plus”をクリックしたら “food and stuff”を選択します watchOS用も同様の手順です ターゲットから 同じセクションへ行き “Plus”をクリックして プロダクトにリンクさせます

パッケージには １つ以上のモジュールがあるので アプリケーションに読み込みます この例では１つですが iOS用のコードに―

モジュールを読み込みます watchOS用も同様です

ワークスペースを大きく変えたので 画面が静止しました “command”と“option”と “Ｐ”を同時に押すと―

アプリケーションが 元どおりに作動します ほんの数ステップで― 再利用できるコードを リファクタリングしました プラットフォームの設定は不要だと 気づいたかもしれません プラットフォーム非依存の パッケージだからです ニーズに応じてビルドします この例ではiOS用と watchOS用なので― 両OS用に２回 プロダクトをビルドします すべてXcodeによる自動処理です パッケージ公開に向けて 出だしは順調ですが スライドに戻って もう少し説明します

ローカルパッケージについて学んだので 公開して共有する方法に移りましょう 具体的な手順を見る前に 知らなければいけないのは Swiftパッケージの セマンティックバージョニングです

Swiftパッケージは 確実に有益なバグ修正をするために セマンティックバージョニングに 従います 各バージョン番号には 特定の意味が割り当てられていて メジャーバージョンは APIの互換性がない変更を示します クライアントのアップデートが必要です この例では既存のタイプのままか― メソッドの移動か シグネチャの変更でしょう しかし非互換性や 重大な動作変更があるかもしれません

マイナーバージョンのアップデートでは 後方互換性を維持しつつ メソッドなど機能IDが追加されます

後方互換性のあるバグ修正には パッチバージョンを上げます この時 クライアントは メンテナンスの負荷を負いません

開発初期段階の際は メジャーバージョンを０とします マイナーとパッチの段階で 破壊的な変更もありえます 開発作業は簡素化されますが 共有するには1.0のリリースが必要です

パッケージを公開したら APIは安定的なものになります クライアントのテスト用として 最終版をリリースする前に プレリリースバージョンを使います

その際にはバージョン番号に プレリリースの識別子を追加します この例ではbeta.1を最後につけました

ただしプレリリースだと示しても まだアップデートしています この場合はbeta.6です バージョン５をリリースしたあとは 自動的に選択されるので テスト後は識別子の削除が必要です

では 公開までの手順を お伝えしましょう

先ほどの画面に戻ります

まずパッケージをドラッグして プロジェクトの外へ

オプションをホールドしたいので コピーを作成します プロジェクトを閉じてから これを開き― パッケージをダブルクリック プロジェクトのように スタンドアロンで開かれます “The run destination”を見てみると iOS用とwatchOS用の開発ですが MacとtvOSもあります 再度 強調しますが プラットフォーム非依存なので パッケージのビルドに 特別な設定は必要ありません 公開するのでREADMEを書き直します

“このパッケージが 供給するのは―”

“フードメニューをJSONから 読み込むためのデータモデルである”

実際のパッケージでは もっと情報を充実させたいですね 例えば 使い方や― APIがプラットフォーム依存なら プラットフォームの条件 ライセンス情報も加えたいですが デモ版なので十分です 続いて テストを加えます Xcodeがテストケースを 作成していますが 実際にテストをしましょう

フードアイテムを作成し

“チキン”と入力

値段は42ドルです

そして妥当な値段であることを 主張しましょう “command”と“Ｕ”を押すと パッケージがビルドされ 実際と同じように動作します テストが成功したので まずはリポジトリを作成しましょう “Source Control”を開き “Create Git Repositories”を選択

Xcodeがパッケージを選択済みなので “Create”をクリック ローカルリポジトリが作成され コミットします GitHubにもリポジトリが必要ですが 同様にXcodeで作成できます リポジトリのコンテキストメニューから “Create Remote”を選択しましょう

GitHubのアカウントは Xcodeで設定済みなので 自動的に選ばれています 名前の変更やオプションの記述は とりあえず無視します ひとまずチーム内だけで共有したいので 表示は非公開にして―

“Create”をクリック

Xcodeがパッケージと GitHub上にリポジトリを作成し 現在の状態をプッシュします

パッケージを公開しましたが 初版も公開したいので コンテキストメニューに戻って “Tag Master”を選択します

バージョン1.0.0をリリースしますが メッセージは空欄にします 作成されたローカルタグを GitHubにプッシュするため “Source Control”から “Push”を選択します “Include Tags”にチェックを入れ “Push”をクリックしてください

GitHub上に公開されたので 見てみましょう コンテキストメニューから “View on GitHub”を選択すると

この画面が開きます ここで終了でもいいのですが 最後に リモートバージョンを アプリケーションに再統合したい “Clone or download”をクリックして ここへURLをコピーします SafariとXcode そしてFinderを閉じて― XcodeのWelcome画面に戻り 再びランチのプロジェクトを開きます

“File”から “Swift Packages”のサブメニューへ

この作業用の選択肢の中から―

“Add Package Dependency”を選びます

ここへURLをコピー

Xcodeが推奨するデフォルトのRulesに バージョン1.0.0が含まれているので “Next”をクリック

パッケージが解析され 選ばれたプロダクトが出ます iOS用のアプリケーションに リンクしたいので“Finish”をクリック

ここで１つ忘れていたのは ローカルパッケージの削除です ゴミ箱へ移動してください

リモートバージョンを取得しています

このプロジェクトナビゲータの 依存関係のセクションでは 依存関係をすべて見られます

既にプロダクトを― iOS用のアプリケーションに リンク済みだからです watchOS用のアプリケーションにも 追加するために― “Frameworks, Libraries, and Embedded Content”に戻ります “+”をクリックして プロダクトを選んでください

ここでプレビューに戻って 画面を再開したら―

元どおりに動作します 数ステップで パッケージを公開できました スライドに戻ります

次は 同僚のアンキットが― パッケージマニフェストAPIについて ご説明します

どうも　ボリス ボリスはXcodeプロジェクト内の ローカルパッケージの使い方と 公開して共有する方法を 紹介しました ここではパッケージの設定に使用する パッケージマニフェストAPIを学びます

Swiftパッケージには Package.swiftが含まれていて １行目は必ず swift-tools-versionsです これはビルドを要求された 最小限のSwiftコンパイラですが 詳細は後ほど学びます

２行目はimportステートメントです APIを含むXcodeが このライブラリを供給します

最下段は初期化ステートメントです このステートメントを使うと パッケージは初期化されます この例ではパッケージ名が そのままターゲットになります

ターゲットの標準レイアウトがあり Sourcesの下の各ターゲットに それぞれサブディレクトリがあります

これらは初期化するセクションで 宣言されます 標準レイアウトがあるので ソースファイルを列挙せずに済みます 正しいディレクトリにドロップすれば 自動的に拾われます ターゲットを追加するには― サブディレクトリを作って マニフェストファイルで宣言します

Testsの下のテストターゲットにも 個別にサブディレクトリがあります

通常 テストターゲットは 別のターゲットをテストしているので 依存関係を宣言しなければいけません それには依存するパラメータを使います

最後に プロダクトを 宣言する必要があります プロダクトはターゲットを エクスポートするのに使われます この例では １つのターゲットを エクスポートしています

Swiftパッケージの設定方法に続き 今度はサポートを追加する方法を 見ていきましょう

MenuDownloaderは― 他のパッケージ管理システムと 一緒に使っています

ここにはSwiftターゲットと レガシーＣコードがあり Xcodeのプロジェクトファイルと podspecファイルもあります

ではPackage.swiftを追加して ターゲットを設定する準備をしましょう

レガシーＣコードから始めますが まず名前とカスタムのパスを設定します このターゲットは 標準設定にないので必要な作業です ランチメニューをダウンロードする マクロのif definedもあるので― Ｃコードで定義します

Swiftターゲットも同様に カスタムのパスを設定して Ｃコードのターゲットへの 依存関係を宣言します

２つのプロダクトがあり それぞれ Swiftターゲットと Ｃコードのターゲットをエクスポート 別々にエクスポートするのは― Ｃコードのターゲットを 直接 使用するユーザのためで Swift Bridgeが不要になるのです

ハイライトを入れたライブラリを 読み込むユーザもいます

次はパッケージの依存関係を 設定する方法です

依存関係のセクションを 構成する要素は２つ

ソースURLとバージョン要件です このバージョン要件では upToNextMajorを使用 メジャーバージョン２から始まる yamsのバージョンが必要であり セマンティックバージョニングに従って バージョン３に上がるということです バージョン要件の宣言には upToNextMajorを推奨します なぜなら 次のメジャーバージョンの 最小バージョンを指定できますし パッケージ技術の衝突を避ける 柔軟性も十分だからです

fromと略すこともできます

version-based要件は 他にもあります fromとupToNextMajorは見ました upToNextMinorは 次のマイナーコンポーネントに バージョン要件を宣言できます 変更に保守的なら これが便利です

exactバージョン要件は 特定のバージョンへの依存を 固定できます ただし衝突を誘発する恐れがあるため 必要でないかぎり推奨しません

version-basedではない要件もあります

branchは 複数のパッケージを開発して 衝突なしで保つのに役立ちます

revisionは 特定のリビジョンへの 依存を固定するのに便利です どちらの要件も 公開されるパッケージには使えません 公開前にbranchとrevisionを すべて削除してください

依存関係を選択したら １つ以上のプロダクトへの依存関係を 宣言する必要があります ここではyamsに依存することを 宣言しています

swift-tools-versionに戻りましょう 先ほども述べたように 必ずマニフェストの１行目にあります パッケージの記述も 他のAPIと同じく徐々に発展し ライブラリのバージョンは ツールのバージョンから得られます

それは依存関係の解決にも関係します Xcodeは すべての 依存パッケージにおいて ツールのバージョンの 互換性を保証します

最後に パッケージをビルドする― Swiftコンパイラの 最小バージョンを宣言します これによって古いバージョンの 互換性を診断する時に いい結果を期待できます

ボリスの言うようにSwiftパッケージは プラットフォーム非依存です もしパッケージに プラットフォーム特有のコードがあれば 条件つきの合成関数を使えます

サポートの可用性については Xcodeが Deployment Targetを割り当てます

Deployment Targetは 初期化するセクションで カスタマイズできます プラットフォームを制限せずに パッケージをビルドでき― カスタマイズするだけです

この例では Mapworksを10.15に iOSを13にカスタマイズしています 現行バージョンのDeployment Targetで 望むものがない場合― Stringを使用できます

どのパッケージマニフェストAPIにも 詳細なドキュメントがあり Generated Module Interfaceで 確認できます “command”を押しながら “import”の “Package Description”をクリック では パッケージの編集については ボリスがご説明します 以上です (拍手)

ありがとう　アンキット

パッケージを公開したら アプリケーションのコンテキスト内で 作業する必要があるでしょう 先ほどの実演では しかるべき場所で パッケージを編集しました １つは ワークスペースの一部として ビルドされたローカルパッケージ もう１つは スタンドアロンですが いずれも編集可能です しかしパッケージの依存関係は Xcodeによってロックされています

“food and stuff”のパッケージも そのままの状態でした それをローカルパッケージのように プロジェクトに追加したら 既存の依存関係をオーバーライドします

LastPassのコンポーネントに基づくため ローカルパッケージは― リモートの依存関係を オーバーライドします ローカルパッケージは いつでも編集可能なので アプリケーションとパッケージを 一緒に編集できます

では実演してみましょう

先ほどの画面に戻ります

Swiftパッケージの 依存関係のセクションには 依存パッケージが追加されています 既に以前のパッケージから チェックアウトしてあるので プロジェクトへドラッグします

依存関係のセクションが消えるのは リモートの依存関係を もう使用しないからです

ユーザの要望は アプリケーションで 食べられる料理なのか分かることです ベジタリアンフードかどうかを 表示したいのですが― 幸いにも既に情報はあります

その情報が見えるように データモデルを変更する必要があります パッケージの “food item type”を開いたら プロパティを追加

名前を“vegetarian”にして―

初期化するセクションに 引数としてコピーします 最後に このプロパティを―

初期値に設定します ベジタリアンフードなのか データモデルに情報が入りました ユーザへの通知を UIに追加しましょう iOS用のアプリケーションの コードへ行きます プロジェクトナビゲータを隠し スペースを広げて― プレビューで確認しながら進めます “Jump Bar”を使って フードアイテムの画面へ

エディタにあるUIのコードは ハイライトの部分が TableViewの各セルを表しています

フードアイテム名を用いたラベルを 計算するスニペットを用意しましたが ベジタリアンフードかどうかを表す 絵文字を追加します テキストフィールドで このラベルを使い―

プレビューを再開します

各料理がベジタリアンフードかどうか はっきり表示されています このようにアプリケーションと パッケージを一緒に編集できます

スライドに戻りましょう

オーバーライドは 自分が所有しないパッケージでも バグの修正や変更などの編集に使えます

最後に Swift Package Managerの オープンソースプロジェクトの話です 略してSwiftPMは 公開されて数年ですが Xcodeのサポートの ベースになっています

SwiftPMはクロスプラットフォームで 構築されたシステムなので クライアントとServer側で コードを共有できます

そして４つのコマンドラインツールで 構成されています swift buildはパッケージをビルド swift runはプロダクトを実行 swift testはテストを実行 最後のswift packageは ビルドされてないオペレーションの実行 これらを使って macOSとLinuxの 両方でパッケージをビルドできます

SwiftPMのコマンドラインツールと 今後の展開に関する詳細は― WWDC2018の Getting to Know Swift Package Managerをご覧ください もちろん xcodebuildも パッケージのビルドに使えます これもiOS用 watchOS用 tvOS用に コマンドラインでビルドする方法です サポートのベースとなる libSwiftPMというライブラリは オープンソースプロジェクトの一環です Swiftパッケージと 他のデベロッパツールを― サポートするのに使えます コミュニティの協力には わくわくします

一例としてSourceKit-LSPは SwiftとＣコードをベースとした言語の Language Server Protocolの実装です このLSPは エディタやIDEと― オートコンプリートのような Language Serverの間で プロトコルを定義します SourceKit-LSPを使う時に IDEはエディタとして 言語の機能を取得します ベースはlibSwiftPMです

Swift Package Managerは オープンソースプロジェクトの一環です Swift.orgでは コミュニティと プロセスについて学べます Package Managerは Swift Evolutionのプロセスに従います 誰でも機能の開発や 大きな変更ができます

提案する前に Package Managerの フォーラムに立ち寄って 会話から役立つ考えや意見を 見つけてください

現在 サポートしているのは ソースコードとユニットテストのみです コミュニティと協力して― 他のリソースへのサポートも 強化していきたい

皆さんは 既にある草案をフォローし 影響を与えることができます

また定期的にアップデートしているので ご自身で最新の変更を試せます オープンソースプロジェクトの更新は 将来のXcodeの一端を担うでしょう

現在 パッケージはプラットフォームと Xcodeでサポートしています 再利用できるコードを捜して リファクタリングしてください Swiftパッケージの エコシステムを広めたい

パッケージの選び方や作り方について まだラボが２つあります そちらのSwift Packages Labも お勧めです

残りの日程も お楽しみください (拍手)