SwiftUI previews向けにAppを構成する

こんにちは WWDCへようこそ “SwiftUI previews向けに アプリケーションを構成する” Xcode previewsのケビンです Xcodeのプレビュー機能は SwiftUIコードを書く際や 一度に複数のビューを編集する時 変更を すばやくテストする時に 役立ちます しかしプレビューは アプリケーション 全体にも有益なものです よりプレビュー可能なアプリを構築すれば より分かりやすく テストや保守がしやすい アプリが作れます 今回はプレビューを最大限に活用するための ４つの方法をご紹介します まずは一度に複数のファイルを プレビューする方法です 大きなコンテクストで ビューの編集ができます 次にプレビューとSwiftUIアプリの ライフサイクルの関係に注目します プレビューのパフォーマンスを維持しながら 明示的なデータの依存関係を定義します それからサンプルデータを どこに定義すべきかを説明します デプロイされるアプリのサイズに影響を与えずに 開発中にサンプルデータを保持できます 最後にプレビュー可能なビューを作るための テクニックをお話しします 内容が盛りだくさんなので 早速 始めましょう すべてのデモで使用するのは 撮影した写真の コラージュを作成するアプリケーションです コラージュを作成してレイアウトを選んだり 写真の選択や友達の追加 他の写真アプリケーション同様に エフェクトの追加も可能です まずは一度に複数のファイルを プレビューする方法です

コラージュのレイアウトを選ぶための サムネイルのビューから始めます ここにグレーの長方形があり 白い背景上でよく見えています ただコンテクストを変えたらどうなるか セレクターに切り替えて レイアウトを選びます プレビューが２つ出ました １つ目は背景が白い場合の見え方で ２つ目は画像の上での見え方です これはコンテンツがズームされて セレクターの下にスライドした時の見え方です このようにサムネイルが見えなくなるので もう少し目立つ色にしたいと思います ただ色を編集する際に 実際に使うコンテクストは残しておきたいです

そこでボトムバーにあるボタンをクリックし プレビューをピン留めします ここで Layout Thumbnailビューに戻ると 今ピン留めしたビューのプレビューと 作業中ファイルのプレビューが表示されます プレビューの各セットがどこから来たか示す デバイダーも追加されます では色を編集しましょう 70%でもよくなりましたが 80%にするともっと見やすいようです Dark Modeではどうでしょうか？ “plus”ボタンをクリックしてプレビューを複製 プレビューを選びます

インスペクタを開き ダークアピアランスを選びます

グレーの色が少しそぐわないので Dark Mode用にカスタマイズします お薦めの方法は Assetカタログの アセットを使用することです

色を選択し 既に設定した色があるので ライブラリを開いて その色に行き グリッドプレースホルダーを選択します まだ何も変わっていないので Dark Mode用に色をカスタマイズします ここでもサムネイルを使用するコンテクストで 色を編集したいと思います そこでピン留めをレイアウトセレクターから Layout Thumbnailのプレビューに付け直します Assetカタログに行き 色を編集しましょう グレーを選択したらインスペクタを使い Dark Modeのカスタマイズを追加します そのカスタマイズを選択し 20%に変更します

Assetカタログを保存し プレビューをレジュームします Xcodeがアプリケーションをリビルドして コンテクストでの見え方を表示します いいですね

ピン留めの別の使用例です 開発中ずっとは必要ない 追加のプレビューを持ち込んでみます

追加のプレビューファイルにある 別のプレビューセットに移動します これは種類の違うアクセシビリティ レイアウトのプレビューです 異なるサイズに反応するよう ビューをカスタマイズしていないので 今はすべて同じサイズです プレビューのピン留めを外し アクセシビリティプレビューにピン留めします そしてサムネイルに戻ります

このサムネイルのサイズとスペーシングを サイズカテゴリに基づいてスケーリングできます Environmentを介して sizeCategoryを渡し ContentSizeCategoryにエクステンションを追加 適切なスケールを提供しました 必要がある場所を選択してスケールを使用し sizeCategory.scaleで拡大します それぞれのサイズカテゴリに基づいて うまく表示されました 引き続きプレビューを編集していくと 各サイズで変更がどう見えるかが確認できます

プレビューのピン留めの活用方法は３つです より大きなコンテクスト内での編集か Swift以外のファイル編集または 特定のタスクに必要な追加のプレビュー用です 次にプレビューとSwiftUIアプリケーションの ライフサイクルの関係についてです これはiOS 14とiPadOS 14で導入されました すべてのアプリケーションは起動時に 何らかの初期化を実行します ディスクからのドキュメントの読み込みか CloudKitとの接続やデバイスとの通信もあります 何であれ この作業には たいていコストがかかります プレビューの利点は プロジェクト内の小さく分かれたビューを編集し キャンバス上のそこへ直接行けることです プレビューではコストが高い初期化作業は 避けたいところです データの明示的な依存関係の定義という観点から これを考えることが重要です その作業はプレビューのためかどうかではなく その作業をいつ発生させたいかを 定義するのです SwiftUIアプリケーションのライフサイクルは この依存関係を定義するツールを提供します 仕組みを見てみましょう

ここに私のアプリケーション タイプの定義があります プロパティとして 私のネットワークモデルを定義しました 私のアプリケーションが作成される度に 私のモデルが作成されます プレビューで実行している際に アプリケーションが何をしているのか見るため プレビューにデバッガをアタッチします “再生”ボタンを長押しして “Debug Preview”を選びます

どのプレビューにもデバッガをアタッチでき その利点は２つあります １つは設定したブレークポイントがヒットしたら その原因をデバッグすることができます または アプリケーションが何をしているのかを デバッグゲージを使用し確認することができます デバッグゲージを開くと アプリケーションは 起動時に多くの作業を実行しています CPU上とネットワークで 大量のデータを引き出しています データモデルを初期化しているからです プレビューではこの作業は必要ありません そこでSwiftUIのStateObjectの プロパティラッパーを利用します

プレビューをポーズして @StateObjectを プロパティに追加しましょう これでアプリケーションが 最初に 作成された時だけデータモデルが初期化され データモデル内のいかなる変更にも SwiftUIが反応できるようになります またプレビューではStateObjectを使用して 作成されるモデルは初期化されません アプリケーションの実行が必要な時にだけ 作業を実行すればよいのです

ではプレビューをレジュームしましょう

もう一度デバッグを開始します

CPUが今どこかを確認しましょう ずっとよくなっています CPU上でもネットワークでも 不要な作業は実行されていません

StateObjectを使って 必要な時だけデータを初期化する例でした StateObjectの詳細については “App Essentials in SwiftUI”をご覧ください データモデルを初期化せずにどうやって データをプレビューに取り込むのでしょうか？ ２つのパートで見ていきます まずはプレビューのサンプルデータを どこに定義するかです

私たちのコラージュエディタは 写真アプリケーションなので 開発中には多くの例を使って エフェクトやレイアウトの確認がしたいです そこでAssetカタログを定義し プレビューで参照できる画像を 多数追加しました ただ これらの画像は 最終版の アプリケーションには入れたくありません そこでXcodeの開発アセットを活用します

プロジェクトエディタに切り替えて 下までスクロールすると Development Assetsというセクションがあります 開発アセットは ファイルまたはフォルダへのパスで Xcodeは アプリケーションの 開発バージョンにだけ そのパスを含めます Xcodeテンプレートから SwiftUIアプリケーションを作成していれば アプリケーションには開発アセットのパスが 事前設定されています これがそうですね ただ このように 自分でも簡単に追加できます また追加のターゲットにも追加可能です Mosaic Kitフレームワークに切り替えて “プラス”ボタンをクリック “preview content”と入れれば アプリケーションの開発バージョンにだけ 追加のプレビューコンテンツが入ります 開発アセットはAssetカタログのような ファイルだけでなくコードにも適用されます 今追加したプレビューコンテンツ フォルダの中を見てみましょう

ナビゲーターを見ると Swiftファイルが２つあります アプリケーションの開発やデバッグのテストに のみ必要なコードが含まれていて アプリケーションが実際にデプロイされる時には 不要なファイルです プレビューアセットやリソース コードを どこに定義すべきかをお見せしました それでは 実際どうやってデータを プレビューに取り込むのか？ そのためにビュー自体を プレビュー可能な形にします そして よりプレビュー可能なアプリケーションを 構築する利点はここにあります

大きな概念から始めます アプリケーションを独自なものにするのは ユーザー体験です しかし独自のユーザー体験の背景には 一意的なデータモデルがあります これをリッチデータタイプと呼びます Core Dataからの場合もありますし CloudKitまたはカスタムの場合もあります しかし最終的なアプリケーションとの やり取りにはシンプルデータタイプが使われます テキスト項目の文字列や Toggleのブーリアンかもしれません その間にすべてのビューがあり リッチデータタイプを シンプルデータタイプに変換します 問題はビューの階層のどこで この変換を行うべきかです 一般的な経験則として このタイプの変換が 行われるのが早ければ早いほど 再利用しやすく テストが簡単で よりプレビュー 可能なアプリケーションになります ここでの大きなインセンティブは プレビューの追加を簡単にして すべての構成でアプリケーションを テストできるようにすることです よりプレビュー可能なビューの構築方法として ４つの例を見ていきます １つ目は不変のシンプルデータタイプを 値を変更する必要がないビューに渡す例です ２つ目はSwiftUIバインディングを使って 値の変更が必要なビューであるインスペクタに シンプルデータタイプを渡す例です ３つ目ではジェネリクスを使って データの抽象化をビューに渡し それを他のビューに渡せるようにします そして最後はエンバイロメントを使って インプットをビューに渡す例です まず最初の例では 不変のシンプルデータタイプをセルに渡して コラージュのコラボレータを 追加してみます 初めにコラボレータの裏にある データモデルから見ます colorやlastContribution Dateのような シンプルタイプもありますが モデルの大部分はCKUserIdentityで バッキングされています ではセルを見てみましょう

セルはコラボレータをインプットとして ObservedObjectとして受け取ります プレビューを作成します

セルの次にコラボレータを作成します CKUserIdentityに 入力するところまできたら CKデータベースでフェッチ操作を 作成する必要があります しかしCloudKitのデータモデルは ここまでのデモの中でオフにしました このビューではフルモデルは必要ないので 別の方法を検討してみます この考え方は非常に重要です 作成中のUIやモデルを考察し モデルを介してビューに渡す必要がある 最小限のデータ量を特定するのです

コラボレータセルの 別の例を見てみましょう

このセルではnameとimageとconnection statusを 個別の簡易なインプットとして渡しています このプレビューを作成するのは とても簡単です コラボレータセルを作成します ここはnameを取り込みます “Jane Doe”にしましょう

imageには今は空の画像を渡します そしてステータスです まずはonlineで始めます これだけでセルのプレビューができました このセルの複数の構成も 非常に簡単に作成できます このプレビューを何回か複製します

その１つをofflineにします 画像を追加するために Assetカタログをオープンして画像を選びます またテキストのサイズが 適切に調整されるかを確認します ミドルネームを長くしてみましょう

このようにシンプルデータタイプを インプットとして 複数の構成が簡単に作れます しかしデータタイプを シンプルにし過ぎることがあります これはアプリケーション内でユーザーが 使用しているロケールに基づいて システムに値を フォーマットする場合に起きます 例えば日付や今回のケースでは名前です そこで名前の文字列を渡す代わりに PersonNameComponentsを渡します これでSwiftUIにこの名前のテキストを 適切な時にフォーマットするよう伝えられます formatterを定義したり

そのformatterを テキスト内に渡すのも簡単です 最後にプレビューを更新し ネームコンポーネントを作成してみましょう

static文字列の各インスタンスを選択し

PersonNameComponentsを作成する コールで置き換えます プレビューをリフレッシュします PersonNameComponentsの１つを 作成するだけで 必要なすべての構成が 簡単にできるのです

例えば ミドルネームでもできます “Really Long Middle”と入れましょう

どのプレビューもバッチリです 複数の構成を確認できます そこで可能ならビューへのインプットは シンプルな不変のデータタイプにしたいでしょう しかし 値を変更しなければ ならないこともあります そこで２つ目の例では SwiftUIバインディングを使って ビューが変更可能な シンプルデータタイプを渡します

このインスペクタでは画像のslotデータを ObservedObjectとして渡します スロットはコラージュの 写真の１枚を表します ImageSlotデータタイプを見てみましょう

シンプルタイプがいくつかありますが 核はバッキングされたClockKitレコードです 前出の例のように レコードを作成するためには ClockKitの完全なデータモデルを すべて取り込む必要があります プレビューの作成を簡単にしたいので 前のデモと同じ考え方を適用します UIを考察して UIが編集を必要とするものだけを選ぶのです インスペクタを別のバージョンに 切り替えましょう

この場合 SlotEffectsのための バインディングを渡しています フィルターごとにいくつかの浮動小数点値を持つ 非常にシンプルなタイプです プレビューの作成は実に簡単です インスペクタを作成して エフェクトを渡してみます ここでは定数バインディングを使っています このビューではバインディングを 変更できないということです 実際にテストしたいのでバインディングの値を 変更できる例を追加してみます これをプレビューで行うために 中間ビューを作成し バインディングとしてビューに渡すことができる ステートを保存します

ビューを定義します

そして新たなプレビューを定義して 新しいビューを作成 エフェクトを渡します これらのエフェクトはステートとして保存され インスペクタがバインディングとして渡します

プレビューをレジュームして ライブで取り込みます するとキャンバス内で やり取りすることができます さらに 写真の置き換えを可能にするボタンを 追加したいと思います 画像スロットデータタイプ全体を このビューに渡し すべての置き換えロジックを ここで実行もできます しかし実施方法は クライアントに決めていただきたいです そこで代わりに ボタンを押すと 呼び出されるクロージャを渡します

クロージャをインプットとして追加し ボタンを追加しましょう

これはreplacePhotoHandlerを呼び出す 簡易なボタンです 次にプレビューを更新して コールバックに値を提供しましょう

１つ目では単に空のクロージャを渡しますが ２つ目では実際にボタンが機能しているか 確認したいです そこでコールバックにエフェクトだけを変更させ 確認ができるようにします

プレビューをレジュームします

ボタンをクリックすると サチュレーションが下がるのが分かります

しかしプレビューで すばらしいのは キャンバス上だけではなく オンデバイスプレビューを使うことで 複数の場所でやり取りすることができる点です ここにあるDark ModeのiPhone XRに 同じプレビューを出したいと思います “デバイス”ボタンをクリックして iPhone XRを選びます

Xcodeがプレビューを デバイス上にミラーリングします するとデバイスで プレビューと完全にやり取りできます Xcode 12やiOS 14やiPadOS 14では オンデバイスプレビューで 変更内容がシームレスにデバイスに反映されます Xcode 12で初めて オンデバイスプレビューを使用すると ホーム画面に Xcode Previewsというアイコンが現れます このアイコンをタップすると 最後に見たプレビューに戻れます スマートフォンと Xcodeとの接続が切られていてもです 変更を実施し それをプレビューに入れて 同僚に見せる際に非常に役立ちます 以上がバインディングを使った場合です インプットとして シンプルデータタイプを使いながら ビューがそれに変更を加えることを 許可できます ただし あるビューから別のビューへ よりリッチなデータタイプを渡す場合もあります ３番目の例では ジェネリクスを使って データをコラージュの メインエディタに渡します まず コラージュのモデルが どう見えるかを示すよう切り替えます

他の例と同じくCloudKit CKShareレコードで バッキングされています 他の例と同様に フルデータモデルが必要になります コラージュモデルオブジェクトを作成し プレビューに渡すためです 前のデモと同じ方法で バインディングを使って データを渡すことが可能です

コラージュのエディタに切り替えます シンプルタイプであるnameとlayout slotデータに バインディングを取り込みます プレビューを作成しましょう

ここでは 定数バインディングを使って nameとlayoutを提供します slotデータに関し 気づいたことがあります 前のデモで使用したリッチデータタイプを まだ使っていたのです このままでは 各プレビューの データを渡す際の妨げになります バインディングを使っていても 実際に必要なデータを渡せません 一歩戻って 他のデモと同じ方法を試してみましょう 作成しているUIが モデルから必要とする 最小限のデータ量を考えます この例では 厳密に必要なものを 抽象化するためにプロトコルを定義します

Collage Protocolという抽象化を見てみます これは コラージュがUIで編集可能になるために 必要なものを定義します nameやlayout そしてslotデータがありますが そのslotデータは抽象化でもあります コラージュ内の各slotには imagePublisherが必要です なぜならそのデータは クラウドから非同期に提供されたか 既にディスク上にあるか エラー状態の可能性があるからです このようなエフェクトもあります コラージュプロトコルができたので 作成が簡単なモデルの Design Timeバージョンを定義できます フレームワークの ここのプレビューコンテンツで行いました DesignTimeCollageには nameやlayoutそれにslotsがあります DesignTimeSlotsを使っており それにはpublisherとエフェクトがあります モデルのDesign Timeバージョンを渡すことを 可能にするエディタをご紹介します

ここのエディタに切り替えます このコラージュのエディタは ２つの点で汎用的です まずCollageTypeに関して汎用的であり 先程ご紹介したCollageProtocolに準拠します またImagePickerTypeにおいても汎用的です Design Timeに対して よりシンプルなUIを定義することが可能となり テストのたびに写真のライブラリに行く代わりに コラージュの写真を選ぶことができます

コラージュエディタのプレビュー作成が いかに簡単かお伝えします

コラージュエディタを呼び出すと ２つのインプットが取り込まれます まずはコラージュです DesignTimeCollageを実行すると いくつかのインプットを取り込みます nameを取り込み“My Collage”とします layoutを取り込み twoByTwoで始めます slotsデータも取り込み ここでは単に空のデータを渡します

また makingPhotoPickerを作成するために クロージャも取り込みます このPhoto Pickerの Design Timeバージョンを作成しました 前に見たプレビューアセットカタログの 画像にアクセスして使用できます

これでコラージュエディタの プレビューができました 完全に機能しています しかし これはDesign Timeのより シンプルなデータモデルを使用しています ビューなので ビュー特有のモディファイアを追加できます 少しpaddingを足してみます

キャンバス内でコラージュエディタを テストすることができます “Play”ボタンをクリックすると slotをダブルタップして写真を選べます 別のレイアウトも選択できます DesignTimeslotデータの例を 渡すこともできます そこでアドレスも選べます アドレスはコラム内の行のようなものです するとDesignTimeImageSlotの例を 渡すことができます これはアセットカタログから画像を１つ取り 空のエフェクトに渡しているだけです すると それが２番目のコラムにあるか ２行目にある場合 または別の画像の場合に どう見えるのか確認できます エフェクトを渡すことも可能です 例えば50%でサチュレーションが どう見えるのかを確認できます

これはiPhoneでの見栄えはよいですが iPadではどうでしょう 最後の例のように このプレビューをデバイスに置きます On Deviceボタンを選択し “My iPad”を選びます iPadの横の設定でこのコラージュエディタが どう見えるか確認できます 私のキャンバスにあるバージョンのように これは完全にインタラクティブです ダブルタップして写真を選ぶと インスペクタを開いてエフェクトを追加できます CloudKitでバッキングされたデータモデルを 作成することなく データモデルのDesign Timeバージョンだけで コラージュエディタの全機能をテストできました ４番目に 他とは若干異なる例をご紹介します ビュー間の明示的なデータの 依存関係を定義するためには できれば ビュー上でインプットを定義すべきです しかし エンバイロメントを介して データを渡す方が便利なこともあります クラウドとの同期ステータスを表示するビューの プレビューを追加し プレビューとエンバイロメントの 関係を見てみましょう

CloudSyncViewに切り替えます

CloudSyncStatusViewは CloudSyncStatusを EnvironmentObjectの インプットとして取り込みます SwiftUIでは EnvironmentObjectがある時には 階層の上部でそのオブジェクトに 値を提供する必要があります インプットとしてEnvironmentObjectを取り込む ビューのプレビューを作成する時には 各プレビューに対して値の提供が必要です どう機能するか見てみましょう

CloudSyncStatusViewを作成します

そしてEnvironmentObjectモディファイアを アタッチします

CloudSyncStatusを作成すると クラウドがオンラインの時に 私のビューが どう見えるかのプレビューがあります 他の例と同じく エンバイロメント使用中は 簡単に 複数の構成を追加できます プレビューを複製します

今回は クラウドがオフラインの時に 起きることを渡します

クラウドがオフライン時のアイコンがあります それを再度複製し 最後に同期された時間が 正しく表示できるか確認します lastSyncを実行して 何時間か前を試してみましょう

最後に 基本を網羅したことを確認するため クラウドがオンラインの状態で つい最近同期した場合を見てみます

エンバイロメントを使って インプットをビューに渡す例があります 他の明示的なインプットと同じく よりシンプルなタイプを使用している時は プレビューの複数の構成を 作るのは本当に簡単です

最後の例では このビデオの内容すべてをまとめます では アプリケーションのルートビューに切り替えます

このルートビューは コラージュエディタと同様 ２つの点で汎用的です １つはCollageType つまりCollageProtocolです もう１つはImagePickerTypeです 中間ビューを定義しました そこに含まれる何らかのstateに 私たちが前に作成したDesignTimeCollageが 保存されています

それは RootViewの1つを作成し collagesをバインディングとして渡しています また“プラス”ボタンが押下された時の アクションコールバックもあり それによりDesignTimeCollageの１つが 作成できます DesignTimeCollageを作るのは簡単なので このクロージャの入力はシンプルです 最後に DesignTimePhotoPickerを 渡しています 実際にプレビューを使用する際は CloudSyncStatusで EnvironmentObjectをアタッチしています これで このキャンバス内に完全なバージョンの アプリケーションができました “Play”ボタンを押します 新たなコラージュを追加するために “プラス”ボタンを押し 異なるレイアウトを選ぶことができます 写真を選んだり 戻ったり スワイプして削除したりすることも可能です また このビューにライブで 変更を実施することもできます プレビューをピン留めします サムネイルを やや大きくしたいと思います そのために Collage Listに切り替えます コラージュとタイトルのサムネイルを表示する コラージュラベルに行きます この値に行き それをもう少し大きい値に変更します これはちょっと大きすぎました 30に戻しましょう いいですね

iPhoneでの見栄えはいいですが iPhoneのダークアピアレンスや iPadではどう見えるでしょうか 一度に複数のオンデバイスプレビューを 見ることができます オンデバイスプレビューボタンを押し iPhoneとiPadの両方のデバイスを選択します Xcodeがすべてのデバイス上に アプリケーションの完全なバージョンを置きます キャンバス内では 追加したりスワイプして削除したりできます iPhoneではポートレートに行って 異なるレイアウトを選べます よくなりましたね 戻ります iPadでは コラージュと写真を選択し エフェクトを開くことができます

そしてアプリケーションを全く実行せずに すべての機能をテストできます 編集を行うと それが同時に すべてのデバイスに反映されます この30を選択し それを90に変更します すると サムネイルが見えるかを 確認できます プレビューがいかに強力か ご理解いただけたと思います データの抽象化を定義する際や 複数のプレビューや 複数のコンテクストを使って アプリケーションを実行することなく すべての 構成をテストする際に便利です よりプレビュー可能なビューを構築するには ４つの方法があります ここまで 多くのことをご紹介しました 最初は より大きなコンテクストで ビューの編集ができるよう 一度に複数のファイルを プレビューする方法をご紹介しました ２番目に プレビューとSwiftUIアプリケーション のライフサイクルとの関係に注目し StateObjectを使って 必要な時だけデータを初期化しました ３番目に どこでサンプルデータを 定義すべきか説明し 開発アセットを使用することで リリース製品に それを入れない方法をご紹介しました 最後に ビュー自体をよりプレビュー可能にする ４つの方法を確認しました

皆さんに１つの大きなアイデアを託します アプリケーションをよりプレビュー可能に することはすべてに恩恵を与えてくれます このビデオで プレビュー可能な アプリケーションは理解しやすくテストが簡単で メンテナンスもしやすいものだと ご理解いただけたと思います さあ すばらしいアプリケーションを作りましょう