SwiftUIの基礎：SwiftUIで優れたアプリを構築

こんにちは やったー！そう、楽しいよね。

こんにちは、クパチーノにある Appleデベロッパセンターへようこそ。 私の名前はリア・ウォメルスドルフです。 テクノロジーのエバンジェリストをしています。

本日はSwiftUIの基礎をご紹介できることを 嬉しく思います。 取り上げるべき内容はたくさんあります。 まずは、会場についてもう 少し詳しくご紹介したいと思います。

デベロッパセンターはApple Parkの 一部です そして、ここは今日のイベントに 最適な会場です。 そこには、交流や 協働のための様々なエリアがある。

この部屋はビッグサーという名前で、 素晴らしい設備が整った美しい空間です。 これは、以下のようなさまざまな活動を サポートするように設計されています。 対面でのプレゼンテーション、 スタジオ録音、生放送。

実験室やブリーフィングルームもあります。 そして、このような活動をはじめ、 その他多くの活動を開催できる 会議室も備えています。

ここは、世界中に4つある デベロッパセンターの1つで、 デザイナーたちが集まる場所です。 そして、セッション、ラボ、 ワークショップの開発者。 ここにいる方で、既にデベロッパセンターに 行ったことがある方はいますか？ いいですね。おかえりなさい。 新規の方も、再来の方も、 本日は皆様をお迎えできて大変嬉しく思います。

現在、オンラインで参加してくださっている 方もたくさんいらっしゃいます。 こんにちは。ご視聴ありがとうございます。 弊社のデベロッパリレーションズチームは、 皆様との交流を大切にしています。 開発者と協力して、Appleプラットフォーム向けに 最高のアプリを開発します。

WWDC以降、ラボ、ワークショップ、 そしてプレゼンテーション。

今週後半、ここクパチーノで、 私のチームは、新しいデザインに 関するワークショップを主導しています。 開発者はLiquid Glassの 実践的な経験を積むことができます コードやデザインを更新するにつれて。

お近くで開催されるイベントの詳細については、 デベロッパをチェックしてください。 今日の議題に入る前に、 この部屋にいる皆さんにいくつか アドバイスをしたいと思います

一日を通して繋がりを保つため。 Apple Wi-Fi ネットワークを使用し、 いつでも充電する必要がある場合は、 どの座席にも電源が備わっています。 本日ご視聴いただいている皆様のために、 肘掛けの前に設置されています。 これらのプレゼンテーションは、 あなただけの特別な体験となることを 意図しています。 オンラインと対面の両方で。 動画撮影はご遠慮ください。 または、プレゼンテーション中の ライブストリーミング配信。

一方、写真撮影は大歓迎ですので、 お好きなだけお撮りください。

イベント終了後、関連資料を含む フォローアップ情報をお送りします。 見逃さないようにチェックしてください。

その小さなお願いは済ませたので、 今日のイベントについて、 もっと詳しくお伝えできるのが楽しみです。

SwiftUIは、Appleが 開発した 宣言型ユーザーインターフェースフレームワークです。

他のツールと同様に、SwiftUIにも 基礎となる概念があります。 これらの概念を学ぶ時間を取ることで、 それをうまく活用できるようになります。 そして、何か素晴らしいものを作り上げる。

SwiftUIを使用すると、 最終的な結果は単なるアプリではなく、 これは、あらゆるApple製ハードウェアで 快適に動作するアプリです。 初めて使う人でも直感的に 操作でき、馴染みやすい。

SwiftUIアプリは最新の アップデートに対応し、 常に最新の状態を維持できます。 オペレーティングシステムへ。 Liquid Glassのように、 SwiftUIはApple社内で 新しいアプリの基盤として広く利用されている。 そして、UIKitから始まった 既存アプリの進化。

段階的な導入を最優先に考えて構築された。 そうすることで、コードベースに 徐々に組み込むことができます。

今こそ、時間をかけることが重要です SwiftUIの基礎を学ぶ。

コードの書き方はたくさんあります。 行単位で処理する場合でも、LLMや エージェントを利用する場合でも同様です。 基礎を理解することで、そして、 自分のコードに対する自信を高めましょう。

私たちのチームは新しいアプリ「Wishlist」 の開発に取り組んでいます。 これは 100% SwiftUIで 作成されています。

今日のプレゼンテーションはすべて、 ウィッシュリストを基盤としています。 SwiftUIの基礎がどのように 組み合わさって実際のアプリが 作られるのかを示すため。

私とチームメイトは旅行が大好きです。 そして、次の休暇の計画を立てるのがとても 楽しいんです。

旅行を最大限に楽しむために、 綿密に計画を立てるのが好きなんです。 私が行く場所だけでなく、 そこで私がすることも含めて。

Wishlistは旅行の バケットリストアプリです。

私たちは行きたい場所を追跡するためにこの アプリを作りました。 私たちがやりたい活動、 そして、自らの進捗状況を振り 返り、責任を果たす。 大きな夢を持ち、新しいことに挑戦する。

アプリには、旅行とアクティビティという 2種類の主要なデータがあります。

旅行とは、ハワイのコナなど、 私が行きたい場所のことです。

そしてアクティビティとは、 私が旅行中にやりたいことです。 シュノーケリングやホエールウォッチングなど。

このアプリには主に3つの機能があります。 ツールバーのプラスボタンをタップすると、 タイトル、写真、時期を追加することで、 新しい旅行を計画できます。

旅行中は、リストにある アクティビティをチェックできます。 マンタと一緒に シュノーケリングをするようなものです。 自分の進歩を振り返ることもできます。 例えば、この秋、 私はモンタナ州へ旅行しました。 そして、これらの体験をナビゲートするために、 私は秋の探検家バッジを獲得しました。 ウィッシュリストはタブビューを使用します。

一貫性のあるナビゲーションを実現するため、 タブビューを選択しました。 私の同僚のマヨがこれらの決定事項の 一部を説明します。 彼女のデザインプレゼンテーションの中で。 ウィッシュリストタブには3つの タブがあります。 下にスクロールすると、 計画済みの旅行をすべて閲覧したり、 新しい旅行を追加したりできます。

Kona Deep Diveのような カードをタップすると、 旅行の詳細ページに移動し、 そこで項目にチェックを入れることができます。

目標タブは、私が賞の獲得に 向けての進捗状況を確認する場所です。 一番上の段には、私が最近受賞した賞、 例えば「秋の探検家賞」 などが表示されています。

スクロールダウンすると、次の目標達成に 向けた進捗状況が確認できた。 私はすでに7つのアクティビティを 完了しました。 あと3つで、10種類のアクティビティを 達成した賞を獲得できるんです。

3番目のタブは検索タブです。

私は探しているものを素早く 見つけるために検索機能を使います。 すでにたくさんの旅行を追加済みです。 自分が本当に欲しいものを検索して、 じっくりと掘り下げることが できるのは本当に便利です。

アプリの開発方法については、 同僚が詳しく説明します。 しかし、おそらくもっと重要なのは、 それぞれの決定を下すための 基礎となる概念である。

これらの基礎知識こそが、 今日あなたが持ち帰るべき最も重要なものです。 この理論を自分のコードに適用してみましょう そうすれば、自信を持ってそれについて 考えることができるでしょう。 ウィッシュリストを作るのはとても 楽しかったです。 アイデア出しからデザインまで、あらゆる段階で そして実際にこのアプリで 構築することで、状況が整う 本日の残りのプレゼンテーションについて。 今後数週間以内に、ウィッシュリストの サンプルコードが利用可能になります。 当社のウェブサイトから ダウンロードしてください。 本当にワクワクしています。 これは、学習内容を理解し、 定着させるための素晴らしい方法です。 サンプルやSwiftUI全般について 質問がある場合は、 Slidoを使えば、Appleのエンジニアに 質問することができます。

私たちのチームは 喜んであなたをサポートします。

サンプルに関する質問や、 SwiftUIに関する質問など、 何でもお気軽にお尋ねください。

他の開発者からの質問に賛成票を投じたり、 回答を読んだりすることもできます。 これは学習に役立つ素晴らしいリソースなので、 ぜひチェックしてみてください。

よし。それでは、議題に入りましょう。

本日のプレゼンテーションでは、 SwiftUIの基礎的な トピックを取り上げます。

これは本当に重要なことです。 基礎は、あなたが 始めたばかりであっても役立ちます または、あなたは既に経験があります そして、その枠組みに対する 理解を深めたいと考えています。

たとえあなたがすでにSwiftUIに 精通しているとしても、 基礎をより深く理解することは、 より良い実装戦略を選択するそして、 アプリ内で彼らの問題を解決します。

まずはSwiftUIの概要から始めましょう。

その後、MajoがSwiftUIがどのように システムを使ったデザインを可能にするかについて 解説します。

その後、少し休憩を取り、 太平洋標準時11時15分に再集合します。

次に、CatがSwiftUIのレイアウトシステムについて 案内してくれます。

カートは続いて、SwiftUIのテクニックを 解説する動画を公開する予定です。 アニメーションおよび視覚効果用。

その後、昼食休憩を取り、 軽食をとってリフレッシュしましょう。 130パシフィックでまた会いましょう。 コールがあなたの意図をどのように 表現するかを実演します。 SwiftUIで意図を持って データをモデル化しましょう。

そして、特別なゲストをお迎えします。 ジェームズ・グラハム。AllTrailsの CTOが重要な教訓を共有します。 SwiftUIを段階的に 採用していく彼らの道のりについて 複雑で成熟したUIKitアプリ。

もう一度休憩して、ストレッチをして コーヒーを飲みましょう。そして最後は、 SwiftUIエンジニアリングのリーダーたちによる パネルディスカッションで締めくくります。 彼らは今日寄せられた 最もよくある質問のいくつかに答えます。 そして、ここクパチーノの人々のための枠組みに 関する彼らのビジョンを共有する。 その後、軽食をご用意した懇親会を行います。 さらに、Appleのエンジニアや デザイナーと交流する機会も得られます。

それでは、まずはSwiftUIの基本に 関するプレゼンテーションから始めましょう。

私はリアです。テクノロジーの 伝道師をしています。 エバンジェリズムチームに加わる前は、 ここAppleで エンジニアとして働いていました。

私はお気に入りのアプリ、 フィットネスアプリ、ワークアウトアプリの 開発に取り組みました。 そしてヘルスケアアプリも手がけましたし、 2021年の基調講演にも 少しだけ出演しました。 これってかなりクールだよね？ 撮影はすごく楽しかった。 Apple Parkを走り 回ることができました。 私がAppleに入社したのは2019年で、 それはSwiftUIが 発表された年と同じ年でした。

長年にわたり、フレームワークについて、 その使い方について、 しかし、もっと重要なのは、 それをいかにうまく使うかということだ。 私が初めてSwiftUIを使い始めたとき、 プロトタイプを素早く 作成できる点が気に入りました。 そして、数行のコードでアプリに 実際の機能的な機能を構築します。 私は何か現実のものを作り出すことができる。 それは素晴らしかった。

これは多くのソフトウェアエンジニアが 経験することです。 ツールやフレームワークに関係なく。 画面に何かが映るのはすごくワクワクする。 しかし、必ずしも 期待通りにはいかないこともある。 だから、一度立ち止まって 基本に立ち返る必要があったんです。

SwiftUIの仕組みを理解する必要があった そうすれば、より高品質なソフトウェアを 作ることができる。

今日は、SwiftUIの仕組みの中核となる 概念についてお話しします。

これらの概念は、より良い コードを書くのに役立ちます。 そして、それらは本日の残りのプレゼンテーションの 導入部分となるでしょう。

まず、SwiftUIのビューでよく 使われる用語を詳しく見ていきましょう。

次に、SwiftUIに組み 込まれているビューについて説明します。

そして、新しいカスタムビューを 作成する際のロジック。

最後に、依存関係と、意図を持って コードを構成する方法について説明します。

各セクションでは、それぞれの最も 重要な概念について説明します。 そして、それらが執筆というより大きな枠組みの 中でどのように関連しているのか。 素晴らしいSwiftUIコードです。 わかりました。SwiftUISwiftUI、 「view」という用語は多義的な用語です。 文脈によって、3つの異なる 意味を持つ可能性がある。 そして、これは少し紛らわしいかもしれません。

多くのフレームワークにおいて、 「ビュー」とはユーザーインターフェースと 画面上のピクセルを指します。

SwiftUIでは、ビューは プロトコルでもある。 それは、画面に表示させたい内容の説明です。

各ビューは構造体であるため、 ビューの各インスタンスは特定の値を持つ。

これら3つの概念はすべて関連している。 画面上のピクセルは、ビューの説明の結果です。 そして、その特定のビュー構造体の実際の値。

景色の説明そして、 それを制御する値が、 画面上の最終的なピクセル値となる。

「ビュー」という言葉のこれら3つの意味は、 アプリのさまざまな場面で登場します。

説明文はコードそのものです。

その値はメモリ内のインスタンスです。 SwiftUI はピクセルを レンダリングできます。 そして画面上のピクセルは最新の情報を表示する 必要があります。最も正確な情報。

これから、それぞれの「視点」 の意味について詳しく見ていきます。 私のプレゼンテーション。

文脈が重要そして、それはあなた 自身のSwiftUIコードにおける 問題点を深く考えるのに役立ちます。

まずは、説明としての「見解」 から始めましょう。

SwiftUIでは、 ビューは、それらを構築するための 意図的な方法を示す記述です。

シュノーケリングをしているクールな水中シーンの 画像が欲しいとしましょう。

英語で。これを説明するには、 私は「水中でシュノーケリングをしている イメージ」というフレーズを書きます。

SwiftUIでは、ビュープロトコルを 使用してこの説明を作成します。

ImageはSwiftUIビューであり、 Deep Seaは画像の名前です。

まさに私の英語のフレーズと同じです。 SwiftUI。 SwiftUIで 何を実現したいかを説明します。

SwiftUI はビューを受け取り、 このように画面に何を表示するかを決定します。 素敵な写真ですね。

SwiftUIのビューはすべて、 コードで記述された説明文です。

これは、それらが組み込みビューであるかどうかに 関わらず当てはまります。 または、自分で作成したカスタムビュー。

この画像は、SwiftUIに 組み込まれているビューの一例です。

ビューはすべてのアプリの構成要素であり、 そして、内蔵されているビューは、 始めるのに最適な方法です。 SwiftUIには多くの組み 込みビューがあります。 そして、それぞれの名前はそれが 何を生み出すかを表している。

例えば、画像が画像を視覚化するのと同様に、

色は、フレーム全体を特定の色で 満たすビューです。 紫色が好き。

組み込みビューは、SwiftUIが ハードウェアと統合しているため、 非常に強力です。

ここでいう紫色は、実際には 文脈によって変化する紫色です。

実際の色値はデバイスのコンテキストに 基づいて調整されます。 例えば、電話がライトモードかダークモードか、 あるいは、画面に太陽の光が 強く当たっているかどうか。

テキストは「Kona Deep Dive」 のような文字列を視覚化します。

色と同様に、テキストの表示も、 それが存在する場所のコンテキストに 合わせて最適化されます。

SwiftUIは適切なフォントを 使用して文字列を描画します 現在のプラットフォーム向け。 iMacのような大型ディスプレイの場合、 テキストビューは、小さいものよりも 物理的に大きくなります。 Apple Watchのように。 テキストビューは、 アクセシビリティ機能であるダイナミックタイプも サポートしています。

ダイナミックタイプを使用すると、 デバイス上の表示テキストの サイズを調整できます。 そうすれば、彼らは快適に読むことができる。

こちらでは、右側のスマートフォンの方が システムフォントサイズが大きい。

私のSwiftUIコード内の テキストビューは自動的に スケーリングされます内容がまだ読めるように、 そして、これは私の側で 追加のコードを書く必要は一切ありません。

各ビュー、画像、色、テキストについて、 ビューの名前は私が望むものの説明です。

ディープシー、パープル、コナディープダイブの 価値観を組み合わせたもの。 それらは画面上のピクセルとして現れる。

造り付けの眺望は素晴らしい出発点です なぜなら、それらはそのまま使えるだけでなく、 カスタマイズも可能だからです。

ビューをカスタマイズすることで、 アプリ独自の個性を表現できます。 SwiftUIに組み 込まれているビューの利点を活用しながら。

SwiftUIでビューをカスタマイズする 方法はいくつかあります。

以前作成したTextViewは 悪くはないのですが、 もっと印象に残るように改良できます。

ビュー修飾子は、個々のビューをカスタマイズするための ツールです。 これからコードをいくつか見ていきます。

テキストビューをカスタマイズする 方法は数多くあります。 例えば、フォントのサイズや 色を変更するなどです。 それは、私たちが ウィッシュリストアプリでよくやっていたことです。 まずは簡単なことから始めましょう。 テキストビューを明るい色を背景にして、 視覚的に際立たせたい。

背景修飾子は、ビューの背景を設定します。 背景画像として任意の画像を指定できます。 私はオレンジ色を選びました。

背景はビュー修飾子の一例です。

ビュー修飾子は、テキストなどの特定のビューに 対して呼び出されるメソッドです。 そして、元のビューを含む 新しいビューを返します。

元のテキスト ビューは、 ビュー修飾子からの変更でラップされています。 そしてそれは新たな視点を生み出す。 ビュー修飾子は、ビューを囲む ラッパーのようなものだと考えています。

これら2行のコードを組み合わせると、 元の文字列「Kona Deep Dive」が生成されます。 オレンジ色の背景。

これは、元のテキスト表示を 少し修正したバージョンです。

複数のビュー修飾子を適用することで、 複合的なカスタム効果を作成できます。

パディングもビュー修飾子の一つです。 これは、適用先のビューの端に点を追加します。 この場合、パディングはテキストビューの 四辺すべてにポイントを追加します。 そしてオレンジ色の背景がそれを埋め尽くす 背景のパディングがそれより 前のすべてを包み込むのと同じように。 つまり、これら３行のコードはすべて １つの大きなビューを表している。 ビュー階層内。

ビュー修飾キーに関する最後の注意点です。 順番は重要です。 各ビュー修飾子は、その上のコード行のみに 影響を与えます。

背景が先に表示されるように 順番を入れ替えたら。 オレンジ色は元のテキスト表示部分のみを 覆います。

灰色の点線で囲まれた部分は、 残りの部分に適用されます。

ビュー修飾キーの順序は意図的に決めましょう。 コードが期待どおりに動作しない場合は、 ビューが適切な順序で ラップされていることを確認してください。

ビュー修飾子は個々のビューを カスタマイズしますが、 構図とは、複数の視点を組み 合わせる技法である。

既存のビューを組み合わせることで、 独自のカスタムビューを作成できます。

例えば、これらの列の1つを 構築したいとしましょう。 ウィッシュリストの検索タブで 「Kona Deep Dive」 を検索してください。 以前作成した組み込み ビューの一部を使用できます。

まず、ビューSearchRowを定義します。

これは構造体であり、 ビュープロトコルに準拠しています。

次に、ビューの本体を追加します。 これはすべてのビューに必須のものです。

そして、深海の画像も追加します。 そして、「Kona

Deep Dive」 と表示される私の TextView。

デフォルトでは、SwiftUIはそれらを 垂直に積み重ねます。

私は彼らを並べて置きたい、 そこで、画像とテキストのような水平スタック、 つまりHスタックを追加します。 HStack はビューです。

しかし、画像のようにレンダリングするものを 説明する代わりに、これは、 SwiftUIスタックをどのようにレンダリングするかを 説明しています。 画像やテキストなどのサブビューをすべて 水平方向に並べます。

本日後半、キャットは ツールについてさらに詳しく解説します。 レイアウトとSwiftUIのテクニック。 より洗練された見解を述べるにあたり、 一つ指摘しておきたいことがあります。 基本的な考え方は同じです。

私の検索行は、私が求めているものの説明です。 そしてSwiftUIはその記述を基に、 画面上にピクセルを描画します。

構成によりコードが読みやすくなります。

SearchRow を作成したら、 たった1行のコードで、 アプリの他の部分でも利用できます。

私の検索ビューでは、 3 つのスタック、3 つの画像ではなく、 そして、3つのテキスト表示モード。 複合検索行ビューを3つ使用しました。

そして後で何か変更したい 場合SearchRow の背景を 紫色にするなど、 そのビューの範囲内であれば、 ローカルで実行できます。 これにより、私が書く 必要のあるコードの量が減少します。 そして、読みやすく、理解しやすくなる。

ビューは構造体だからです。 軽量なので、このように 小さなビューに分割しても、 パフォーマンスに悪影響はありません。

組み込みビューと同様に、 カスタムビューは、私たちが 説明する内容の説明です。 SwiftUIは画面上に描画するべきである。 SearchItemViewのような名前は 重要です。 しかし、それ以上に重要なのは、 そして、それらがリストされている順序。 SwiftUIは説明を使用します 画面上にピクセルを描画するための コードを作成します。

さて、これをさらに一歩進めたいと思います。 私のSearchRowは 意図したデザインにかなり近いのですが、 完全には完成していません。

現在、私は Kona Deep Dive のインスタンスを 3 つ持っていますが、皆さんはどうでしょうか。 でも、私は毎年休暇の過ごし 方を変えるのが好きなんです。 アプリは動的であり、 変化するデータを表します。

やりたいことリストにある他の旅行も 表示できるように、何か方法を変えたいんです。

これで最後の話題に移ります。 依存関係。

SwiftUIのビューは データに基づいて動作します。 そのデータが同じままかどうか、 深海のイメージと弦楽器のコナ・ ディープ・ダイブのようにあるいは、 データが変更される可能性もある。

本日ご紹介した見解はすべて データに基づいています。

画面上のピクセルは、 画像のような説明の結果の一部です そして、ディープシーのようなデータの一部。

先ほど、すべてのビューは 構造体であると述べました。 つまり、すべてのビューは値型であり、 ビューのすべてのインスタンスには 値があります。

私は、ビューの名前を使って、 このようなビューのインスタンスを 視覚化するのが好きです。 上部には画像のような表示があり、 下部には深海のようなデータが表示されます。

SwiftUI は特定のビューの インスタンスを受け取り、 画面上にピクセルを描画するための データも含まれます。

ピクセルがレンダリングされると、 SwiftUI はそのインスタンスを 破棄します。 もう必要ない。

これが「view」の3つ目の意味です。 価値としての見解。

ビューのインスタンス。これらの特定の値が、 画面上のピクセルを決定します。

各ビューインスタンスは一時的に存在する。 それらは短命です。それらは作られます 必要なときにSwiftUIの メモリ内に配置される。 そしてピクセルがレンダリングされると、 ビューの役割が完了すると、 インスタンスは破棄されます。

それらを捨てることは、 悪いことでも重大なことでもありません。 ビューは軽量で、簡単に作成できます。

ビューはテンプレートのようなもので、 同じものを繰り返し 生成できるものだと考えています。 画面上にピクセルを生成する。 これらのテンプレートは、多くの場合、 柔軟性と動性を備えたデータを表しています。

例えば、私のアプリでは 深海に焦点を当てています。 でも、京都の写真ももう一枚欲しいんです。

これはビューの別の例です。 しかし、こちらは 少し違った価値を持っています。 京都の画像名は深海とは異なります。

SwiftUIは、異なる値を持つこれらの イメージビューを受け取ります。 画像名が異なるため、 異なる画像が生成されます。

それでは、この柔軟性を活かして、 SearchRowのコードを 見直してみましょう。

画像名とテキスト名をハードコーディングする 代わりに、 私のSearchRowは 画像の名前を引数として受け取ります そして旅行のタイトル。

このバージョンのSearchRowは、 より柔軟性があります。 私はまだそれを使ってコナ・ディープ・ダイブ・ ロウを作ることができます。 でも、他の旅行にも使えるよ。 これで、実際のデザインにさらに 近づくことができる。 検索ビューで新しい SearchRow を使用すると、

私は様々な画像をすべて提供します そして、マンモス・ブラッシュや京都ミスティークといった 旅行名も。

そして、これははるかに良い。

データが画面上のピクセルを動かしている。 そして、私は今でもコンポジションから 得られるクリーンなコードを活用できています。

検索ビューのこの実装はまだWishlistに 掲載されている最終版を簡略化したものです。

実際の検索では、データが動的に検索されます。 そして画像に基づいて 検索行を埋める検索フィールドに 入力された文字列。

これらの検索行について、 もう一つ強調しておきたい点があります。

以前の画像ビューと同様に、 SearchRow の各インスタンスは、 旅行名と写真名に記載されています。

SwiftUIはこれらを簡単に比較し、 等しくないことを検出できます。

SwiftUIが画面上に ピクセルを描画した後、 ビューのインスタンスを解放します。 ピクセルがレンダリングされたので、 もうそれらは必要ありません。

それでは、SwiftUIが 依存関係をどのように扱うかについて、 もう少し詳しく説明したいと思います。

私のSearchRowの 説明は、ビューコードです。

ビューの値が異なると、 画面上のピクセル数も異なります。

SwiftUI は依存関係のある 重要な値を追跡します。 そして重要な価値観とは、データに基づいて、 ピクセルが正しいか 間違っているかが判断できる。

仕組みはこうです。

SwiftUI が初めて body を実行すると、 読み取ったすべての値をグラフで記録します。

このグラフの最初の部分は、 SearchRow のノードです。

本文内で、 SwiftUI は 画像ビューの写真名の値を読み取ります。

つまり、写真名のノードと、 SearchRowを指す 下向きの矢印が追加されるということです。

SwiftUI は Trip name の値も読み取ります。 そのため、SwiftUIに旅行名のノードと 矢印が追加され、これを追跡します ピクセルが正しいためには、 写真名と旅行名を正しく 表示する必要があります。

それらのいずれかが変更された場合。 例えば、新しい写真名を 次のように指定した場合。 私はこの赤い点で表しています。 そうすると、SearchRow の ピクセルが古くなってしまう。 そしてSwiftUIは 新しいものを描画する必要があるだろう。 依存関係は、ビューの入力のようなものです。

依存関係の追跡は、SwiftUIが アップデート作業が非常に 効率的です。

閲覧数とデータ量が多いアプリの場合。 何かが変わるたびに、 SwiftUIはすべてを再描画する 必要がありました。

アプリ内のデータは頻繁に変更されます そして、これは多くの不必要なアップデートを 引き起こすだろう。

その代わりに、SwiftUIは 依存関係を追跡します。

ここでは矢印で表しています。 そして、どのビューが特定のデータに 依存しているかを示します。

このシステムでは、何かが変わると、 SwiftUIは、下流の処理のみを 再計算および再描画します。

依存関係の追跡により、変化が速い状況でも SwiftUIの効率性を維持できます。 そして多くの場合、あなたのアプリの中にも。 これは高度な技術であり、 素晴らしいニュースです。 このグラフを自分で作成する必要はありません。

SwiftUIは、依存関係グラフの 中でそれを自動的に構築します。

各ビューが本文を実行するたびに 読み取るプロパティを追跡します。

このシステムはグラフを常に 最新の状態に保ちます。

このグラフを作成したり 維持したりする必要はありません。 コードを作成するにあたって、 まだいくつか注意すべき点があります。

景観を構築する際は、 景観を明るく保ちましょう。 SwiftUIにボディに必要な情報として 伝えた内容を検討してください。 そして、それらの見解に対する変更が、 見解全体を無効にするべきかどうか。

ビューは最小限の依存関係で 軽量に保つのが最善です。 そのため、SwiftUIは 重要な場合にのみそれらを再描画します。

これは、複雑なビューを作成できないという 意味ではありません。

つまり、複雑なビューをより小さなビューに 分解する必要があるということです。 先ほど検索ビューの行で行ったような、 もっとシンプルな部分です。

データを表現するには適切なツールを使用し、 変更点を伝える方法のみ 画面上のピクセルを変更すべきタイミング。 ビューがデータに 依存する方法はいくつかあります。 一つの方法は、先ほど私がやったように、 そのデータをビューに直接渡すことです。 画像や旅行の具体的な名前を 提供することによって。

データを作成するもう1つの方法は、 状態を使用することです。

私の同僚のコールが 州についてさらに詳しく説明します そして彼のプレゼンテーションにおける データフローの他のオプションのそれぞれ、 しかし、基本的な事項については 説明しておきたいと思います。

状態によってラップされたプロパティ。 SwiftUIにその情報を 保存するように指示する 眺望の全寿命にわたって。

それは、ビューがビュー階層に 存在する全期間を指します。 簡単な例で説明しましょう。

Wishlist の検索タブで、 検索バーに文字を入力し始めると、 結果は下層に伝わる。

文字 J を追加すると、 最新のアイテムは私の旅行記に 置き換えられました ハイキング、ジョシュアツリーなどの 検索文字列を含むアクティビティ、 そして崖からの飛び込み。

さらに文字「O」を追加すると、 結果はさらに絞り込まれていきます。

アプリに追加した旅行やアクティビティの中で、 Joshua Tree は、文字列 j o を含む唯一のアイテムです。

アプリの状態。入力した文字列検索フィールドに 入力された文字が、検索結果と 画面上のピクセルを決定します。

状態がどのように機能するかを示すために、 簡略化された例を作成します。

これは検索ビューの簡略版です。 私はこれを「シンプル検索」と呼んでいます。

実際の検索ビューの中核機能を備えており、 しかし、デザインにはいくつかの 簡略化が加えられている。 本体には2つのビューしかありません。 テキストフィールドとテキストビューを 使用しています。

テキストビューは、ここに「結果」と表示される 単なるプレースホルダーです。 これは私がプロトタイプ開発中に 頻繁に行うことです。 仮のプレースホルダーを入れました。 いずれ差し替えます。 検索結果を表示する カスタムビューを備えています。

TextFieldは、SwiftUIに 組み込まれているビューの一つです。 これは意見を収集するためのものです。 人々がそれをタップすると、 キーボードが開き、 入力した文字列が表示されます。

ここでは開始プロンプトタイプを提供します。 そして、入力された文字列を保存するように SwiftUIに指示します。 「検索値」という名前の変数に格納されます。

ドル記号はバインディングの構文です。 これは、コールが後ほど詳しく 説明する別のデータフローツールです。

プロパティ検索値を、At状態プロパティラッパーで 装飾しました。

これは、 SwiftUIに対して、 更新後も検索値を保持するように 指示するものです。

初期値は空の文字列です。

テキストフィールドをタップすると、 カーソルが点滅し、入力できることを示します。

私が文字 J をタイプすると、 検索値の値が空文字列から j SwiftUIに変更されます。 その値を保持しておけば、 それに応じてSimpleSearchの ピクセルを更新できます。

同じことが起こる ジョシュアツリーに向かってフィルタリングを 続けるために文字Oを追加すると、 SwiftUIホールド検索文字列joの 値へそのため、 アップデートを通じて 継続的に進歩することができます。

状態とは、保持すべき情報をモデル化する 最もシンプルな方法です。 視聴期間全体にわたって。

検索タブを開いている間ずっと、 私の検索値は保持されるので、 引き続き追加していくことができます。

タブから移動して後で戻ってきた場合、 値は空の文字列から再び開始されます。

これは、ウィッシュリストに 本格的な検索ビューを構築するための 第一歩にすぎません。 次に、プレースホルダーのテキストビューを 旅行情報に置き換える必要があります。 検索値の文字列に一致するアクティビティ。

今のところは、国家のこれらの側面に 焦点を当ててください。

state はSwiftUIの プロパティ ラッパーです。

物件にマークが付けられている場合。 状態 8 では、SwiftUIは、 それが私のアプリの真の情報源であることを 認識しています。 そして、その価値は アップデート後も維持されます。

その光景は、その人が生き続ける限り、 記憶の中に残り続ける。

これは、アプリが動的で 複合的なデータを表示できることを意味します。 テキストフィールドに入力された 文字列のようなものです。

SwiftUIで依存関係を構造化する 方法には複数の方法があります。 コールは後ほど、それらそれぞれについて 詳しく説明するだろう。 今のところ、私が強調したいことは 一つだけです。時間を投資してください。 これらのツールがどのように機能するかを学ぶ。 こうすることで、依存関係が 正しく機能するように モデル化されていることを確認できます。 SwiftUIを使用。

本日説明したように、ビューは SwiftUIの構成要素です。 それらが使用されるさまざまな文脈についてより 深く理解することで、 枠組みだけでなく、しかし、 コードの品質を向上させましょう。

本日の残りのプレゼンテーションについて。 Wishlist のさまざまな領域を 探索すると、 これらの解決策の背後にある 理論に注目することをお勧めします。

こうすることで、得られた知見を自分の アプリ開発に活かすことができます。

私のプレゼンテーションから、 以下の点を念頭に置いておいてください。

SwiftUIに組み 込まれているビューを活用して、 独自のカスタムビューを作成しましょう。 アプリの独自性を表現するために、 さまざまな修飾語を検討してみましょう。

それらのビューを構築したり、 既存のビューを再検討したりすると、 表示内容は軽めに保つようにしてください。 各ビューが実際に依存すべき データを検討してください。 そして、複雑な視点をより 単純で小さな要素に分解する。

最後に、SwiftUIについて 学ぶ時間を確保しましょう。 これらの基礎を念頭に置くことで、 そうすることで、問題が発生した際に、 より適切に対処できるようになるでしょう。 ご参加いただき、 本当にありがとうございました。 さあ、次は同僚のマヨに 引き継ぐのが楽しみです。 彼女は、そのシステムを使ってWishlistをどのように 設計したかについて、 もっと詳しく説明してくれるでしょう。 マジョをステージに迎えるにあたり、 皆さんも一緒に盛大な拍手をお願いします。

皆さん、こんにちは。 お越しいただきありがとうございます。 あぁ。本当にごめんなさい。 コントロールの中に。 発表者のメモをもう少し大きくしてもらえません か？読めません。

チーム全員でお越しいただき、 ありがとうございました。 私たちはあなたとこのイベントのためだけに ウィッシュリストをデザインしました。 そして、そのプロセスがどのようにして実現したのかを 皆さんと共有できることを大変嬉しく思っています。 だから、うまくいけば、少しは、 私が長年にわたって 培ってきた学びやデザインプロセスを、 あなた自身のものにしてください。 それでは始めましょう。 アプリの操作方法から始めます。 これは、コンテンツを具体的に 区分けすることから始まります。 そして、あなたの機能。 私はそういう風に始めるのが好きなんです。 計画を始めるにあたっては、具体的に 何を作るのかを把握しておく必要がある。 ナビゲーションって、 まあ、ちょっと退屈な話題かもしれないけど、 個人的には大好きなんです。 それでは、まずそこから始めましょう。 次に、レイアウトについて説明します。 そして、画面上でコンテンツを提示する 最適な方法について話し合います。

そして最後に、ビジュアルデザインについて 詳しく見ていきましょう。 これは、コンポーネントと視覚要素が 組み合わさって明瞭さをもたらすものです。 アプリに個性を加える。

さて、先ほど申し上げたように、 このアプリは私がゼロから設計しました。 そして私が最初に考えたのは アプリのナビゲーションについてでした。

アプリのコンテンツと機能を決定する それは私に良い構造を与えてくれるでしょう。 明確に構築できるように、そして、 トップバーなどのナビゲーションコンポーネントの 使い方がわかるようになります。 そしてツールバー。

私はまずブレインストーミングを行い、 チームメンバー全員の意見を リストアップすることから 始めました。そして、 私はそのアプリにこうあってほしい、 こうあってほしいと願っていました。 私たちは目標達成を祝いたかったので、 どんなアイデアも歓迎しました。 私たちはブレインストーミングの 段階にいました。

デザイナーは、ほんの1分だけだと言った。 そこから、私は簡略化しました そして、旅行バケットリストアプリ （旅行作成など）に 必要な最低限のものだけを残しました。 写真を追加して、検索して、それから一歩引く 旅行やアクティビティ、 進捗状況など、関連する アイデアをまとめてグループ化します。 そして、旅行の成功を祝う。

これらのグループはアプリの上位3つの セクションを表しています。 そこで、それらを「ウィッシュリスト目標」 と「検索」と名付けました。

これが私たちのアプリです。 そして、これがあなたにとっての意味です。

新規に開発を始める場合でも、 既存のアプリを改修する場合でも。 この練習をすることは非常に有益です。 私は開発者センターの 開発者たちとそれをやってきました ワークショップに参加している間は、 いつもとても目から鱗が 落ちるような経験になります。 ですから、皆さんも 同じようにすることをお勧めします。 つまり、思考を整理するのに 役立つということです。 そして、ブレインストーミングで 思いついたこれらの自由なアイデアをすべて 形にしてみましょう。 これで、接続された 画面を構築できるようになります。

これら全てがSwiftUIとどのように 繋がるのかを説明します。 あなたがここにいるのはそのためだと 分かっています。 iOSではもうすぐ実現できそうです。 アプリのナビゲーションをサポートする コンポーネントは2つあります。 上部のバーとツールバー。

まず、上部のバーの仕組みをご説明します。

上部のバーには、アプリの最上位セクションが 表示されます。 そして、それはあらゆる 画面で表示されたままになります。

この例では、アプリが 実際よりも複雑に感じられることがある。 これらのアプリでは、機能が増えれば 増えるほど、できることも増える。 上部のバーがずっと気になるのですが、 あれを好まない人も多いようです。 非常に複雑になります。 だから私がいつもおすすめしているのは、 タブの数を少なくしておくことです。

シンプルさを保つのに役立ち、 非常に予測しやすい。 意思決定の手間を減らす。 だから、アプリを開くたびに、 どんなオプションが 利用できるのかが正確にわかるんです。

第二に、タブバーは ネイティブのままにしておきましょう。 これは今日のビンゴカードに入っていますか？

ご存知のように、 SwiftUIコンポーネントは、 タブバーにはアニメーションなどの組み 込み動作が付属しています そしてアクセシビリティサポート。 そのため、カスタマイズを行うと、こうした 特性が失われてしまう可能性があります。

でも心配しないで、 他にもたくさんの場所があるよ あなたのアプリでは、 あなたの個性を表現できます。 上部のバーは、そのどれにも当てはまりません。

最後に、上部のバーには分かりやすい 記号を使用するようにしてください。 そして、各タブの中身と一致するラベル。

ウィッシュリストには世界共通の シンボルはないですよね？ だから私は虹を選んだ。 それは今でも人々の記憶に残るものであり、 人々が憧れる旅を捉えている、そうでしょう？ 希望に満ちているように。

目標は、一方で、より 明確なシンボルを使用することです。 より明確で、ラベルに非常によく合致している。 そして、内部にある 多くの収集品と同じ形をしており、 それは素敵な心遣いだと思いました。

タブバーも同様に効果的です これらのガイドラインのいくつかに 従えば、同様に効率的です。

さて、ここでちょっと寄り道をします。 デザインやタブバーについてもう 少し詳しく知りたい場合は、

ヒューマンインターフェイスガイドラインを ご覧ください。 それは以前にもお伝えした通りです。 ハーグはデザイン指導の本拠地です そして、Appleのすべてのプラットフォームと テクノロジーにおけるベストプラクティス。

私たちにご相談いただく前に、 まずはご質問やアドバイスをお寄せください。 そしてついにハーグへのリンクが見つかります デベロッパウェブサイトの デザインセクションで、 そこには、非常に貴重なAppleの デザインリソースも含まれている。

Wishlistアプリのデザイン そして私がデザインした 他のほとんどすべてのアプリ 私は自分の生活の中で、 このライブラリのネイティブコンポーネントを 使用しています。

そしてあなたが閲覧している間 そして、 SF Symbolsアプリを ダウンロードしないことで、 デザインツールボックスを構築できます。 それは図像学におけるアップルサイダーだ。 7000以上のシンボルがあり、 それをコピーするだけで使用できます。 そして、デザインや コードに貼り付けてください。

これらは私がトップバーに使用しているもので、 今回が最後ではないでしょう。 今日、それについて調べてみます。 それでは、トークトラックに戻りましょう。 上部のバーとツールバーの両方で、アプリの ナビゲーションがサポートされています。 でも、違いはあるよね？ 彼らは異なるレベルで活動する。 ユーザーはアプリ内を移動する際に、 上部のバーを使用します。 トップレベルナビゲーションのことです。 しかし、行動を起こして 特定のセクションに入る時が来たら、 ツールバーを使用します。

ツールバーには、ナビゲーションをサポートするためのさまざまな 要素が含まれています。 まず、現在のビューのタイトルです。 この画面では、人々が見えます。

彼らは持っていることがわかる。 彼らはウィッシュリストに 入っている、ごめんなさい、 ウィッシュリストのセクションにあります。 そして、彼らは画面の内容に 関するある程度の背景情報も持っている。 いわば、全体の雰囲気を 決定づけるようなものだ。 そしてツールバーには コントロールが表示されます 画面上で最も重要な操作を行う場合。

ここでの主なアクションは、 旅行を作成することです。 そこで、右上隅に操作ボタンを配置しました。

ツールバーの3つ目の要素は、 ナビゲーションコントロールです。 旅行の詳細については、 一つ前の階層に戻れるように、 戻るボタンを追加しました。 そして再びウィッシュリストに アクセスします。

スキャンしやすくするため。 私は行動の数を最小限に抑えます。 上部のバーと同じガイダンスです。 そして、馴染みのある SF Symbolsを選ぶことで、 意味が明確になるようにしてください。

アイテムが多すぎる場合。 この例では 明らかに、人々がまず 何をすべきかを理解するのは難しい。 それを解決するには、あまり 一般的でないアクションを見つけるだけでよい。 あるいは、もっと高度な機能があって、 「その他」メニューの奥に 隠されているのでしょうか。

ツールバーは、主要な操作を際立たせる 目立つスタイルも提供します。 鮮やかな色彩を添え、瞬時に 視線を集めるポイントを作り出します。 アプリを設計する際には、 画面ごとに1つのアクションにのみ、 このスタイルを使用するようにしてください。 最高でも、 私たちが望むであろう多くの重要な 機能があることは承知しています 強調したいのは確かですが、 すべてが重要だとすれば、 何も重要ではないということになります。

では、この場合、旅行を全く行わない 旅行のバケットリストはどうなるのでしょうか。 だから、それを強調したいのです。

最後にツールバーについて言っておきたいのは、 タブバーの場合と同じように、 ネイティブのままにしておくのが一番です。 一緒に言うべきだ。

背景などの追加要素を加えることは、実際には、 それはあなたのコンテンツと競合します。 それは機能性やモルヒネ効果と競合する。 そして後ほど、カートもそのことについて 少し話してくれるでしょう。

ここまで、私はアプリの構造に 焦点を当ててきました。 そして、人々がそれをどのように 乗り越えていくのか。 そして今こそ、コンテンツを画面に映し出す時だ そして、それをどのように 発表するかを決定する。

これが私がレイアウトについて 言っていることです。 私が気に入っているレイアウトパターンの 例を2つご紹介します。 リストとコレクションを使用する。

どちらも非常に柔軟性があり、 どちらかをお選びいただけます。 あるいはその逆ですが、 すぐにわかると思いますが、 表示したいコンテンツと、 人々がそれに対して何をする必要があるか、 どちらか一方の方が優れている。

例えば、コンテンツがテキストベースの 場合はリストを使用します。 ええ。それに、展示する 必要のあるアイテムが複数あります。 そして、人々が非常に 素早く目を通すのに役立ちます。 だから、このレイアウトは 旅行のアクティビティに適しているのです。

ここでは、エッジツーエッジという スタイルを使用しています。 そうする必要があるからです。 コンテンツを分類する必要があるときは、 グループ分けの方法を使います。 つまり、微妙な違いなんです。 しかし、挿入図、挿入図のレイアウト そして丸みを帯びた角が、 異なるカテゴリーを明確に区別している。 リストに含めることができるコンテンツ。 だから、このスタイルは アプリには実際には必要なかったんです。 ダウンロードしてプレイを 開始するとそれを使えば、 この例は見つからないだろうが、 私は私がどのようにそれをできるかを お見せするために、 なぜなら、次のような混乱が常に 存在するからです。エッジツーエッジ印刷はどのような 場合に 使用し、インセット印刷はどのような 場合に使用すべきですか？ これが私たちのやり方です。

最後に、あなたは人々がリストを素早く確認し、 行動に移せるよう支援していますか？ 私はアクセサリーや コントロール類を使用します。 画像などの付属品字幕は、 人々がより早くアイテムを 認識するのに役立ちます。 行ごとに読むための機能や、 選択ボタンなどのコントロールここでは、 人々が別の視点に立つことなく 行動を起こすのを助けます。 これは非常によくあることです。 アプリは時として非常に複雑になる ビューを追加しているため リストビューから簡単に 実行できるいくつかの操作についてのみ。

追加できるコントロールには 多くの種類があります そして、さまざまな機能をサポートします。 ですから、ぜひご自身で 利用可能なものを探索してみてください。 レイアウトを簡素化できる 余地がないか確認してみてください。 ここでは、ステッピングモーター、 トグルスイッチ、スライダーなど、 様々な種類のスイッチをお試しいただけます。

そして、これには人々がテキストを素早く 読み進めるのに役立つリストも含まれます。 しかし、目的が写真、ビデオ、 または製品を閲覧することである場合、 コレクションの方がはるかに適している、

SwiftUIコレクションは基本的に StackViewです コンテンツが画面外に 拡張できるScrollViewを備え、 そして、スクロールして 中身を発見するように人々を誘います。

しかし、この「ウィッシュリスト」タブでは、 主な目的は閲覧することです。 そこで私はレイアウトを作ることにしました コレクションの複数のバリエーション

旅行をより視覚的に表現し、 個人的で刺激的なものに感じさせる、 人々がアップロードした写真を紹介します。

コレクションの場合、 すべてのコンテンツが一度に表示されるわけではないことに 注意してください。 そのほとんどは画面外にある。 適切な期待値を設定し、人々がそれらを スクロールして見るように促すために、 タイトルと画像を効果的に 追加するようにします。 それはどういう意味ですか？

さて、この例において、 画像は付加価値を与えていると思いますか？

少しランダムに見えますか？ はい。はい。とてもランダムですね。 そして、それが時にコンテンツの信頼性を 失わせる原因となるのです。 なぜなら、その画像は単に 理にかなっているわけではないからだ。 意図的に選ばれたようには見えない。 そして、長さが一定であることを示す タイトルを追加できます。 そうでなければ、レイアウトは 少しごちゃごちゃしているように見える。 そして、位置がずれている ように見える。つまり、 コレクションに損害を与えるだけでなく、 しかし、下に何かがあるときは、 縦スクロールも発生します。 今はすべてが少し不安定に見える。 だから、あなたのためにいくつかの ルールを設定しようとするのは、 きれいで良いことだ コレクションの内容において。

なるほど、SwiftUIは 既に私が私の説明の随所に 少しずつ散りばめてきたのですが、 しかし、階層、整列、 近接性など、それらはすべて 構成要素の一部です。 しかし、レイアウトを作成する際に、 これらのツールを積極的に 活用することをお勧めします。 そしてそれは、ビジュアルデザインの 重要な要素の一つです。

そこで、テキストの色と画像を使って、 人々の注意を誘導していきます。 そして、あなたの個性を表現してください。 これまでのところ、私たちは効果的に 業務を遂行しようと努めてきました。 それでは、あなたの魅力をもう少し引き 出せるかどうか見ていきましょう。 そこで、視覚デザインの中で 最も大きな影響力を持つ3つの側面について 考察したいと思います。 そして最も初期の影響。 織物、意味のある色彩、そして一貫性。

これらが相まって、アプリを楽しく、 より分かりやすくしている。 そして、私が大好きなもの。 アプリの成長に合わせて、 パターンを再利用するためのガイダンスを 提供してくれます。

まずはテキスタイルから始めて、 スタイルの階層構造を説明しましょう。 彼らは申し訳ないと思っている。 彼らは階層構造を確立した。 また、様々な画面サイズや 環境下でも読みやすさを向上させる。 だからシステムテキスタイルを使えば、 すぐに階層構造が実現します。 しかし重要なのは、目的に合った 適切な生地を選ぶことです。 アプリ内で使っています。いつも使っています。 例えば、タイトル3は 「夏の輝き」のようなすべてのセクションタイトルに 使用されます。 画面全体がよりバランスよく、 より洗練された印象になります。 なぜなら、具体的なコンテンツセクションが 存在するからです。 そして、私が階層構造を表している と知っている織物を見た瞬間、 その内容が何を意味するのか、 私は正確に理解しています。

私がシステムテキスタイルに頼るもう 一つの理由は、ダイナミックタイプです。 多くの人が快適さを求めて 大きな布地を使用するあるいは、 両方の場合もある。 そして、ダイナミックタイプを使用すると、 それらのテキスタイルは同じ名前になります。 しかし、それらは一貫して大きい。 ですから、ぜひ使ってみてください。

フォントファンなら、 アプリ全体でAppleシステムフォントSF Proを 使用していることにお気づきでしょう。 しかし、私は明らかに一つのスタイルだけを 使っているわけではありません。 SF Proには、個性を形作ることが できるさまざまなバリエーションが 含まれています。 アプリの可読性を損なうことなく。 私たちはもっとスポーティーな 雰囲気を目指していました。 だからタイトルでは強調のために expandedを使っています また、一部のオーバーレイではごくわずかに 凝縮するにとどめる。

ここでも、UIが意図的であるように、 選択肢を最小限に抑えたいと思います。 さらに、アプリの維持管理や拡張も容易です。 それから、繊維製品に戻りますが、 ああ、拡張版はいつ 使用すればよいですか？ Konaはいつ使うのですか？ そして今、たくさんのテキスタイル、 たくさんのバリエーションがあります。 それに、フォントの種類もかなり多い。

先ほどコレクションについて説明したとき、 アプリの視覚的な印象において、 画像が大きな役割を果たしていると述べました。 つまり、意味のある色は UIの良い補完要素であり、 そして、彼らは非常に似た 役割を担っているが、より具体的で、

つまり、ステータスと フィードバックのことです。 例えば、私はこのアプリ全体で インディゴという色を使っています。 例えば、ここでは 完了したアクティビティの中にあり、 上部のバーで選択されている タブの中にあります。

私は装飾にインディゴやそれに 非常によく似た色を使うことを避けています。 そうしないと、人々はこれが インタラクティブなのか、 それともそうでないのか 理解できないかもしれません。 何か意味があるのだろうか？ 私はこの色をインディゴと名付けました。 その前に、私たちは 意味的な色について説明します。 つまり、それは周りにある 色ではないということです。 ええ、適当に選びました。

システムによって提供され、各色は ネイティブにあるので、申し訳ありません。 各ネイティブコンポーネントには、それぞれ 独自の色があります。 だから、背景は設定しませんでした。 区切り線の色は設定していません。 これらは全て、私にとっては 既に既成概念にとらわれないものです。 私が選んだのは、 このアクセントカラーだけです。

つまり、これらの色はライトモードとダークモードに 自動的に適応するからです。 また、Liquid Glassや 様々なスクリーン環境にも対応しています。 カスタマイズをやりすぎない方が良い。 特にボタンや操作部に関しては。

アプリでご覧になったかもしれません が、カラーパレットも ネオングリーンも含まれていますが、 強調のためだけに取っておきます。 進捗状況を示す指標や小見出しなど。 ここでもまた、意味やこれらの視覚的な 比喩を理解しようと試みている。 つまり、色は意味的なものではない。 それは私たちのキットには含まれていません。 だから、十分なコントラストがあることを 確認するんです。 様々な背景でテストしてみました。 また、コントラストを高めるための 値も指定しました。

つまり、システムカラー以外の色を 使用することにした場合です。 いくつか簡単なルールを守るようにしてください。 例えば、このルールのように。 テストを続け、アプリがまだ 表現力豊かであることを確認してください。 しかし、使いやすさには影響を与えない。

そろそろ終わりに近づいてきたので、 つまり、すべてが最高の状態に 見えるように確認するのに 最適な時期だということです。 そして最後の仕上げとして、 戻って、すべての要素が 揃っているか確認します。 そして、常に一定の間隔を空けていた。

これにより、デザインがより洗練され、 視覚的にバランスの取れたものに感じられる。 プロっぽい見た目だ。 また、人々が情報をどのように取り入れ、 次に何をすべきかを決定するかにも役立ちます。 狭いスペースにたくさんの部品が詰め 込まれている場合、どうなるでしょうか？ 私たちはストレスを感じ、 考える余裕も時間もないように感じます。 そしてUIにもう少しゆとりを持たせると、 その時、素晴らしい体験が始まった。 人々が物事を整理するための 時間と空間を与える場所。

だからネイティブコンポーネントを使うときも、 同じように使うように気をつけています。 異なる画面間でも同様に。 私は、同じことをする複数の方法を人に 与えることを避けています。 そういうことも時々ある。 私たちは新しいスクリーンを作ることに ワクワクし、ゼロから作り始めます。 しかし、一番良い点は、 開発を簡素化するだけでなく、 人々がこれから経験するのは、 これらの部品を別の用途に再利用することだ。 彼らはそれを以前どこで見たのか 知っている。彼らは自分たちの振る 舞い方を自覚している。 そして彼らは、自分たちに何が 期待されているかを正確に理解している。 例えば、進捗指標として、 ここでは同じアクセントカラーと 形状を使用します。 しかし、それらはさらに少し小さい。 それらは私がよく知っている状況の中にある。 ええ。彼らは何をしたんですか？ そして、その一貫性はあなたの 成長にも役立ちます。 組み立てる部品が少なくなります。

コレクションの説明の中で イメージについて簡単に触れていますが、 もちろん、ビジュアルデザインの一部です。 画像やイラストを選ぶ際には、それらを並べて、 裏地が似ているかどうかを確認してください。 詳細度と全体的な雰囲気。 その後、微調整や調整を行うことができます そうすることで、彼らは自分たちが 同じブランドの一員だと感じるのです。 もしそれらが同じコレクションに 属するものだと感じるなら、 自分の直感を信じてください。 彼らの言うことはおそらく正しいだろう。 例えば、ウィッシュリストでは、 ユーザーが自分の写真をアップロードします。 しかし、その点を説明するために、 コード内にもどのように組み 込めるかを示すために画像を使用しました。 あなたはそれらの画像に アクセスできるようになります。 つまり、私たちが辿ってきた パターンがお分かりいただけるでしょう。 だから、ダイナミックな空を目指します。 多くの場合、被写体はより小さく、 空間と相互作用し、 しかし、UIが写真よりも 目立つという考え方です。 しかし、間違いなくあなたが 評価すべきものです。 アプリ全体で統一感のある外観を実現するため。

そう考えると、アプリのデザインに関しては、 私の功績が大きいと言えるでしょう。

少しはそうかもしれないが、 SwiftUIがデザイン上の 決定の多くを処理している。 私にとっては。そしてそれは、 まさに正直な意見です。

でも本当なんです。エンジニアの方々と一緒に 仕事をするのは本当に楽しいです。 このアプリを作成するにあたり、 そして、私がデザインしたものがすべて、 コード上でも非常に似た翻訳になっています。 皆さんと共有できることをとても嬉しく思います そして、それを使って遊ぶことができる。 そして、これらのヒントのいくつかを、 あなたのプロセスにとって、 そして、ご存知のように、 少し不確実性を減らすために、 創造性を発揮したいときに、まるで ランダムな時点のようにあるいは、 最初は創造性を発揮できる 場を提供するだけです。 意思決定を行い、ブレインストーミングを行い、 そしてコーディングに取り掛かる。

ですから、仕事に復帰する際には、 組織構造とそのナビゲーションを明確に 定義または評価してください。 部品は意識して使用しましょう。 これは、明確な意思決定を行うのに役立ちます。 つまり、コーディングを始めた瞬間から、 自分がどこに向かっているのかを 正確に把握できるのです。 あなたはまさに、あなたが築き 上げているものそのものです。 そう、そうすれば、より意図的なアプリを 開発できるようになるでしょう。 よし、 SwiftUIと提携しよう、 重労働は任せて、あとは 自分の個性を出すことに集中しましょう。 創造性と、そこに人間味が 加わっている。本当にありがとうございます。 組み立てを楽しんでいただければ幸いです。 私もアプリで遊んでいます。 以上がデザイン面に関する全てです。 お越しいただきありがとうございます。 それでは、リアに返します。

わあ。すごかった。 マジョ。SwiftUIの システムコンポーネントのおかげで 簡単にできるのが気に入っています。 人々がすぐに使い方を理解できる アプリを設計する。 Wishlistは美しいアプリで、 ちょっと立ち止まって そして、それぞれの決断の背後にある 考えを理解することで、 その決断の価値をさらに 高く評価するようになる。 全く新しいものを試作している場合でも、 既存のアプリを改良している場合でも、 私は常に、システム構成要素を有効活用できる 機会を模索するようにしています。

さて、ここで少し休憩を取りましょう。 11時15分（太平洋標準時） にここで再集合し、 SwiftUIのレイアウトに 関するプレゼンテーションを行います。 それではまた。

おかえり。

休暇を楽しんでいただけたでしょうか。 そして、飲み物を飲んだり、 体を伸ばしたりする機会があった。 それでは、同僚のCatが SwiftUIでのレイアウトに 関するガイドを共有します。 キャットをステージに迎えるにあたり、 皆さんも一緒に盛大な拍手をお願いします。

おはようございます。皆さん、こんにちは。 私の名前はキャットです。Appleで 開発ツールエンジニアをしています。

ここ数年、 私はApple WatchのVitalsアプリなどの プロジェクトに 携わってきました。iPhoneと iPadのヘルスケアアプリにおける 睡眠体験も同様です。そう、これらは 直感的で美しく見える必要がある体験なんだ。 手首をちらっと見る場合でも、 スマートフォンを見る場合でも。

この仕事を通して、 私は強力なUIレイアウトが基礎は、 これを可能にする土台です。 今日、SwiftUIレイアウトの 普遍的な構成要素となる 原則について説明します。 どのプラットフォームで作業しているかは 関係ありません。

まず、SwiftUIの概念的な構成要素をいくつか 改めて確認します。 レイアウトにとって特に重要なもの、続いて、

SwiftUIのレイアウトメカニズムについて 説明します。

次に、例を挙げて説明します SwiftUIを使用して 予測可能な結果を​​得る。

それでは、基本から始めましょう。 リアが今朝説明した見解は、 SwiftUIのビューは、 画面に表示される内容を記述する 軽量なテンプレートです。

ビューとは、位置、サイズ、 階層構造を表すテンプレートのことです。

SwiftUIは、画面に 表示されている内容を記述するための 軽量なビュー構造体を作成します。 そしてそれらを破棄し、 以降の更新で新しい構造体を作成します。

SwiftUIアップデート エンジンは変更された UI 部分のみを更新します。 状態変化に基づいて、 予測可能で効率的な結果を保証する。

この効率性は、SwiftUIの ローカル更新モデルによるものです。 ビュー階層の一部分の変更は、 無関係なサブツリーには連鎖しません。 そのため、影響を受ける サブビューのみが再レンダリングされます。

そして SwiftUI。 ビューテンプレートは、 位置決めからすべてを制御します。 レンダリングと状態更新のためのサイズ調整。

ビューとは何か、そして SwiftUIの更新エンジンがどのように 機能するかについて説明しましたので、 これらの概念がどのように組み合わさるのか、 その仕組みを説明します。 SwiftUIがレイアウトを実行するとき。

レイアウトの仕組みについて説明しながら、 今回は、ウィッシュリストアプリで 作成したトリップカードに 焦点を当てて説明します。

TripCard は、 SwiftUI がどのように処理するかを 示す素晴らしい例です。 さまざまな状態に基づいた動的なレイアウト。

そして、SwiftUIのレイアウトは 状態に依存する機能です。 ここで私が状態と言うとき、 それは状態プロパティラッパーのことではなく、 つまり、一般的に言って、

例えば、カリフォルニア沿岸トレイルのような 旅行の名前のように、

または、旅行の写真のURL。 SwiftUIは、レイアウトから 状態を本質的に抽象化しています。

これは他のUIフレームワークでも可能です。 しかし、それにはある 程度の努力と規律が必要だ。 しかし、この抽象化は SwiftUIの不可欠な部分です。

状態は、UIを動的に 制御することでレイアウトを決定します。

状態は、それらの各ビューの中身も設定します。 画面に表示されている文字列や画像のように。

他のフレームワークでは、 状態変更には手動更新が必要となる。 UIの特定の部分を表示するために、

また、 SwiftUI の状態変更により、 影響を受けるビュー テンプレートが 自動的に再生成されます。 常に最新の情報を把握しておくようにする。

それでは、Wishlistアプリの 旅行カードのレイアウトをどのように 作成したかについて説明します。 レイアウトを状態から抽象化する 方法を説明するために、ここに示したように。

トリップカードは、無地の暗い 背景に表示されています。

旅行を表す画像を含むVStackがあります

そして、旅行名を表示するテキストビュー。

旅行の画像ビューには、アクティビティの 数を表示するオーバーレイがあります。

ただし、活動の数がゼロより大きい場合に限る。 そうでなければ、テキストは 決して作成されません。 また、 SwiftUI はアクティビティの オーバーレイをレンダリングしません。

ビューの状態は、モデルからのトリップによって 独立して制御されます。

Tripモデルには、 旅行のタイトルを表す 名前文字列と写真URLが含まれています。 旅行用にどの画像をレンダリングするかを 決定するため。

そして最後に、アクティビティの 辞書も付いています。 辞書内のアクティビティの カウントが使用されます アクティビティオーバーレイが表示されている かどうかを判断する。

これは、状態制御による SwiftUIの簡単な例です。 レイアウトと価値の付け方。 この例では、アクティビティの 数が使用されています。 ビューのレイアウトをカスタマイズする。

次に、SwiftUIにおける レイアウトの仕組みについて説明します。

SwiftUIレイアウトの基本的な前提は、 コンテナがサイズを提案することです そのサブビューへ。

この提案のサイズは コンテナビューによって制限されます そして、それ以前のすべてのコンテナビューも。

各サブビューは、自身の推奨サイズを計算して 報告することで応答します。

ビューやSwiftUIによって、 推奨されるサイズは異なります。

色彩表現は常に、提示されたものをそのまま 受け入れる。 それは利用可能な空間を埋めるように成長する。

Imageviewは、 たとえ提供されたスペースが少なくても、 常にフルサイズを要求します。 これは、画像が本来のビューからはみ 出す可能性があることを意味します。

これを上書きするには、 resizable修飾子を使用してください。 そして、色と同じように、 提供されたスペースを何でも占有します。 たとえ、ここにある海岸の花のように、 最終的に潰れたような見た目になったとしても。

画像の元の縦横比を維持するため。 コンテンツモードを「フィット」 または「フィル」に設定します。

テキストには、少なくとも省略記号を表示するのに 十分なスペースが必要です。 テキストは、その内容に 必要なスペースのみを占有します。

レイアウトとSwiftUIは 階層的に処理されます。

コンテナビューは、そのサブビューそれぞれに サイズを提案します。

提案されたサイズが 特定のものであると仮定します。 例えば、このオレンジ色の枠は、提案書がどのようなものになるかを 示しています。

コンテナビューがアプリの ルートビューである場合。 提案はデバイスサイズ、 またはフレーム修飾子を適用する場合です。 提案内容はフレームのサイズです。

一方、提案されたサイズが 明記されていない場合もある。

または両方向。

これは、コンテナビューがサブビューが 全く制約を受けていない場合に、 どれだけのスペースを必要とするかを知るため。 これはサブビューの理想的なサイズです。

各サブビューは、提案されたサイズに基づいて、 それぞれが推奨するサイズで応答します。

これはSwiftUIの特別な独自の動作です 他のビューシステムへ。 提案は下がっていくだけでなく、 上がっていくこともある。

このレイアウト処理は再帰的です。

提案はルートビューから ビュー階層全体へと流れていきます。

すると、反応は再び上層部へと流れ込む。

サイズがわかったら、 ルートビューは、すべてのサブビューに 描画場所を指示します。 それらはサブビューに指示を出し、 すべてのビューが描画されるまで これを繰り返します。

それでは、同じルートをもう 一度ご説明しましょう。 今回は、TripCardに 掲載されている実際の閲覧数と 実際の数値をご紹介します。

TripCardは、水平スクロールビュー内の 水平スタックに表示されます。

旅行カード全部欲しい。 カリ、京都なども同じ高さで、 元画像のサイズや旅行名の長さに関係なく。

高さ固定のフレームを使えば、それが可能です。

SwiftUIは無制限の幅を提供します そして、TripCardのルートにある VStackの高さは 220に固定されます。

スタックはサイズを提供します 旅行画像ビューの高さは220です。 これは単なる例です。 高さが固定されたフレームの。

画像ビューは、必要な正確なサイズである 185 × 150ポイントで応答します。

外側のスタックは返された高さを減算します。 そして残りのスペースには、 旅行名を含むテキストを配置します。

名前のテキストは、必要なスペース（ 15 × 130ポイント）で応答します。 最後のビューに到達しました。

これで、各ビューが 必要なサイズを返信しました。

それは、アクティビティオーバーレイ以外の 各ビューのことです。 それについては、プレゼンテーションの 後半で改めて触れます。

手続きを完了します。 VStack は、内部画像、 ビュー、テキストの要求された サイズを組み合わせます。 そして、ビューの最終的な 要求サイズを返します。

これがSwiftUIの レイアウトの仕組みです。

まとめると、 SwiftUI のレイアウトは 上から下へ順に処理されます。 また、サイズ情報はどのレベルでも ルートまで共有されます。 利用可能なスペースは コンテナビューによって提供されます。

必要なスペースは サブビューによって決まります。 おそらく、自身のサブビューを 確認することによって。

レイアウトは状態が変わった ときにのみ再計算されます。

ビューテンプレートは常に再作成されます。

状態がコンテンツを制御するため、 Trip の値が変更されると、 表示は自動的に切り替わります。

素晴らしい。さあ、魅力的なSwiftUIビューを 作成する時が来た。

私がSwiftUIを始めたばかりの頃、 ビューを作成しても、期待した 結果が得られないことがありました。 それでは次に、いくつかのガイドラインを ご紹介します。 レイアウトをシンプルかつ 構成しやすいものにすることで、 予測可能な結果が得られます。

最初の考慮事項予測可能なレイアウトの場合、 レイアウト優先度が使用されます ビューの配置順序を決定し、 間隔やサイズ変更の調整を行う。

眺望の要求を満たすのに 十分なスペースがない場合、 レイアウト優先度が高い ビューにはより多くのスペースが割り当てられ、 レイアウト優先度が設定されます。 レイアウト優先度修飾子を使用し、 デフォルト値はゼロです。 値が高いほど、優先順位が高くなります。 例えば、優先度3のビューはより 高い優先度になります 優先度1のビューよりも。

これはおそらく、あなたが 普段バグキューで慣れ親しんでいるものとは 正反対でしょう。p1が最優先事項です。 しかし、この場合は正反対だ。 数字が大きいほど、優先順位が高くなります。

そして、ウィッシュリストアプリ。 カードの幅を広くした 旅行プランのセクションを作成しました。

Wishlistアプリのデザイナーである Majoとチャットしていたのですが、 そして私たちは、これらの広範囲な旅行カードが 最適な場所だと考えています 余剰スペースを活用する 旅行のサブタイトルと作成日を表示します。

コンテナビュー内に複数のテキストビューが 含まれる場合もあります。 テキストは、利用可能なスペースに応じて、 切り詰められたり、 折り返されたりする場合があります。

この例では、字幕を追加すると そしてハワイ（アメリカ合衆国） のテキストの日付 カードの左下隅の部分が途切れてしまった。

利用可能なスペースの広さは 分からないかもしれません。 例えば、デバイスのサイズによって 異なる場合があります。それに、

自分にはどれくらいのスペースが必要なのか、 自分でもよくわからないかもしれない。 旅行によっては字幕が長くなるものもあり、 レイアウト内のさまざまなテキストの 重要性を注釈することで、 どのテキストを切り詰めるかを決定する。

テキストのレイアウト優先度を上げることで、 それが可能になります。 デフォルト値のゼロから、 1のようなより大きな値へ。

先ほどお話ししたように、 スタックは優先度の高い ビューに最初にスペースを提供します。

字幕に必要なスペースがすべて確保される。 しかし、これによって右下隅の日付テキストが 切り詰められてしまう。

私はこのレイアウトの問題をデザイナーの Majoに伝えました。 彼女は、スペースが足りない場合は 作成日を隠すことを提案した。 そのため、「Trip」 という字幕が完全に表示されます。

それは文字列の切り捨てを回避できるので、 素晴らしいアドバイスだと思います。 それでは、その方法をお見せしましょう。

HStackをViewThatFitsビューの 中に移動しました。 ViewThatFits はサブビューを 評価します。 初期化子に渡す順序で。

提案されたサイズ内に理想的なサイズが 収まる最初のサブビューを選択します。 これは、あなたが希望する順序で 意見を提供することを意味します。 通常、この順序は大きいものから 小さいものへと続きます。

そこで、サブタイトルだけのテキストビューを 追加しました。 HStack 内のビューが切り捨てられると、 ViewThatFitsはテキストビューを 選択します。

これらの変更は、デザイナーのマジョをきっと 喜ばせるでしょう。

次に、スタックの配置について説明します。 スタックは、ビューが 一致するように配置します。 デフォルトの配置は中央揃えですが、 他の配置を指定することもできます。

センターに加えて、 HStack内のビューは、上端または 下端を垂直方向に揃えることもできます。 また、 firstTextBaseline または lastTextBaselineにも 適用されます。

VStack 内のビューは、 その先端で水平方向に揃えることもできます。 後縁部など。

旅行コレクションのセクションヘッダー ウィッシュリストアプリはその完璧な例です。 デフォルトでは、スタックは 中央揃えを使用してビューを揃えます。

しかし、要素が複数ある場合、 位置がずれて見えることがあります。 この場合は、すべてを基準値で 揃えるのが最善です。

ここでは、セクションのサブタイトルの サブビューは デフォルトの配置を使用しています。 つまり、ショー全体が視覚的なラインより 上に浮かんでいるということです。 字幕テキストによって確立された。

HStackの配置をfirstTextBaselineに 変更することで、 私は番組全体を、字幕によって 確立された同じ視覚的なラインに合わせる。

それでは、SwiftUIで レイアウトを作成する際に 考慮すべき点をいくつかご紹介します。

可能な限り、明示的なレイアウトではなく、 適応型レイアウトを作成してください。 適応型レイアウトにより、さまざまな デバイスサイズに簡単に移動できます。 ウィンドウサイズ、およびプラットフォーム。

ビューフレームを明示的に操作するのではなく、 明示的な高さを使用するようにしてください。 そして、ビューの幅。 利用可能なスペースを埋めるように、 彼らが成長できるようにしよう。

フレームや位置などのビュー修飾子のみを 使用します。 希望するレイアウトを、 適応的かつ柔軟な方法で実装できない場合。

Zstackと同様です。 ビューに奥行きを加えるには、 背景修飾子またはオーバーレイ修飾子を 使用できます。

オーバーレイと背景修飾子は レイアウトのサイズ設定には含まれません そして、常に変更対象のビューと 同じサイズになります。

これがレイアウトツリーの走査例で、 以前は、アクティビティオーバーレイは レイアウト計算に含まれていませんでした。 それは、コンテナビューの計算された サイズを継承した。 デフォルトでは画像ビューが表示されます。

レイアウトの問題は起こり得る。 今でも時々彼らに遭遇する。 それでは、識別に用いるいくつかの テクニックをご紹介します。 そして、それらのレイアウト上の 問題を修正する。

これらの多くは、迅速なプロトタイピングを可能にする SwiftUIの力に基づいています。 ちょっとした調整をするだけで、 すぐに結果が現れる。

簡単な方法の一つは、画像に 赤色などの色の枠線を追加することです。 そして、テキスト部分は青色にします。 このトリップカードでやったように。

この手法は、スタックレイアウトを理解する 上で特に役立ちます。 そして、景色を囲むように余白を設ける。 一時的な境界線が重なることもあります。 また、サブビューのサイズと位置をより 明確に表現できるようにしたい。 この場合、半透明の色のオーバーレイ修飾子を 使用します。 サブビューの全容と、それらがどのように 階層化されているかを明らかにするため。

ビューがレンダリングされたときに、 プロパティの値を表示することも 役立つ場合があります。

print関数を使ってみたものの、 コンパイラエラーに遭遇してがっかりした 経験があるかもしれません。

ここで表示されるエラーメッセージは 「ビルド式が利用できません」です。 この表現は、見解に適合しません。

このエラーは、Swiftの print 式には戻り値がないためです。

そのため、戻り値の型はvoidです。 そして虚無は景色ではない、 しかし、ビューの本体は 変数宣言をサポートしています。

プレースホルダー変数を宣言することで、 このエラーを修正できます。 これで、等号の右側に print式を記述できます。 これはエラーなくコンパイルされ、 実行時にはコンソールに出力されます。

次に、 Xcode はプレビュー キャンバスを プレビューします。 Xcodeは、どのビューがどのコードに 対応しているかを素早く 確認できる便利なツールです。 キャンバス下部のマウスポインタアイコンを クリックします。 プレビューを選択可能にする。

そして、エディタでコードを選択すると、 プレビューでは関連するビューが強調表示され、 プレビューでビューを選択すると、 Xcodeはエディタ内で 対応するコードを選択します。

私の道具箱の中で最も強力な道具 レイアウトの問題をデバッグするには、 Xcodeのビューデバッガーを使用します。 アプリを実行してビューデバッガーで 停止することで、 すべてのビューを展開してから、 個々のサブビューを選択して 焦点を合わせることができます。この手法は、 SwiftUIとUIKitを組み 合わせて使用​​する場合、特に効果的です。 ここで重要な点に触れたいと思います。

SwiftUIはJamesが 言うようにUIKitのレイアウトと 互換性があります。 AllTrailsのグラハムが 後ほど共有してくれるでしょう。 詳細については、 WWDC 22のビデオをご覧ください。 SwiftUIをUIKitと組み 合わせて使用​​する。

SwiftUIのレイアウトの 基本について説明したので、 そろそろこれらの概念を実践に移す時が来た。

学ぶための最良の方法は、 実際に作り始めることだ。 私はまず、気に入ったアプリからビューを選び、 それをSwiftUIで 作り直すことから始めました。

Xcodeのプレビュー機能は、 さまざまなレイアウトを素早く 試すのに最適な方法です。 そしてアプローチ。

印刷などのシンプルなテクニックを使用する また、レイアウト上の問題点を診断するための カラーオーバーレイも備えています。 問題の特定と解決がどれほど迅速にできるかに、 きっと驚かれるでしょう。

本日はご参加いただきありがとうございました。 さあ、SwiftUIを使って 何か特別なものを作って、 残りのセッションを楽しんでください。

最高だったよ。猫。 レイアウトの経験を積む方法についての アドバイスがとても気に入りました。 既存のビューを再現しようとしています。 いろいろ試してみて、 自分なりの思考モデルを構築してみよう。 次に、同僚のカートがSwiftUIにおける モーションの詳細について解説します。 カートをステージにお迎えするにあたり、 皆様の温かい拍手をお願いいたします。 ありがとう、リア。

こんにちは、カートです。 私はテクノロジーの伝道師です。 ワールドワイド開発者リレーションズチームで、 今日皆さんとご一緒できて、本当に嬉しいです。 そして、オンラインで参加してくださった 皆様を歓迎いたします。 デベロッパーリレーションズに入社する前は、 私はSwiftUIのエンジニアとして、 ナビゲーション機能を中心に 開発に携わりました。 そしてAPI設計。

今日は、動きを導入するための 基礎についてお話しします。 SwiftUIを使用したアプリで。

デバイスの性能が向上するにつれて、 インターフェースもより ダイナミックになってきた。 この動作を適切に行うことで、 デバイスはより生き生きとした、 パーソナルな印象を与える。 動きのあるデザインは、アプリや プラットフォームをより分かりやすくする。 それは文脈を提供し、人々の注意を導く。 それに、単純に楽しいんです。

こうしたダイナミックな 相互作用を生み出すには、 多くの要素が組み合わさる必要がある。 人々が一つの視点から 別の視点へと移行する遷移があり、 設定アプリでビューに プッシュするのと同じように、 または、焦点を絞る選択肢のシートを提示する そして、人々がデバイスと直接やり 取りするジェスチャー、 地図を拡大して詳細を表示したり、 アプリ間をスワイプしたりするような操作です。

そして最後に、画面上のオブジェクトが 移動したり、大きくなったり、 または、Dynamic Island内のライブアクティビティなどの 視覚的なプロパティを変更します。 これら全てが連携して、 流動的でインタラクティブなインターフェースを 作り出します。

SwiftUIは、アプリに滑らかな動きを取り 入れるための最良の方法です。

SwiftUIにおけるモーション表現は、 実に多岐にわたる。 最もシンプルな方法では、 自動翻訳トランジションが得られます。 組み込みのSwiftUIコンポーネントを 使用するだけで。

状態駆動型アニメーションでレベルアップし、 選択できるようになります SwiftUIにアニメーションの方法を 指示する修飾子のメニューから選択 特定の特性が変化すると、

または、完全にカスタムの アニメーションを指定して、 まさに、フレームごとに起こるべきこと。

今日は、この幅広い 範囲から例を挙げて説明します。 適切なツールを選択できるように アプリに最適な、ダイナミックで 動きのある体験を創造します。

多くのSwiftUIビューは、 滑らかなモーション効果を自動的に提供します。 Wishlistアプリからいくつか 例をご紹介します。 そして、これらの自動効果を微調整する 方法を紹介します。 アプリで表現したい感情を呼び起こすために。 次に、状態駆動型アニメーションを追加する 方法について説明します。 SwiftUIの修飾子とプロパティを 使用して、アプリに修飾子を追加します。 これらのアニメーションの 基礎について説明します。 つまり、目の前の作業に 最適な手法を選択できるということです。 最後に、SwiftUIにおける カスタムアニメーションの威力を説明します。 さらに詳しく学ぶための資料もいくつか ご紹介します。

SwiftUIの組み 込みビューを使用する場合、 多くのモーションエフェクトが 自動的に適用されます。

このウィッシュリストアプリは、 NavigationStackプッシュのパワーを 示す素晴らしい例です。 誰かが旅行のサムネイルをタップしたとき。 チェックマークなどの記号は、 やり取りがあったことを示す。 詳細がサムネイルに戻り、 シートがアニメーションで表示されます。 ポップアップメニューは、Liquid Glassの ボタンから変形して出現する。 スクロールビューは、 ユーザーがスワイプすると自動的に加速し、 スワイプすると減速します。 スワイプを停止したとき、 または特定のビューで停止したとき。

使用できる 4 種類のSwiftUIビューについて 説明します これらのモーションエフェクトを 自動的に取得します。 このようなナビゲーションスタックから 始めましょう 旅行の詳細が表示される 「ウィッシュリスト」タブをご覧ください。

Wishlistアプリは、 各タブ内にNavigationStackを 使用しています。

この束の中には、様々な旅行のための タイルがすべて入っています。 すべての旅行を反復処理する for each に焦点を当てます 私の秋の旅行記のようなコレクションの中に。

これらのサムネイルはそれぞれ ナビゲーションリンクによって描画され、 目的地ビューとラベル。

ラベルとは、ユーザーがタップする インターフェースの一部のことです。 そうすると、宛先ビューが スタックにプッシュされます。 デフォルトでは、後端から スライドして入ります。

戻るボタンをタップしたり、 ディスプレイをスワイプしたりしたとき。 目的地画面がアニメーションで消える。 例えば、音楽やニュースなどのアプリでは、 ズームトランジションと呼ばれる テクニックを使って、 これらの押し出しや押し出しを洗練させます。

NavigationStackにズームトランジションを 使用させるには、 たった3つの手順で済みます。

まず、ビューのプロパティに 名前空間を追加します。 名前空間は、SwiftUIが 使用できる一意の識別子です。 他の2つのコードを関連付けるため。

次に、遷移修飾子を目的のビューに追加します。 ズームパラメータに一意の IDと名前空間を渡します。

最後に、リンクのラベルに 「match transition source」修飾子を追加します。

現在、ウィッシュリストアプリでは、旅行の画像をタップするとズーム効果のある トランジションが表示されるようになっています。

戻る操作をすると、詳細表示が サムネイルサイズに縮小してしまう。

ズームトランジションは素晴らしい 宛先がラベルに含まれる コンテンツを繰り返す場合、 ザイオン国立公園のこの美しい写真のように。

ナビゲーションリンクのラベルは、 より詳細な場合もあります。 例えば、ウィッシュリストの検索タブにあるこの 商品のように。

旅行名の横にサムネイル写真が表示されます。 このような場合は、一致する トランジションソースを追加します。 リンクラベルのサブビューへ。 SearchItemView という名前の カスタムビューを使用して、 これらの行がどのように 描画されるかを以下に示します。 サムネイルと旅行名を含む HStackを使用します。

ここに、一致するトランジションソース修飾子を 追加しました。 検索結果アイテム全体を表示するのではなく、 画像のサムネイルを表示する。

周囲の NavigationStack から 名前空間をプロパティとして渡しました そして、行をタップすると、 詳細ページがサムネイルから縮小表示されます。

元のページに戻ると、 サムネイル画像にズームインします。 こういうちょっとした心遣いが 本当に好きです。楽しいし、 人が最初にいた列に自然と目が向くようになる。

今日取り上げる2つ目の組み 込みビューの種類は、シートです。 Wishlistアプリのシートに 関するコードについて説明します。 ウィッシュリストタブのナビゲーションスタックをもう 一度表示します。 物件が提示されています。 シートが表示されているかどうかを判断するために 使用するトリップを追加します。 スタック内部には、ツールバー修飾キーが アタッチされたスクロールビューがあります。

ツールバーの中に、 このプラスボタンがあります。

その構造が整っていれば、シートを提示するにはたった 2つのステップで済みます。 まず、ツールバーのボタンは isPresentingAddTripプロパティを true に

設定します。そして第二に、 シート修飾子は表示する内容を指定します。 isPresentingAddTrip がtrueの 場合。

ここでの修飾子は、プロパティへの バインディングを受け取ります。 それがドル記号の意味です。 コールは後ほどバインディングについてさらに 詳しく説明します。 しかし、ここで重要なのは、 これによりSwiftUIが 設定できるようになるということです。 誰かがシートを閉じると、 isPresentingAddTrip は false に戻ります。

これらが揃った状態で、ボタンをタップすると、 シートは画面下部から スライドして上がってきます。 閉じるボタンをタップすると、 スライドして元の位置に戻ります。

ナビゲーションの場合と同じように、 これをズームトランジションに変換するために、 私の3段階の手順を適用できます。 二。 まず、ビューのプロパティに 名前空間を追加します。 次に、ナビゲーション遷移修飾子を追加します。 シートの内容にズームパラメータを渡します。

最後に、ボタンのラベルに一致する トランジションソース修飾子を追加します。

さて、私がボタンをタップすると、 シートがそこから変形して出てくる。

私がシートを閉じると、それは元の場所に戻る。

この動作によって、人々は ボタンとシートを関連付けやすくなります。

SwiftUI の ScrollView には、 組み込みのモーション エフェクトも 用意されています。 スクロールビューの目は、ユーザーが スワイプすると滑らかに減速しながら動きます。 そしてコンテンツの最後には、 親しみやすい反響が添えられている。 こちらは、ウィッシュリストアプリで 獲得したバッジを表示するための ScrollViewです。 ScrollViewは、 ユーザーがスクロールできるコンテンツを 表示するSubviewを受け取ります。 これが、私のバッジをすべて 表示したタイルの山です。 オプションとして、ScrollView は、 何を表示するかを指定する パラメータを受け取ります。 スクロールできる方向。

ここでは水平方向です。 Wishlistアプリのバッジについては、 ScrollViewは 常にバッジが画面中央に 表示される位置で停止するようにしたい。 たった2つのステップで、SwiftUIにこれを 実行させることができます。 まず、スクロールターゲットの 動作修飾子を追加して、 SwiftUIに指示します。 ビューに合わせて停止する。

次にスクロールターゲットレイアウト修飾子を 追加してSwiftUIに指示します どのビュースタックをこの 動作に参加させたいか。

それが整ったので、バッジをスワイプすると、 ScrollViewは常に画面中央に バッジが表示された状態で停止します。

そうなったら楽しいだろうな。 これらのバッジにちょっとした 遊び心を加えるのは楽しいだろう。 画面に出たり入ったりしながら。 書籍やスポーツなどのアプリは、 こうした種類のモーションエフェクトを 使用しています。 彼らはスクロールトランジション修飾子を 使ってこれを実現します。

変換したいビューに修飾子を適用します。 これが、私が達成した目標のタイルです。

私は移行をインタラクティブにします。 そのため、手動スクロールに対応し、 方向を水平に設定します。

修飾子はクロージャを受け取ります。 移行を定義する。 SwiftUIは、コンテンツのプロキシとアニメーションフェーズを クロージャに渡します。

位相は、遷移がマイナス1のどの 位置にあるかを指定します。 先端部を完全にスクロールすると、 完全に画面上に表示され、ゼロになります。 そして、後端まで完全に スクロールされている場合はプラス1点。

フェーズを使用してコンテンツを変更します。

ここでは、ゴールタイルが画面外に 移動したときに、そのサイズを縮小しています。

そして、垂直軸に沿って3次元回転を適用する。

見てください。景色が端で折り 返されているように見えるのがわかりますか？ まるで回転木馬の一部みたいに？ それは素晴らしいですね。

今日最後に紹介する組み込み ビューは、イメージビューです。 SF Symbols付き。

マジョがさっき言った通りだ。 SF Symbolsは、 7000種類以上のシンボルを収録した アイコンライブラリです。 この画面には重複する項目はありません。

SF Symbolsは サンフランシスコにシームレスに 統合されるように設計されています。 Appleプラットフォームにおける システムフォント。 Appleデベロッパ Web サイトから 入手できる Mac用SF Symbolsアプリは、 ライブラリを探索し、用途に合った適切な シンボルを見つけることができます。 例えば、ウィッシュリストアプリでは、 アクティビティリストにチェックマークが 使用されています。

自分のアプリにチェックマークを追加する。 SF Symbolsアプリで、コードに SwiftUI画像を追加します。 目的のシンボルをコントロールクリックして、 チェックマーク、円の塗りつぶし、 「名前をコピー」を選択してください。

次に、Xcodeでその名前を イメージ宣言に貼り付けます。

そして、これが私のチェックマークです。 SwiftUI、 SF Symbolsをアニメーション化するためのさまざまな 方法が提供されています。 3つの例を挙げましょう。

進行中の操作を示すには、 無期限の効果を使用します。 チャットで誰かが返信を送ってくるのを 待つようなものだ。 これらの効果は、有効になっている間は 継続的に発揮されます。 例としては、可変効果、色効果、 スケール効果、呼吸効果などがあります。

これらの効果のいずれかをSFシンボルに 追加するには、 Isactive パラメーターを指定して シンボル効果修飾子を使用します。 この引数の値が真の場合、 その効果は実行されます。

ダウンロードなどのイベントを示すには、 個別の効果を使用してください。 完了しました。これらの効果は、 イベントが発生したときに発動します。 例としては、跳ねる、 脈打つ、揺れるなどがあります。

これらの効果のいずれかをSFシンボルに 追加するには、 シンボル効果修飾子を値パラメータとともに 使用します。 この引数の値が変更されるたびに、 その効果が実行されます。

あるシンボルを別のシンボルに 置き換える場合は、 contentTransition 効果を 使用します。 例えば、円にチェックマークを 追加する場合など。

これらの効果のいずれかをSFシンボルに 追加するには。 シンボル効果タイプで contentTransition修飾子を 使用してください。 選択されたシンボルが変更されるたびに、 遷移が実行されます。

SF Symbolsアプリでは、アニメーションを 試すこともできます。

ここでアニメーションインスペクターに 切り替えます。 呼吸アニメーションを選択し、 実行するように設定します。 再生ボタンをクリックしてテストしてみます。 次に、コピーメニューを使用して アニメーション設定をコピーします。

Xcodeに戻り、設定した オプション付きの修飾子を貼り付けます。 SF Symbolsアプリで。

そして、息を吸って吐いて。

SwiftUIはスタック、 シート、スクロール ビューなどの ビューで構築されています。 画像には、さまざまな内蔵エフェクトが 用意されています。 アプリに合わせてこれらの効果を微調整するための 修飾子を自動的に追加します。

次に、別の種類のアニメーションを紹介します。 SwiftUIの 状態駆動型アニメーションにおいて。 説明しましょう。 以前、リアはSwiftUIビューが データから画面上のピクセルにどのように マッピングされるかを共有しました。 そしてCatは、 表示されるビューの例を示した。 またはウィッシュリストのレイアウトに 基づいて隠されている データモデル内のプロパティの値に基づいて。

このように使用されるデータは、 ビューの状態と呼ばれます。

ウィッシュリストアプリの例を以下に示します。 これは旅行の詳細画面で、 下部に予定しているアクティビティの 一覧が表示されています。 この画像の上に浮かんでいるテキストは、 パーセンテージを示しています。 私が完了した活動のうち、 さらに、タスクを完了するにつれて 埋まっていくバーもあります。

アクティビティにチェックを入れると、 SwiftUIは、アクティビティが 完了したことを記録するために、 関連する状態を更新します。 この状態に依存する ビューは自動的に更新されます 状態が変化するとき。

今のところ、アクティビティに チェックを入れると、 すべての変更が瞬時に反映されます。 代わりにSwiftUIにこれをアニメーションさせるように 指示します。 アニメーション機能を使ってそれを行います。 方法は以下のとおりです。 表示されるボタンのコードは以下のとおりです。 これは、旅行の詳細ページに 表示されるアクティビティを表しています。

このボタンの操作により、 完了状態が切り替わります。 関連する活動の。

この切り替え動作を、 アニメーション関数で囲みます。 これは、 SwiftUI、 発生するビューの更新をアニメーション化するように 指示します。 ラップされた状態が変化した結果として。 最新情報をもう一度お伝えします。 アクティビティを完了すると、 パーセンテージのテキストがクロスフェードし、 バーが塗りつぶされ、 アクティビティの色が変わります そして、チェックマークのクロスフェード。

これらの変更をアニメーション化するために、 アニメーションを追加しました。 残りは自動的に行われます。

アニメーションの強みは、 そのシンプルさにある。 関数内で状態変化をラップするだけです そして、その状態に依存する ビューのすべてのプロパティ そして、アニメーション化されるでしょう。 一方、アプリの一部では、より精密なアプローチが 必要になる場合もあるでしょう。

それを説明するために。 Wishlistアプリのこの完了オーバーレイのみに 基づいています。

アプリでは、これらの 3 つのビューは テキストの完了率を表示します。 バーとサブタイトルは、 カスタムの ActivityProgressView に埋め込まれています。

焦点を絞るため、いくつかのスタイル修飾語と サブタイトルを省略します。 アニメーションについて。 ActivityProgressView は完了を 受け取ります 0から1までの値を持つプロパティで、 完了率を表します。

書式設定済みのテキストビューに 完了率が表示されます。

この不透明度修飾子は、完了値が ゼロの場合にテキストを非表示にします。

ライムグリーンのバーには 角丸長方形を使用しています。

バーの幅は定数バーを乗算することによって 設定されます 完了値による幅、そしてまた、

不透明度修飾子によってビューが 非表示になります完了値がゼロの場合。

ウィッシュリストのデザインは ActivityProgressViewが 使用されている場所すべてで アニメーションを適用するため。 それにはアニメーション修飾子を使えばいい。

この VStack にアニメーション修飾子を 適用することで、 SwiftUI に、渡されたビューが アニメーションするたびにこれらのビューを アニメーションするように 指示します完了値の変更において。

これまでのところ、 その挙動は以下のとおりです。 これは、アニメーション機能を使って 得たアニメーションと全く同じです。

アニメーション修飾子は、アニメーションを 使用する代替手段です。 状態が変化する時点で。 アニメーションは、しかし、 状態変化のすべての要因が アニメーションをトリガーするわけではない。

一方、アニメーション修飾子を使用する ビューの状態の発生源に関係なく、 常にアニメーションさせたい場合。 両方ともアニメーションで変更する また、アニメーション修飾子を使用すると、 アニメーションのタイミングを変更できます。 その速度、加速度、そして跳ね返り。 これを使うと、アニメーションの雰囲気をより 細かくコントロールできます。

例えば、バーが少し揺れるとお祝い ムードが増すだろう それが増加したとき。それは、 アニメーションモディファイアに bouncy を渡すことで実現できます。 それがどんなものか、お見せしましょう。 緑色の棒グラフは、新しい値に 落ち着く前にわずかに変動する。

さらに弾力性を加えることもできます。

これから何が起こるか見てみましょう。 そのバーは楽しい雰囲気だ。

テキストに何かおかしいところがある。 それでは、もう一度実行して、 アニメーションの途中で一時停止します。

私の超弾むアニメーションは目標値を上回り、 そして元の位置へ後退し、最終的に落ち着く。 そして数字を見ると、 この後退は、数字が消え始めるほど十分に遠い。 初期値に戻す。 2つ目のアニメーション修飾子を追加することで、 この問題を解決できます。

テキスト表示部分だけに滑らかな アニメーションを追加します。

これで、弾むようなアニメーションが VStack全体に 適用されるようになりました。 しかし、テキストのためだけにその アニメーションを上書きします。 サブビュー。

数字に関する不具合は解消されました。 棒グラフは跳ね上がるが、 数字は滑らかにクロスフェードする。

これで解決したから、 バーに電話して少し気分転換しよう。 さらに、テキストにモーションエフェクトを 1つ追加します。

数値テキスト引数を持つ contentTransition修飾子は、 SwiftUIに指示します。 数値が変わる際に、特別なカウンターアニメーションを 使用する。 数字が順番に表示され、変化が強調される。

あれ、大好きです。

要約すると、SwiftUIのビューは データからピクセルへのマッピングを行う。 状態駆動型アニメーションを使用すると、 動作を制御できます このデータまたは状態の変化の結果として ピクセルが更新される時。

アニメーションの動作方法を指定するには、 幅アニメーション関数の実際の状態変化、 または、ビューにアニメーション修飾子を 追加することによって実現できます。 さて、先に進む前に、 私が使用しているオプションパラメータについて 少しだけお話しします。 バーのアニメーションの弾み具合を制御する。 このオプションパラメータは、 アニメーションのタイミングを制御します。 つまりこういうことです。バーには 弾むようなアニメーションを使っています。 アニメーションは目的地を通り過ぎてから、 ゆっくりと戻ってきます。 内蔵アニメーションの中で最も遊び心のあるもの

価値と時間の関係を示すグラフ上で。 価格は最終水準に落ち着く前に、 一時的に上昇する。

一方、キビキビとした アニメーションは最終値に素早く移行し、 正確さとプロ意識を感じさせる。

グラフには、値が最終レベルに 達する明確な屈曲点が見られる。

滑らかなアニメーションは、 弾むような動きとキビキビとした 動きの絶妙なバランスを保っている。 すぐに落ち着くが、キビキビとした アニメーションというよりは、 よりカジュアルな印象を受ける。

カーブはより緩やかで、 最終地点へはよりゆっくりと近づいていく。 Smoothは、汎用性の高い 優れたアニメーションです。 実際、これはAppleのすべてのプラットフォームにおける デフォルト設定です。

最後に、スプリングアニメーションを使用して、 スプリングのすべてのプロパティを カスタマイズします。 これにより、きめ細かな制御が可能になります。 跳ね返りを調整して、アニメーションの遊び 心をコントロールします。 0.6の反発で、値は複数回振動する。 最終的に落ち着く前に。 バネの持続時間も調整できますさらに、 他のバネ駆動アニメーションとの相互作用についても 考慮する必要があります。

通常、名前の付いたバネの弾力性、弾力性、 または滑らかが適切です。 でも、必要な時に自分で コントロールできるという安心感は良いものだ。

アニメーションとSwiftUIの 内部動作の詳細については、 SwiftUIアニメーションを 探索してみましょう。 次にバネを使ってアニメーション化して技術的な 問題を解決しますアニメーションのタイミングに 関するデザインガイダンスも併せて提供します。

どちらの動画もW23からのものです。

Wishlistアプリが SwiftUIの組み込みビューをどのように 使用しているかを共有しました。 美しいモーションエフェクトを 自動的に得るために、 そして、アプリが状態駆動型アニメーションを 使用して、 さらに洗練された印象を与えている 点についても解説します。 最後に、SwiftUIで 作成したカスタムエフェクトの例をいくつか 紹介して締めくくりたいと思います。

これらの例は現在ウィッシュリストアプリには 含まれていません。 しかし、それらを追加する方法を説明します。 このように実験してみることは、 感覚をつかむのに最適な方法です。 SwiftUIで可能なことについて。

最初の例は、跳ねるボールです。 これは読み込みインジケーターとして 機能するかもしれません。 PhaseAnimatorを使用してこれを 実装してください。

このアニメーションは 4つの段階から構成されています。 まず、ボールが落下する。

そして、潰れるんです。これは専門用語です。

ボールは再び膨張し、そして上昇する。

このサイクルは繰り返されます。列挙型は、 フェーズを定義するのに最適な方法です。 PhaseAnimatorの場合。 この例では、ドロップ、スクイッシュ、 エクスパンド、ライズを行います。 次に、アニメーションさせたい 各属性に対してプロパティを追加します。 この例では、まずプロパティに yオフセットを追加します。 各フェーズの終了時に値を返します。 上昇の終わりには、 ボールは元の位置より 40ポイント高い位置にある。 スクイッシュ終了時点で、ボールの 得点は5点下がっている。

他の2つの段階が終了すると、 ボールは元の位置に戻ります。 次に、ボールのスケールを表す プロパティを追加します。

押しつぶすと、ボールは通常の形よりも 少し幅が広く、少し短くなる。

そうでなければ、フェーズを定義した 後は丸い形になります。 ビューにフェーズアニメーターを追加します。

列挙型を適合させることで、 アニメーターがすべてのフェーズを 反復処理するようにします。 CaseIterable に変換し、 すべてのケースを PhaseAnimator に渡します。

SwiftUI はアニメーターの 最初のクロージャを呼び出します。 各段階を順番に通過する。 だから、下がったり、縮んだり、 膨らんだり、上がったりするんだ。 次に、ここにアニメーションビューを 描画します。 それが円です。次に、フェーズから 引数を読み取って修飾子を適用します。 ここでは位相のyオフセット値で オフセットしています

そして、各フェーズのスケール値による スケーリングを行う。

最後に、2回目の閉鎖では、 各フェーズで使用する アニメーションを定義します。 ここでは、ドロップと展開のアニメーションに イーズ効果を使用しています。 これらは最初は遅く、 最後は速い。そして、私は生地を潰したり 膨らませたりするためにイーズアウトを 使っています。

以上が、SwiftUIで フェーズアニメーションを作成するための 4つのステップです。 各アニメーションプロパティのフェーズを 定義します。 各フェーズの終了時点での値を定義します。 アニメーション効果を適用して ビューを描き、最後に、 各フェーズのアニメーションを指定します。

フェーズアニメーターについてもっと詳しく 知りたい場合は、こちらをご覧ください。 高度なアニメーションを駆使して進んでいこう WWDC23のSwiftUIで紹介します。 次に紹介するカスタムエフェクトは トランジションです。 ウィッシュリストでバッジを 獲得した人を祝うため。

このエフェクトはかっこいいけど、 速いからもう一度やってみるよ。

SwiftUI、 ビューを追加または 削除する際にトランジションを適用できます。 または、一方を他方と置き換える。

このバッジ移行には、 大きく分けて2つのステップがあります。 まず、あるビューを別のビューに 置き換えるコードを記述します。 ここでは、まずバッジのグレースケール版から 始めます。 そして、それをカラー版に置き換えます。

ビフォーアフター画像を格納するための グループを作成します。 if文を使ってカラー画像を表示します。 バッジが獲得されたもの、 またはそのグレースケールコピーである場合。 それ以外の場合は、設定をtrueにすると、 灰色のバッジが置き換えられます。 色付きのものと一緒に。

2つ目のステップは、 この置換をアニメーション化することです。

これを行うには、グループに 遷移修飾子を追加します。 これはSwiftUIにモーションエフェクトを 適用するように指示します。 グループ内のビューが入れ替わったとき。 ここには、使用できる組み 込みのトランジションがいくつかあります。 不透明度やスケールなど。 しかし、バッジを反転させるには、 カスタムトランジションを使用します。

準拠する構造体を宣言して カスタムトランジションを作成します。 移行プロトコルへ。

移行プロトコルには、ボディメソッドという 1つの要件しかありません。 以前ご紹介した スクロール遷移修飾子のようなものです。 カスタムトランジションの本体には、 コンテンツパラメータが指定されます。 これは、追加または 削除されるビューのプロキシです。 本体には、ビューが表示されている かどうかを示すフェーズもあります。 あるいは消滅する。

体内で効果を適用する フェーズを条件として使用して コンテンツプロキシに渡します。 位相は同一性という性質を持つ。 それは、視界が確保されている 場合に当てはまります。 バッジを裏返すには、 位相が同一である場合は 回転なしで回転3D効果を適用します。

それ以外の場合は 180度プラスまたはマイナス、 表示が現れるか消えるかによって異なります。

不透明度修飾子を適用して、フリップ中に バッジを徐々に非表示または表示します。

カスタムトランジションが定義されています。 そのインスタンスをトランジション修飾子に 渡します。

アニメーションブロックでAの中に トグルが獲得されると、 灰色のバッジがアニメーションで消える そして、色付きのバッジは、 カスタムのフリップトランジションを 使用してアニメーション表示されます。

アプリでカスタムモーションエフェクトを 作成する方法について詳しくは、 この動画をおすすめします。 Web 24 のSwiftUIを使用して カスタム視覚効果を作成します。また、 デザインガイダンスについては、ヒューマンインターフェイスガイドラインの 動作に 関するセクションを確認してください デベロッパで、 モーションエフェクトの使用場所を 検討してください。 アプリではSwiftUIを使用してください。 内蔵されたビューとコントロールにより、 さまざまなモーションエフェクトが 利用できます。 アプリに合わせてこれらの効果を微調整するための 修飾子を自動的に追加します。

状態駆動型アニメーションを使用して イベントに反応する そして、人々の注意を重要なことに向けさせる。 厳選されたカスタムアニメーションで、 あなたのアプリを際立たせましょう。

SwiftUIのモーションエフェクトに 関するこのツアーにご参加いただき、 ありがとうございました。 SwiftUIで何ができるのか、 ご理解いただけたなら幸いです。 それでは、リーアをビッグサーのステージに 再びお迎えしましょう。

最高でした！SwiftUIのおかげで 簡単に個性を出せるのが 本当に素晴らしいですね。 アプリに動きでアクセスする。 緑色の弾むような顔のアニメーションが 気に入りました。 最高だったよ。 次は昼食休憩です。ですから、少し時間を取って 軽食をお楽しみください。 質問したり、新しい人と出会ったり してみましょう。 午後は予定がぎっしり詰まっています そして、1215パシフィックでまた 会いましょう。

休憩を楽しんでいただけたでしょうか。 また、質問する機会もあったでしょうか。 あるいは新しい人と出会うなど、 充実した楽しい午後をお過ごしいただけます。 続いて、同僚のコールが SwiftUI Dataflowの詳細について 解説します。 それでは、皆さんも一緒に ステージへお迎えください。

皆さん、こんにちは。 私の名前はコールです。 Appleでコアテクノロジーの エバンジェリストを務めています。 今日はアプリ内のデータについてお話しします。 そして、それをSwiftUIビューにどのように 反映させるか。 Wishlistアプリは、私が 一日を通して使う素晴らしい例です。 データに遭遇する 可能性のあるいくつかの方法を示す SwiftUIアプリにおけるフロー。

Wishlistアプリも同様の 機能を備えています アプリが必要とする 可能性のあるデータとともに、 そして、対象となるデータの種類に応じて、 異なるアプローチが必要となる。

まず、最も重要なものから説明しましょう。 特定の場所このアプリでは、 インターフェースの状態が変わります 誰かがそれとやり取りするとき。 例えば、誰かが旅行を変更する場合、 アプリは、UIが編集モードになっている かどうかを追跡する必要がある。

さて、この話題はいくつかの異なる 場所で出てくるでしょう。 ボタンをタップした後にシートが 表示されたタイミングを追跡するなど、 または、警告を表示する必要がある場合。 私はこれらのケースを一般的に 「ビュー状態」と呼ぶことにします。

このアプリにはデータモデルも 搭載されています。

Wishlistアプリの目標は 私の素晴らしい旅行や活動から得られた 豊富なデータをすべてお見せするためです。 例えば、この京都旅行では、たくさんの楽しい アクティビティが紹介されています。 寺院を探索するのと同じように、 日の出とともに運河沿いの道を散策するなど。 だから、このデータをアプリ内で モデル化する必要がある。 そして、それをすべてのSwiftUIビューに 反映させます。

アプリは、ユーザーが設定した 好みも記録しておく必要がある。 アプリ内で。例えば、 このアプリには、旅行中のアクティビティ一覧に 並べ替えボタンがあります。 タイトル順、日付順、またはアクティビティの 完了状況で並べ替えることができます。 アプリは、ユーザーが最後に選択した 並べ替え方法を追跡する必要があります。 次回このビューが表示される際に、 同じソート方法が使用されます。

そして最後に、アプリを開発したいと 思っています。 すみません。私は持続性を確保するための アプローチを構築したいのです。 永続化とは、アプリが データを保存できるようにする手法です。 デバイスのストレージに、 ファイルのように保存します。 そうすれば、次回誰かが アプリに戻ってきたときに、 アプリが再リリースされても、彼らが 加えた変更はすべてそのまま残っています。

このセッションでは、 これらのユースケースそれぞれについてさらに 詳しく説明していきます。 詳細な情報。これにはビューの状態に 関するデータも含まれます。 豊富なデータモデルの構築、設定と構成の処理、 そして、粘り強く続けるためのいくつかの テクニック。

このセッションの終わりまでに、 あなたはこれらの各ユースケースについて 推論する能力を身につけるでしょう。 そうすれば、再現できる パターンがわかるでしょう 同様のニーズを自社アプリでも満たすため。 それではまず、ViewStateから 始めましょう。

先ほども申し上げましたが、 アプリによっては、単にデータを作成する 必要がある場合もあります。 インターフェース自体の状態を追跡するため。 これらの現象は多くの場合一時的なものであり、 表示が消えた場合は リセットしても問題ありません。 例えば、サンプルアプリは旅行が 編集モードになっているかどうかを追跡します。 あるいはそうでないかもしれない。もし 誰かがこの旅から離れて航行した場合。 そして後でまたそれについて話す、 UIが編集モードではなくなった のは当然のことだ。 たとえ私が「完了」 をタップしなかったとしても。 インターフェースで追跡する 必要のある状態の別の例を以下に示します。 このアプリの「ウィッシュリスト」 タブにあります。 ツールバーに「追加」ボタンがあります。 さて、カートは以前、 アニメーションを改良する 際にこのボタンについて話していました。 このボタンをタップすると、 誰かが作業を開始できるシートが表示されます。 アプリに追加する 新しい旅行の詳細を入力します。

そのため、アプリは、または、 シートが現在画面に表示されているかどうか。

また、シート自体には、 変更を保存したり、旅行の追加をキャンセルしたりする ボタンがあります。 そのため、シート内のアクションには 状態を更新する方法が必要になります。 そうすればSwiftUIがシートを閉じます。

それでは、SwiftUIでこの追加ボタンを 実装する方法をご紹介します。 WishlistView の本体に シートを配置すると、 シンボルラベル付きの SwiftUIボタンがあります。 そして、シートを表示させるために、 ボタンのアクションに コードを追加する必要があります。

シート自体を提示する。 ビューに追加されるシートのisPresented修飾子を 使用する必要があります。

さて、このコードを完成させる前に、 SwiftUIは私に決断を迫っています。 追跡するデータは何ですか？ それとも、このシートは実際に 今画面に表示されているのでしょうか？

これは、 at state API を使用するのに 最適なユースケースです。 仕組みはこうです。isPresentingAddTrip という 新しいプロパティを作成します。 そして、それを at state を使用して装飾すると、 デフォルトは false になります。 `at state` を使用すると、 SwiftUI は永続する 新しいデータを作成するように指示されます。 この見解が続く限り。 この値の寿命については後ほど 詳しく説明しますが、今のところは、 これで定義できたので、 ビューの残りの部分で使用できます。 ボタンのアクションで、 isPresentingAddTrip を true に設定します。 ボタンをタップすると必ず シートが表示されるはずなので、 シートが既に表示されている場合は、 ボタンを無効にします。 状態をdisabled修飾子に 渡すことによって。

ビュー本体はisPresentingAddTripの 値を読み取るので、 この修飾子では、WishlistView はこの 値への依存関係を確立します。 いつでもプレゼンテーション可能です。 旅行の変更を追加すると、 SwiftUI がこのビューを更新します。

シート修飾子にもisPresentingAddTripプロパティを 渡します。 このドル記号表記により、バインディングをこの 状態に渡すことができます。 このコードがこの値をシートと 共有できるようにすることで、 両方から読み取ることができます。 そして、それを変更する。 バインディングについて、後ほど 詳しく説明します。

物件を装飾する` at state` は、このプロパティが 囲んでいるビューによって所有されている ことをSwiftUIに伝えます。

この物件の価値は、 その眺望が存在する限り存在する。

そしてこれは、先ほど少し触れた重要な点です。 状態プロパティがインターフェース内の ビューの寿命と一致する場合、 ビュー構造体自体の存続期間ではありません。 それでは、これが実際にどのように 機能するのか、もっと詳しく調べてみましょう。 リアが今日先に話したように、 SwiftUIのビューは、テンプレートのように、 一時的な説明文にすぎません。 WishlistViewがインターフェースに 表示されると、 SwiftUI は画面上の UI を更新するために本体を実行します。 しかしその後インスタンスを破棄し、

そしてこれは、SwiftUIがビューを レンダリングするたびに繰り返されます。

では、なぜ isPresentingAddTrip プロパティは リセットされないのでしょうか？ デフォルト値が false なので、 このビューが再初期化されるたびに発生します。

それはSwiftUIが特別な扱いをするから このような州有地では。

舞台裏では、SwiftUIは 独自のデータストレージを持っています。 州が所有するすべてのビューについて。 SwiftUI がこのビューを 初めてインスタンス化するとき、 内部ストレージにスペースを割り当てます この物件は、他の景色とともに州が 所有するすべての物件と並んでいます。

このストレージは、ビューの識別子によって インデックス付けされます。

同一性を対応するものとして考えてください このビューのレンダリング結果が 画面に表示される期間。 つまり、SwiftUIが ビューを初めてレンダリングするときに、 ビューにIDを割り当てます。 そして誰かがこのビューから移動すると、 SwiftUIはストレージから そのエントリを削除します。 後で景色を見に戻ってくると、 SwiftUIは新しいIDを割り当て、 ストレージ内に新しいエントリを割り当てます。

それでは、シートを表示するボタンでこれがどのように 機能するかを説明します。 誰かが初めてウィッシュリストビューに 移動したときにタップされます。 SwiftUIはストレージを割り当てます このビューの isPresentingAddTrip 状態プロパティには、 デフォルト値を使用します。 値はFalseです。

次に構造体をインスタンス化する そして、isPresentingAddTrip の値をSwiftUIの 内部ストレージに一致するように設定します。 そして、WishlistView の本体を 実行して画面にレンダリングします。 そしてビューインスタンスを破棄します

アプリを使用している ユーザーがボタンをタップすると、 アクションクロージャ実行設定は広告トリップを trueに表示します。 しかし、これは州の所有物であるため、 この課題はSwiftUIの 内部ストレージを変更し、 ビューの本体はこの状態に依存しているため、 SwiftUI は更新をトリガーします。 isPresentingAddTrip の値を 設定する新しいビュー構造体を作成します 実行ボディの前に内部ストレージから 取得した新しい真の値を使用します。

つまり、この内部ストレージは SwiftUIが状態を維持する方法です インターフェース内のビューの存続期間中。 構造体自体は 一時的なものであるにもかかわらず。

なるほど、この内部ストレージは、 この状態プロパティがSwiftUIに 問い合わせる方法を説明しています インターフェース内のこのビューの存続期間中、 ブール値を追跡します。 しかし、状態は単一のビュー宣言内だけでなく、 他の場所でも役立ちます。 また、バインディングと呼ばれるものを使って、 他のビューと共有することもできます。

シート修飾子にあるこのドル記号を使うと、 バインディングにアクセスできます この isPresentingAddTrip状態にします。 バインディングとは、アプリ内の何らかの 状態への読み書き可能な参照のことです。

ビューを作成する際に、囲んでいるビューから 値を読み取り、その値を変更する 必要があるかもしれません。

バインディングはSwiftUI全体で 使用されています。 それらは、トグルとテキストフィールドの パラメーターの中にあります。 シート修飾子など。 これらは、このデータに依存し、 それを変更できるカプセル化された制御です。 必要に応じて。 例えば、旅行追加ビューの 抜粋を以下に示します。 これは、シート自体の内部ビューです。

バインディングを使用して、 囲んでいるビューから参照を受け取ります。 シートがビュー本体に 表示されているかどうかを追跡する状態へ。 シートを閉じることができるボタンがあります。 これを実現するために、 isPresented バインディングの値を false に設定します。 彼らの行動の終結において。 これにより、 SwiftUI は 依存するすべてのビューを更新します。 私のような州で。 画面を閉じると、シートが閉じられます。

私のシートのような、ただ追跡したい場所 誰かがインターフェースを操作する 際に、これは最適です。 状態。これは一時的なデータであり、 ビューが消えるとリセットされるはずです。 または、ビューが存在する間だけ 存在すべきオブジェクトがある場合。

しかし、状態は私のデータモデルのような 他のタイプのデータには 最適ではありません。 そのような場合、状態の種類を表現する 方法が必要になります。 コードの他の部分によって 所有されているSwiftUIに対して、 UI自体が所有するものではありません。

そこで、次のユースケースであるWishlistの データモデルについて説明します。 データモデルはこのアプリの心臓部であり、 魂そのものです。 アプリに戻ってくるために 必要な情報がすべて含まれています。 例えば、各旅行の名前や 写真、アクティビティなどです。 この例のように、 旅行対象の名前はペルーオフロードです そして、この素敵な写真が添えられています。

これらのオブジェクト間にも関係性が存在する。 例えば、旅行には複数のアクティビティや アクティビティが含まれることがあります。 名前などの独自の属性を持つ そして、アクティビティが 完了したかどうかを追跡するためのブール値。

そこで、旅行を表すクラスを使った データモデルを作成しました。 そして、このアプリ内のアクティビティ。 各クラスには、名前、写真、日付などの属性を 格納するためのプロパティがあります。

また、それらは互いへの参照を順番に保存します これらのオブジェクト間の関係をモデル化する。 例えば、旅行オブジェクトには 任意の数のアクティビティを 関連付けることができます。 アクティビティプロパティにそれらへの参照を 保存することで、それらと連携します。

また、これらのオブジェクトは編集可能で、 ユーザーがUI上でこれらのプロパティを 変更する可能性があるためです。 例えば、誰かがテキストフィールドで 旅行の名前を編集した場合など。

DataSourceというクラスも 作成しました。 アプリ内でこれらのオブジェクトすべてを 管理するため。 アプリが必要なすべてのオブジェクトを 検索できる単一の場所です UI上に表示する、例えば 全ての旅行のリストを取得するなど。

このようなデータモデルを持つことは、 素晴らしい出発点となります。 しかし、このデータモデルをSwiftUIで 実際に使用するには、 1つ簡単なものを追加する必要があります。

データモデルは、そのプロパティに 変更が発生したときにそれを 認識できる必要があります。 SwiftUIがUIを 更新できるようにするためです。

そして、これこそがObservableマクロの 目的です。 この1行のコードで、 SwiftUIにプロパティへの依存関係を 確立する権限を与えることが できます授業で。

Observableマクロは、各クラスの プロパティに更新追跡機能を追加します。 これを使用するには、 各クラスに at Observable マクロを追加するだけです。

データモデルがObservableになった ので、 SwiftUIは、モデルのプロパティに 直接依存関係を設定できるようになりました。

この例では、TripCard ビューは 参照を受け取ります 表示すべき旅行オブジェクトへ。

いいえ、ありません。 状態または拘束時。 実際、この資料には装飾は一切ありません。 このビューが機能する理由は、ビュー本体の中に 次のように書かれているからです。 旅行の写真URLプロパティ。 これは、SwiftUIがこの Observable クラスの photoURL プロパティが変更されるたびに更新します。

そして、これは計算プロパティを 通しても同様に機能します。 例えば、プレースホルダー写真を 使いたいとしましょう。 まだ写真が保存されていない旅行の場合。 UIでこれを処理するには、 TripオブジェクトにphotoURLまたは placeholderという名前の計算プロパティを 定義することができます。 この計算プロパティは、 プレースホルダー写真が定義されていない 場合は、プレースホルダー写真を返します。 旅行のために。そして、 その新しい計算プロパティを使用します。 photoURLの代わりに、 ビュー本文に記述します。

SwiftUIは、基となる プロパティphotoURLが 赤色であることを判別できます。 このビュー本体で、 計算プロパティにアクセスしたとき。 そのため、SwiftUIは 基となる写真のURLが変更されるたびに TripCardを更新します。

まとめると、このアプリはTripの 構造化データモデルを使用しています。 およびアクティビティオブジェクト。 各オブジェクトをモデル化するために 参照型またはクラスを使用します。 そうすることで、参照を用いてこれらのオブジェクト間の 関係をモデル化することができる。 そして、これらのプロパティは UI上のどこからでも簡単に編集できます。

これらのクラスのデータを SwiftUIに渡すには、 それぞれの定義に、 at Observable マクロを追加するだけです。 そうすれば、SwiftUIビューは ビュー本体内でプロパティを直接読み 取ることができます。

さて、あと一つやらなければなら ないことがある。 これまでご紹介した方法は 非常にうまく機能します。 ビューが既にTripのようなオブジェクトへの 参照を持っている場合。

さて、先ほど私は、 これらのオブジェクトはすべて DataSourceクラス、 しかし、ビューにどのデータソースインスタンスを 使用するかをどのように 指示すればよいのでしょうか？

実は、その方法の一つについては 既に説明しました。 そしてそれは州レベルで始まる。

状態において、存在するオブジェクトを 作成することを思い出してください。 ビューと同じように。アプリの上部には、 データソースオブジェクトを保持する 状態プロパティを作成できます。 このアプリの宣言で状態を指定すると、 オブジェクトが作成され、 アプリが行うように、 そしてビューに渡すことができます。

これは、このアプリの非常に シンプルなビュー階層にはうまく 機能するかもしれません。 UIのさまざまな部分がデータソースに アクセスする必要がある場合があります。 例えば、旅行の全リストを取得するには そして非常にシンプルなビュー階層で、 DataSourceのようなオブジェクトをそのまま 渡すのは 全く理にかなっています。 それを必要とする人々の見解へ。

しかし、アプリが複雑化するにつれて、 このやり方は次第に煩雑になる可能性がある。 ネストされた使用レイヤーが 多数あるアプリは、最終的に データソースへの参照を保存し、 そうすることで、それを必要とするより 深い視点へと伝達することができるのです。

この問題を回避するために、 このようなケースは、 その環境に適していると言えるでしょう。

環境を本質的な特性として考えてみましょう これらはアプリの一部を構成するもので、 頻繁に変更されるものではありません。

この場合、データソースオブジェクトを 状態として作成します。 そして、そのオブジェクトを ビュー環境に設定します。 これは、データソースを必要とする ビューを設定します。 この特定の事例において。

これは、データソースオブジェクト自体が 交換されないため安全です。 非常に頻繁に出ます。それは観察可能です そして、さまざまな見解がある 私のアプリでは、それへの参照が 必要になるかもしれません。 つまり、データソースを 環境内に配置することで。 それへの参照が必要なビューは、 直接参照を取得できます。

環境は、それが適用される ビュー階層全体に流れます。 ビューは環境から値を要求するだけでよい そして、 SwiftUIがそれを提供します。 例えば、ビュー階層のさらに深いところでは、 RecentTripsPageView は参照を 取得します 環境内のプロパティを装飾することで、 データソースに追加します。 SwiftUI はこの参照の値を設定します 環境内の、一致する型のオブジェクトと。

DataSourceは Observableなので、 ビューは依存関係を確立できます ビュー本体内から直接、 そのプロパティにアクセスできます。ここでは、 最近追加された Trips プロパティがこのビュー本体で読み込まれます。 そのため、最近の旅行ページビューは 新しい旅行があるたびに更新されます 旅行プランがアプリに追加されました。

ViewStateと私のデータモデルは、 私が必要とするデータフローの 大部分をカバーしています。 このアプリでは今のところこれだけですが、 他にもいくつかユースケースがあります。 少し異なるアプローチを取るもの。 それでは、引き続き好みについてお話しします。 そして、このアプリの設定。

先ほど述べたように、 誰かがトリップをタップすると、 表示されるアクティビティのリストを名前順に 並べ替えることができます あるいは、それらが 完了しているかどうかによって。 アプリはこの設定を保存する必要があります そのため、誰かがこの見解に至ったときには、 彼らが好む並べ替え方法を使用します。 さて、好みはうまく合わない 先ほど説明したデータモデルの内部に入ると、 これは旅行そのものとは 全く関係がないからです。 これは人々の好みを追跡するものです アプリのさまざまな機能を使用する。

そこで、このソート機能を構築するには、 まず、状態を使用して 新しい状態を定義することから始めます。 使用されているソート方法を追跡するため。

この例では、sortOption と 呼ばれています。 そして、アクティビティサブビューは ソートオプションを読み取ります 活動内容を説明する際に。

これでうまくいき、アクティビティは 誰かが選んだものに基づいて 並べ替えられるようになりました。 メニューに。

しかし、このような状態プロパティは 保存されるだけであることを思い 出してください。 その景観が維持される限り。 つまり、誰かがこのビューを 離れてから戻ってきた場合、 並べ替えは常にデフォルトの タイトル順に戻ります。 旅行の詳細ビューに戻るたびに、 以前選択したのと同じ方法で 並べ替えられています。

そのためには、AppStorage の 状態を次のように変更します。 そして、設定に固有の識別子を提供する。

AppStorage はステートと 非常によく似た動作をします。 これはアプリ全体に 共通する状態の一部を宣言します。 そして、シンプルなCodable型で 最も効果を発揮します。

AppStorageの値は 実際には自動的にディスクに保存されます。 内部的には、Appleプラットフォームの User Defaults と呼ばれる API を使用しています。 これは、アプリで使用する キーと値のセットを保存します。

そしてここは設定に最適な場所です。 設定およびアプリ構成の詳細。

そこで、アプリのストレージプロパティに 並べ替え設定を保存することで、 アクティビティは常に、 誰かが最後に選択したオプションで 並べ替えられるようになりました。 彼らは様々な旅をしながらも、 その景色を眺めている。

最後に、本日議論したい ユースケースは永続化です。

先ほどお見せした例では、 その並べ替え設定を保存しました。 AppStorageを使用することは、 実際には永続化の一例です。 SwiftUIは自動的に ユーザーデフォルトAPIを使用します このキーの値をディスクから取得するには、 そして、ビュー内の値をそれに 合わせて設定します。

また、sortOption に 別の値が割り当てられている場合は、 AppStorage はその新しい 値をユーザーデフォルトに保存します。 だから、誰かがあなたのアプリに1日後、 あるいは1週間後に再びアクセスしたとしても、 または1か月後、 sortOptionプロパティはそのままになります 変更されるまでは同じです。

しかしもちろん、こだわり 続けるべきなのは好みだけではありません。 このアプリには、このような豊富な データモデルがあります。 そして人々は間違いなくウィッシュリストを 数日間保存しておきたいと思うだろう あるいは数週間以上。

アプリでこのような永続的な データモデルを構築するには、 優れた選択肢の一つとして、 SwiftDataが挙げられます。

SwiftDataは、アプリに永続性をすばやく 追加できるフレームワークです。 最小限のコードで、外部依存関係もありません。

マクロやプロパティラッパーなどの最新の Swift言語機能を使用しています。 これにより、Swiftコードを書くだけで モデルを記述できるようになります。

デフォルトでは、Core Dataの実績ある 永続化機能を活用します。 SwiftDataの技術とモデルはすべて 自動的に観測可能です。

SwiftDataについてもっと知りたい 場合は、ビデオをご覧ください。 SwiftDataをご紹介します。 そして、SwiftDataを使って アプリを構築します。 先ほどお話ししたように、データモデルはいくつかの クラスで構成されています。 そしてその各属性そして、 それらの間の関係は プロパティとして保存される。 これらの各クラスについて。 そして現在、これらのクラスにはObservableマクロが 付加されています。

しかし、SwiftData を使用してそれらを 永続化したい場合は、 Observableマクロをmodelマクロに 置き換えるだけでいいでしょう。

このモデルマクロは、これらのクラスを SwiftDataモデルに変換します。 そしてこれもまた、自動的にそれらを Observableにする。

そこで、楽しい練習として、 サンプルコードが利用可能になった らダウンロードしてみてください。 そして、このアプリをSwiftDataに 移行するためのいくつかの手順を実行します。 それに興味のある方は、 コードの中で変更すべき 重要な点をいくつか説明します。 まず、モデルにメタデータを 追加する必要があります。 アプリのビュー内からデータを取得または クエリする方法を洗練します。 そして、モデルを保存するための コンテナを設定します。 それでは、それぞれのステップについて 簡単に説明していきます。

まず、モデルをat Observableから at modelに切り替えた後、 モデルを見ていきます そして、必要な場所にプロパティを注釈します SwiftDataに彼らに 関するより詳細な情報を提供するため。 例えば、トリップモデルでは、 アクティビティプロパティのリレーションシップを 使用できます 旅行とアクティビティの関係性を定義する。 ここでは、削除ルールをカスケードに 設定しているので、旅行が削除されると、 その活動履歴もすべて削除されます。

また、旅行プロパティの逆関係を「申し 訳ありません」に設定しました。 旅行プロパティとアクティビティの逆相関関係。 つまり、これらのアクティビティの 旅行プロパティは常に元の場所に 戻るということです。それが属する旅行へ。

SwiftDataを使えば、 フェッチが非常に簡単になります。 そして、クエリを使用して ビュー内にモデルを表示します。 SwiftDataにソートされた モデルの配列を要求するだけで済みます。 そして、お好みの方法で フィルタリングできます。 このコードスニペットでは、 先ほどお見せした RecentTripsPageView を更新しました。 以前はデータソースオブジェクトを 使用していましたが、 最近追加された旅行のリストを取得するには、 しかし、SwiftData を使用すれば、 代わりに Query を使用できます。

このクエリは、SwiftDataに対して、 ソートされた旅行の配列を提供するよう 要求します。作成日順（降順）

ビュー本体は、最近追加されたこの trips 配列を ForEach で使用します。

クエリ結果が変更された場合、SwiftData はこの ビューを更新します。 例えば、新しい旅行が ビューに追加されたときのように。

そして最後に、アプリ宣言では、 モデルを保存するためのコンテナを 使用してアプリを構成します モデルコンテナ修飾子を追加することで そして、モデル型の名前を渡します。 アプリはモデルにデフォルトの コンテナを使用します。

つまり、これら３つの変更点です。 プロパティのメタデータを追加します。 クエリを洗練させ、 次にモデルコンテナを追加することが、 始めるための鍵となります。 これにより、SwiftDataはこのような アプリに 強力な永続化機能をもたらします。

これで、ウィッシュリストアプリのデータフローの ユースケースをすべて説明しました。 そして、SwiftUIアプリでも 同様のアプローチを取ることができます。 アプリのビューが単純な UI 状態を追跡するだけでよい場合、 ボタンがタップされたときのように、 状態を使用し、バインディングを使用して 他のビューにアクセスできるようにします または、制御がその状態の一部を共有します。

構築中のリッチデータモデルには、 Observableマクロの使用を 検討してください。 クラスなどの参照型と組み合わせる。

データを保存したいとき。 データをストレージに保存して、 永続的に保持しましょう。 設定や環境設定などの小さなデータは AppStorageに保存してください。 モデルデータにはSwiftDataフレームワークの 利用を検討してみてください。 お時間をいただきありがとうございました。 イベントの残りの時間を楽しんでくださいね。 さて、リアの話に戻りましょう。ええ。

素晴らしかった。時間をかけることはとても 大切だ。 データフローの基本と、 各ツールをいつ使用すべきかを学ぶ。

続いては、AllTrailsのCTOであるジェームズ・ グラハム氏を特別ゲストとしてお迎えします。 複雑な環境からSwiftUIを導入した 経験について共有します。 成熟したUIKitアプリ。 ぜひご参加ください。ジェームズさんを ステージにお迎えしましょう。

皆さん、おはようございます、 またはこんにちは。 あなたに質問があります。 もしかしたら、共感できるかもしれません。 これまで、既存のUIKitコードベースを 見直したことはありますか？ 4年前に書かれた巨大なビューコントローラーを 見て、 「うわっ」と思ったのかもしれない。 これは大幅なリファクタリングが必要だ。 いったんこの件は保留にして、 全体を再構築しましょう。 そして、SwiftUIについて 簡単な挙手発表をお願いします。 あなたにもこのような経験はありますか？ わあ。すごい。たくさんの人が 手を挙げているのが見える。 オンラインで視聴している 人はもっと多いはずです。 魅力的な考えだが、 我々が運営する規模では書き換えは、 エンジニアの努力によるものか、 AIネイティブのワークフローによるものかに 関わらず、 それは大きなリスクをもたらす。 こんにちは、私の名前は ジェームズ・グラハムです。 私は AllTrailsのCTOです。 そして今日は、書き直しをせずに 現代的なスピードを実現した 方法についてお話しします。 SwiftUIに強制的に 私たちを採用させるのではなく、 どのようにSwiftUIに 私たちを採用させるかをお見せしたいと 思います。トップダウン方式での導入。 本題に入る前に、まずは 物語の概要を説明しましょう。 まず、AllTrailsとは何か、 私たちの規模、そして 制約についてお話しします。 次に、コードベースを書き 換えることなくSwiftUIがどのように 導入されたかについてお話しします。 あるいは、委任状が必要になるかもしれません。 その後、転換点をお見せしましょう。 SwiftUIが実験段階を終えたとき そして、デフォルトの選択肢になり始めた。

最後に、今日の状況について お話しして締めくくりたいと思います。 そして、私たちがハイブリッドアーキテクチャをどのように 捉えているかについても。 当社の技術的な意思決定を理解するには、 当社の規模を理解する必要があります。 今日、 AllTrailsは世界で最も人気のある そして、アウトドア探検のための 信頼できるプラットフォームです。 私たちの使命はシンプルです。 世界中の人々が外の世界へ出る 道を見つける手助けをすることです。 私たちは人々がトレイルを 発見するのを手伝います。 自信を持って道案内をし、 トレイルでの体験をより充実させる。 トレイルの最新情​​報や フォトツアーなどの機能を備え、 道中の写真がハイライト表示される。 近所の公園を散歩するにしても、 数日間のハイキングをするにしても、 ご安心ください。 AllTrailsには9000万人以上の コミュニティメンバーがいます。 世界中に50万のトレイルがあります。 そして、会員の皆様の走行距離は 累計19億マイルを超えています。

私たちは14の言語で対応しています。 つまり、私たちが下すすべての技術的な決定は、 さまざまなデバイス、 さまざまな地域にわたる数百万人の会員、 重要なのは、接続レベルの違いです。

私たちは、さまざまな興味や嗜好を持つ 幅広い層の会員にサービスを提供しています。 一方、手軽さを求める カジュアルメンバーもいます。 そして、地元の湖の素敵な景色を眺めながら、 比較的平坦な午後の散歩を楽しめます。 そしてその一方で、全行程に 挑戦する熱心なハイカーがいます 携帯電話の電波が届かない場所で、 オフラインナビゲーションを使って ハーフドームへの日帰りハイキングを行った。 その多様性は信頼性、バッテリー寿命、 そしてUIのパフォーマンスも重要です。 不具合のあるコードを出荷することはできません が、 私たちのアプリは静的なものではありません。 新しい表面や新しい機能の深度によって、 常に進化し続けています。

SwiftUIが登場した頃には、 それは約束されていた。 AllTrailsは既に 非常に大規模で成熟した、 成功を収めているUIKitアプリだった。 その進化の一例として、長年にわたる 当社のホームページの変遷をご紹介します。

私たちは毎週リリースサイクルで 出荷しており、両方とも無料で そして有料体験。

そして、私たちの遺産について私が 言いたい最も重要なことはこれです UIKitのコードは 修正すべき問題ではなかった。 それは、私たちの規模拡大を 可能にした基盤でした。 そのため、遊歩道を閉鎖して 変更を加えることはできませんでした。 私たちはそれを維持し、 アップグレードする必要があった。 ハイキング中盤。

SwiftUIが登場したとき、 それは私たちが切望していたものを 実現すると約束していた。 データが変更された際に自動的に更新される、 よりクリーンな状態管理ビュー。 UIの同期がずれるバグを全て排除する モデルレスコードを使用。 UIKitの同等機能と比較すると、 40% の削減になります。 つまり、保守、更新、 そして読み取る必要のあるコード量が 40% 削減されるということです。

ライブプレビュー機能により、デザイン変更を 即座に反復できます。 しかし、既に成熟したアプリを書き直すことは、 技術的にも組織的にも選択肢にならなかった。 私たちには別のアプローチが必要だった。 こうしてSwiftUIは静かに 私たちのコードベースに組み込まれた。 それは義務付けられた事項でも、 ロードマップ上の項目でもなかった。 私たちはサンドボックスを作成しました。 そして、プロトタイプの低リスク実験に 利用しました。 そして、孤立したサービス。 これにより、リリース候補版を危険にさらすことなく フレームワークを学ぶ機会が得られました。 それについて。

最初の本当の決断は、UIKitかSwiftUIかという ことではなかった。 彼らはどのようにすれば共に成功できるのか？ 私たちは早期から 相互運用性に投資してきました。 こちらのコードスニペットをご覧ください。

これが私たちの架け橋です。 私たちは、トレイルコーディネーターのような SwiftUIの機能を活用します。 HostingViewでラップします そして、それを標準のUIKit StackViewに 直接配置します。

そしてそれをScrollViewに 追加します。

このページを下にスクロールすると、 HostingView の一部には、 SwiftUI のサブビューが 含まれています。 私たちは早い段階でこの パターンを確立しました。

これはプロセス上の決定でした。 境界線が明確であることを確認する そして、二つの世界は同じ 言語を話すことができた。

時間が経つにつれて、 自然に2本の平行な線路が形成される。 UIKitが依然として 多くの面倒な作業を代行してくれる。 アプリのライフサイクルナビゲーションと複雑な あるいは、トレイルページや コミュニティアクティビティのような、 深く統合されたサーフェス。 成人向けアプリでご覧ください。 安定版を書き直すのは意味がなかった。 戦闘で鍛えられた スクリーンをフレームワークを 変更するためだけに、そのため、 私たちはハイキングの途中でよく 整備されたトレイルのルート変更を避けることが できました。そして、明確なユーザー成果をもたら す分野に新たな投資を集中させた。 そして、SwiftUI側での 開発速度の向上も実現しました。 私たちは意図的に、孤立した人々にとって 最も適した場所でそれを使用しています。 境界が明確な曲面、 重厚な景観の表現、そして新たな試み。

ここにその例を2つ示します。 トレイルレビューフローは、動的な状態を持つ 自己完結型の表面です。 そしてUIの更新は、SwiftUIの 宣言型モデルによく合致しています。

Apple Intelligence をベースに構築された、 トレイルに何でも質問できる 機能は比較的新しいものです。 より実験的なサービス。 SwiftUIを使えば、 ここで素早く反復作業ができます。 そして、それを密接に 結びつけることなく、体験を進化させる。 アプリの中核となるアーキテクチャへ。

SwiftUIがデザインシステムとして 非常に優れているもう一つの分野。 アプリを見てみましょう デバッグモードでは、Denaliと呼ばれる デザインシステムを視覚化します。 デナリは日々大きくなっており、 デザイン、システム、設計、 エンジニアリングチームすべての 新機能がこのシステムを 活用するようにするため。

当社のコアコンポーネント、 ボタン、セグメント、コントロール、 ここに表示されているバッジは、 当社のデザインシステムの一部です。 デバッグモードでアプリ内で表示可能で、 現在はSwiftUIで構築されています。

かつては何百行もの定型文が必要だった。 では、そのごく一部を取り出そう。 そして、新しいバリアントを追加したり、 間隔を調整したりする必要がある場合、 それは、あらゆる場所に波及する単純な変化だ。 SwiftUIを使うことで、 コードベースを肥大化させることなく、 デザインシステムを拡張できます。

SwiftUIを採用した際に、 予期せぬ事態が発生したことにも気づきました。 それは私たちの建築様式に影響を与え始めた。

ビューモデルは小型化され、 多くの場合3分の1に縮小されました。 なぜなら、UIと状態を同期させるためだけに、 グルーコードを書くのをやめたからです。

また、配管に関する明示的な記述を大幅に 減らし、出版社や運営者も減らしました。 ライフサイクル管理ははるかに少ない なぜなら、SwiftUIが 状態伝播を処理してくれたからです。

UIの状態と動作が一体となっているため、 変更箇所は少なくて済んだ。 UIのプルリクエストは 30 ～ 40% 小さくなりました そして、コードレビューのスピードが 目に見えて速くなった。

その時、SwiftUIはUI実験のように 感じられなくなった。 そして、それがシステム構築の 正しい方法だと感じ始めた。 私たちはエンジニアにSwiftUIの 使用を強制したことは一度もありません。 彼らがそれを新しい仕事に選んだのは、 摩擦が少なかったからだ。 それは認知負荷を軽減した。

適切な選択をすれば、 コード導入率を 40% 削減しても、 それが自己持続的な効果をもたらす。

これが私たちにとっての教訓です。

SwiftUIが普及したのは、 私たちが人々に使うように 勧めたからではありません。 それが広まったのは、 それが最も速い前進方法だったからだ。 フレームワークが認知負荷を軽減し、 複雑さを取り除くと、 エンジニアは説得される必要はない。 私たちはただ、それに手を伸ばすだけだ。 しかし、コードベースは 一夜にして変わったわけではありません。 それは傾いた。UIKitは 依然として深く組み込まれている。 SwiftUIはそれを中心に発展してきた。 機能ごとのコード行数の削減などの 成功指標を測定します。

より速い反復サイクル、 そして、それらの個別のSwiftUI機能における 不具合も減少しました。

相互運用性はインフラであると 私たちは認識しました。 私たちはホスティングラッパー、 共有アニメーションに投資しました。 橋梁、そして統一されたテーマ設定。 橋がしっかりしているときは、 SwiftUIは目新しさを感じさせなくなり、 基礎的なものへと変化していく。

その完璧な例が、当社の Apple Watchアプリです。 当社のコンパスとマップのサーフェスはどちらも SwiftUIで構築されています。 そして、私たちの地図は MapKitを使用しています。 これは、重要なパフォーマンスをどのように 提供できるかを示しています 現代的な建築技術を用いた、繊細な機能性。

ここでSwiftUIを選んだのは、 それがクールだからではなく、 しかし、それはより速い 反復を可能にしたからです 複雑なサーフェス上で、 従来のナビゲーションロジックに 手を加えることなく動作する。

さて、私たちは今日、どこにいるのでしょうか？ AllTrailsはSwiftUIに 移行されていません。 メリットを得るために、 アプリ全体を書き直す必要はありません。 私たちは方向性を持った ハイブリッドシステムです。

UIKitは安定性を提供します。 複雑なコレクションビューなど、高度なUIカスタマイズには 依然として最適です。 あるいは複雑なナビゲーションバー。

SwiftUIは私たちの 成長を象徴するものです。 急速に追いついてきて、 そして、ここに掲載されている植物識別機能は、 100% SwiftUIで作成されています。

これまで説明してきたことはすべて、 AllTrailsのスケールに 特有のものです。 私たちのメンバー、私たちの制約。 そしてそれは意図的なものだ。

チームがよく犯す間違いは、導入を二者択一の 選択肢として捉えてしまうことだ。 SwiftUIを採用すべきでしょうか？ より良いフレーミングは。 どのような条件下で、 導入はリスクではなく勢いを生み出すのか？

実際に効果があったのは、 バグの減少、配送の迅速化、 チーム間の連携をより円滑に。 それは単一の技術的な選択ではなかった。 それは意図的に下された一連の決定だった。

よく聞かれる質問の一つに、 UIKitとSwiftUIは 安全に共存できるのか、というものがあります。 そして、私が今日お見せした内容から 判断すると、答えは間違いなくイエスです。 だから、何を採用すべきかを 指示するのではなく、 最後に、採用を評価する際に 使える3つの質問をご紹介します。 あなた自身の文脈において。 一つは、相互運用性をインフラストラクチャとして 扱うかどうかです。 相互運用可能な相互運用性が 脆弱または場当たり的である場合、 実際の製品に対するプレッシャーがかかった 瞬間、普及は停滞するだろう。

２．この新しいツールは認知負荷を軽減するか？ ツールが本当に精神的な負担を軽減する場合、 養子縁組には強制は必要ない。 エンジニアはそれを自発的に選択するだろう。

そして3つ目は、コンバージョンではなく、 勢いを測定しているということですか？ 勢いは、プルリクエストの規模縮小、 レビューの迅速化、リグレッションの 減少という形で現れる。 コードベースのどれだけの部分を変換したか、 ということではありません。

だから、ここから何か教訓を得るとすれば、 つまり、進歩するために書き 直しは必要ないということだ。 あなたには方向性が必要です。 今日は貴重なお時間をいただき、 本当にありがとうございました。 そして、AllTrailsのストーリーを 共有させてくれたことに感謝します。 トレイルでお会いしましょう。

ジェームズさん、本当にありがとうございます。 SwiftUIがいかに機能のリリースを 容易にするかを直接聞くのは刺激的だ。 メンテナンスの手間も軽減され、 そして、SwiftUIが UIKitのコードベースとこれほど スムーズに共存できるということ。 私はAllTrailsの大ファンです。 そして、舞台裏でどのように 作られているのかをもっと知ることは、 私にとって楽しいことです。 よし、もう一度休憩を取ろうそして、 225 Pacificに 戻ってリーダーたちとのパネルディスカッションに 参加しましょう。 SwiftUIエンジニアリングの分野で。 それではまた。 休暇を楽しんでいただけたなら幸いです。 それでは、SwiftUIエンジニアリングの 分野で 活躍する3人のリーダーによる パネルディスカッションの時間です。 それでは、ニック、ラッセル、 テイラーをステージにお迎えしましょう。

リーア、いいね。

これまで皆さんと一緒に仕事をする機会に 恵まれましたが、視聴者の皆さんのために、 自己紹介と、もう少し詳しい お話を聞かせてください。 Appleにはどれくらい勤めていますか？ ええと、私の名前はニック・タイラーです。 私はAppleに約6年間勤務しています。 私は最初にMapKitチームに 加わりましたが、それはすでに夢が 叶ったようなものでした。 MapKitのエンジニアがどのようにして オブジェクト指向プログラミングの 先駆者であり、 そして、Nextにいた人たちと一緒に 働く機会は今でも本当にあります。 そして当時のAppleも。 そうやって私は入社することになったんです。 すごくかっこいい。 私はラッセルです。今は SwiftUIのマネージャーをしています。 しかし私はAppleに9年間勤めています そして私は主にUIKitのエンジニアでした ごく最近まで、私のキャリアのほとんどの 期間においてそうでした。 そして、大学を卒業してすぐにここに来た。 私はテイラーです。13歳なので、 ここで一番年上だと思います。 私もずっと昔にSwiftUIに 移行した時と同じように MapKitから始めました。 そしてつい最近、まさに 一周回って元の場所に戻ってきた。 MapKitとCatalystに 関する一部の責任を復活させる。 ここに来られて本当に嬉しいです。 皆さんが相互運用性について話しているように 感じます MapKit、 UIKit、 そして、 あなたの経歴と経験だけで SwiftUI習得できます。では、 あなたが性別移行を決意した動機についてもう 少し詳しくお聞かせください。そして、 SwiftUIについて、 そしてそのフレームワークの好きなところについて 考えてみてください。 さて、Appkitの人たちと仕事をした後、 オブジェクト指向設計の先駆者であった テイラーを見かけました 別のチームでは、宣言型フレームワーク設計の 先駆者として活動している。 だから、そこが次に行くべき 場所だと本当に思ったんです。 ええ。つまり、それに加えて、 宣言的、断定的な表現が、 私を惹きつけた理由の一つでもあるんです。 そして特に、 Swiftで動作している点が気に入りました。 宣言型システムを記述して、バックアップとして 次のようにすることもできます。 宣言的と言うとき、それは、 つまり、フレームワークに自分が 何を望んでいるかを伝えているわけです。 そこに至るまでのすべてのステップではなく、 実際に起こること、 これは、物事を構築する 上で不可欠な方法である。 だからこれは、構築できる本当に 強力なアイデアのようなものだった Objective-Cを含む、 あらゆる言語の宣言型システム。 しかし、Swiftはこれを書くことをより 自然で表現力豊かなものにした。 だからそれはある意味、またとない機会だった。 これらのアイデアを真に探求するため。 そして、それが私をも惹きつけたのです。 うん。 あ、すみません。 話を遮るつもりはなかったんです。 ああ、私もそれを一種の試みと捉えています 私がずっと解決したいと思っていた 同じ問題を解決するために、 これにより、UI上で アプリを作成しやすくなります。 フレームワーク同士も、それほど 大きな違いはない。 しかも、SwiftUIにも 命令型の要素がないわけではない。 例えば、レイアウトプロトコルや キャンバスやパスに降りていくと、 宣言型APIを持つことは、 抽象化のもう一つのレイヤーに過ぎない。 それは、次のような問題を 解決するのに役立ちます 私たちは常に解決しようとしてきました。 ラッセルはいつも、アプリが バグのない未来について夢見ています。 アプリはあなたの望む通りに 動いてくれれば、世界はすべてうまくいく。 ええ、私はそういう現実の中で生きたいんです。 君には連絡手段があるんだね。 私にも紹介してくれないか？ これだと思います。 つまり、ロゴも全部揃っているんです。 まるでそれが大きいみたい。 まあ、そのシンプルさを表現したあなたの 言葉がとても気に入りました。 SwiftUIが目指すもの、 そして私の意見では、 フレームワークを使い始めた最初の瞬間から、 宣言型インターフェースは、単に 優雅なだけでなく、 しかし、学ぶのは楽しく、 時間を費やす価値はある。

そこでSwiftUIが導入された。 2019年に設立されました。 このプロジェクトが 解決しようとしていた問題について、 もう少し詳しく教えていただけますか？ そして、その問題提起がどのように そしてそのアプローチは、 時間の経過とともに進化してきた。 飛び降ります。 テイラー。 君の方が勤続年数が長いよね？ うん。 ほとんどの年は、つまり、 ほら、私が解決しようとしていた問題は、 アプリ開発のハードルを下げる、 ということですよね。 そして、宣言型システムのようなものを 活用する。 ご存知の通り、私たちは本当に 唯一の真実の情報源を求めている のです。 そうすればそうでなければ発生する可能性のある バグの種類他の種類のアプリでも。 つまり、本当に目標があるんです。 私たちは多くのことの中心にいます 私たちがやっていたこと。だから 最初の数年間は本当に これらの原則を土台として、 そこから発展させていく。 そしてその後は毎年、 新たな機能を追加していくことになる。 ご存知の通り、UIKitには 長い歴史を持つ機能があります。 そしてAppkitはそれらを提供します。 私たちの目標はそれらに匹敵することです。 私たちは今日に至るまで まだそこにすら達していません。 しかし、私は感心する 段階に達しつつあると思います 人々が開発できるアプリの種類によって。 テイラーの発言に付け加えると、 最初から一貫していることの一つは、 私たちが書くことだと思います。 APIのおかげで、ほら、 「一度学べば、どこでも書ける」 というキャッチフレーズが生まれたんです。 しかし、慣れてくるとフレームワークの各部分に 慣れていく。 APIの他の多くの部分についても、 自然と理解が深まるでしょう。 そこで、UIKitを想像してみてください。 Uitableviewがある場所そして、 Uitableview API サーフェスについてすべて 学びます。そして別のコンポーネントに 移動しますそしてあなたはこう思うでしょう、 「ああ、これには 他にもいろいろなパターンがある」 私はそれに慣れる必要がある。 しかし、 SwiftUIでは、 最初からすべてが馴染みのある感覚で 使えるようにすることがコンセプトです。 そしてそれは着実に、 安定している。 まるで原動力のように。 ええ。そしてそれは、実際に APIを使用することだけにとどまらず、また、 一つのコードを別のプラットフォームに 展開することも可能である。 異なるハードウェアそして、 さまざまな状況における アプリの存在を確認できるようになります。 そして、あなたのスキルセットを磨きましょう。 ラッセルが別の議論で 指摘していたことの一つは、ほら、 完全な状態になる終わりに 近づいているアプリが期待する機能セットは、 いわば次の レイヤーのようなものになるでしょう。 そして私たちは、本当に 大切なものは何かという 方向へとシフトしているのだと思います。 SwiftUIで構築できるユニークなものや、 使用できるツールの種類は？ ええ。だって、つまり、私たちが始めたとき、 そこには、良いものの核のようなものがある。 アイデアが本当にしっかりしたものになったら、 しかしその後、他の国と同等の 地位を得るのに何年もかかった。 フレームワーク。そして、 今私たちはそれに近づいている と思います。優先順位をコアのようなものに 戻すこともできます。 例えば、どのような新しい アイデアをフレームワークに 取り入れることができるでしょうか？ そして、コアフレームワーク自体のように 進化していくのでしょうか？ ええ、もちろんです。 それに関して私が思い浮かべるのは、 導入されたScrollView APIと、 そしてあなたは私よりも 彼らと上手く話せるでしょう、 しかし、デベロッパにとってより 簡単にするという点で、 さらに一歩進んだものと言えるでしょう。 それほど多くのコードを書かずに、 非常に高度なビューを実装する。 ええ、そうです。 その点に触れてくださって、本当に嬉しいです。 観客の皆さんに簡単な質問です。 アプリ内でSwiftUIをどのくらい 使用していますか？ そして、ScrollViewの中に GeometryReaderがあります。 あった。設置して。いいぞ。よし。 私はいくつかの手を見ました。 もう必要ないでしょう。 2年前から存在する 他のAPIもありますさらに長く、 より人間工学的に設計されています そして、それは可能だ。 あなたもそうだ。 スクロール位置修飾キーについて説明します。 スクロール位置修飾子。 アニメーションをうまく繋げる 方法はたくさんあります。 ScrollView でアニメーションを 駆動し、 それについてもセッションを用意しています。 過去には2023年まで 遡らなければならなかったかもしれません。 しかし、とにかく、私たちは。 捨ててください。行スクロールページを 表示します。 ページ行。 スクロールするカートがやった、 スクロールする。 ターゲット動作、スクロール、 ターゲットレイアウト。 レイアウトプロトコル自体も、いくつかの ニーズに対応していた。 Geometryreaderが必要とするものと 同様です。 これらはフィードバックループを示す 素晴らしい例だと思います。 例えば、人々が物を使っていて 問題に遭遇しているのを見ると、 これにより、フレームワークを改善するための 次のステップについて考えることができる。 それもまた、そうです。 できる限り、誰かに本当に 素晴らしいことをさせてあげましょう。 現時点では正確には説明できませんが、 しかし、座標空間を使用します ScrollViewの座標空間には、 以下からアクセスできます。 スクロールプロキシだと思います。 スクロールリーダープロキシ そしてたくさんの面白いことをする それによって無効化のサイクルを 経る必要がなくなる Geometryreader が時折もたら すもの。 ScrollViewについてなら、いくらでも 語り続けられそうな気がする。 話したいことはたくさんあるんだけど、 しかし、開発者の影響についてあなたが 言ったことに戻りたいと思います。 そして人々がそのフレームワークをどのように 活用しているかを見る そして、 SwiftUI をUIKit MapKitと 同等にするだけでなく、 しかし、実際に次のレベルに進む そして、楽しい体験をより 簡単に作り出せるようにする。 デベロッパコミュニティがSwiftUIに 与える影響についてお話いただけますか？

それが本来の理由だった。 私が「テイラー、あなたのチームに 参加したい」と言ったら、彼はこう言った。 何が好きですか？そして私は自分に言いました、 UI やSwiftUI は ユーザーインターフェースの略ではありません。 それはあなたと私を表しています。 そしてそれが。 しかし、それは本当に事実なのです。 誰かと会うときと同じように 共通の趣味があって、誰かと会っても、 二人ともランナーであるとか、 二人とも特定の映画ジャンルが好きだとか。 旅行中に他の国でたくさんの人に会ったことが あるよつい最近連絡を取った相手は、 お互いUIフレームワークが好きだからだ。 そして、すぐに共通の言語が生まれるのです。 だから、世界を見て回ったり、 人々と出会ったりするのに、 本当に素晴らしい方法だと思うんです。 ええ。つまり、私が説明したフィードバックループのようなものだと 思います。 毎年、私たちは次に最も 重要だと考えるものをリリースするために、 人々が何を作っているのか、 そして彼らがどのように反応するのかを観察し、 そこから改善を重ねていく。 つまり、先ほども言ったように、 当初の目標は、アプリ開発への 参入障壁を下げることだった。 そしてそれは目標だったが、 私たちはまだ少し感銘を受けていました そして驚いたことに、 SwiftUIをリリースするとすぐに、 これまでアプリ開発をしたことがない人たちが、 初めてアプリ開発に挑戦していた。 ご存知の通り、デザイナーはそういった 人々のグループの一つであり、 他にも多くのグループが存在します。 ご存知の通り、生成AIツールも良い例です。 本当に人々を力づけてきたもの、 毎日見ていると、私は自分が 本当にやりたかったことを実現した 新しいアプリを開発しました。 アプリを開発したのは今回が初めてです。 そして、それがとても素晴らしいです。 そして、ほら、 アプリ開発に携わる新しいタイプの人々が 直面する問題とは何でしょうか？ そして、その体験をさらに 向上させるにはどうすればよいでしょうか？ つまり、私はさらにこう付け加えます。 私が朝起きる理由は、新しいものを加えるためだ 皆さんが素晴らしいアプリを 開発できるようにするためです。 つまり、私もここで働く 前はデベロッパコミュニティ出身だったんです。 それは、私がプログラミングを学ぶためにやった ことの一つで、読書でした。 Appleが提供する、 iOSアプリの作成方法に関するドキュメント。 つまり、iPhoneの画面上で 何かを動かすのは、 以前使っていたターミナルアプリよりもずっと 魔法のようだった。 つまり、それに付け加えると、 いつか私は卒業して戻ってくるかもしれないという ことです。 アプリ開発を始めるために。 ええ。動画の最後に言うように、 私たちはよく、「あなたが何を作るのか、 見るのが待ちきれません」と言うんです。 本当にその通りです。 最も楽しいことの一つは、あなたは 一年中このAPIを研究し 構築することに費やし、そして、 あなたの頭の中には、あなたは 人々がそれをどのように使うかを 想像しました。そして、誰かが 「このAPIを使ってこんなことをしたよ」 と言っているのを目にする。 そしてあなたはこう思うでしょう、 「ああ、それから」。 それは良い感じだった。 最初は「こんな風になるとは 思わなかった」って感じだった。 そして彼らは実際にとても クールなことをしているのですが、 そしてそれはつまり、私たちが 目標を達成したということです 一般的に動作する構成的なAPIを 作成するという観点から 予想外の方法で物事を成し遂げることができる。 予想外だった。素晴らしいね。 いいえ、フレームワークの進化は喜びでした どれほど洗練されているかを見るだけでなく、 どれほど楽しいかを見るためだ。 そして、ここで開発者と交流できるこのような イベントが大好きです オンラインで質問したり、 これらのAPIがどのように使われている かを実際に確認したりしてください。 そして彼らが素晴らしいことをしているのは、 そして、アプリのニーズにさらに 良く応え続けるにはどうすればよいか。 だから、すごくやりがいがあると思うんです。 そして、これは私たち 全員の気持ちを代弁するものです。 やりがいがあります。 本当にやりがいがあります。 これはSlidoに関する質問です。 多くの人が推薦について 尋ねていましたSwiftUIで 推奨されるアプリアーキテクチャについては、 こちらをご覧ください。 それについてもう少し詳しく 教えていただけますか？ これはよく聞かれる質問です。 そして、私たちが試すことができた 頃から世界は大きく進歩したと思います あるアーキテクチャを推奨し、 万能なソリューションであると言うこと、 そして私たちは人々をこの一つの 建築様式の道へと送り込むのです。 そして、あなたのアプリは サーバー依存度が非常に 高いことが判明したのかもしれません。 つまり、その建築の仕事はあなたにとって 適切な選択ではなかったということですね。 つまりSwiftUIの目標は 実際にはあらゆる建築に 必要な構成要素を提供する。 私たちは、コミュニティが 構築しているすべてのアーキテクチャを 十分に認識しています。 私が指摘したいことの一つは、 Observable マクロは、あなたが 始めるのに最適な場所です。 Observable で使用されているような ViewModel ベースのアーキテクチャをお持ちの場合は、 その原子的な構成要素を使用する さらに、SwiftUIとの優れた統合により、 ViewModelを構築できます。 また、Observable は 次のように使用できます。 UIKitでも汎用性を損なうことなく、 これは本当に素晴らしいことです。 そしてこれを強化しているのは、 鍵となるものの1つである 目標は相互運用性である。 つまり、AllTrailsがどのようにして 採用したかという話を見ました。 SwiftUIを段階的に開発する。 そしてそれは、多くのアプリに 当てはまることです。 そして、それらのアプリはそれぞれ 異なる場所から来ています 建築的には。そしてそれは本当に SwiftUIに対応できることは 非常に重要である アプリがどこから来ているかに関わらず。 ええ。AppleAppleでも、多くの アプリがその相互運用性に依存しています。 ええ、もちろんです。 それは本当に、あなたのチームが、 チームのメンバー全員と相性の 良いものは何ですか？ そして、彼らが最も速く建設する方法 そして、彼らが最も優雅だと考えるもの。 そして、たくさんのリソースがあります。 例えば、あなたのアプリが 現在UI UIKitの領域にあるか MapKitの領域にあるか、 そしてあなたは、いつSwiftUIの導入に 踏み出すべきか考えているのですね。 デベロッパウェブサイトには、 WWDCの動画など、 たくさんのリソースがあります。 そのプロセスを円滑に 進めるためのお手伝いをいたします。 それは本当に多くの人が通った道です。 そして、最初の一歩を踏み出すための素晴らしい リソースはたくさんあると思います。 うん。

Slidoさんからもう一つ質問があります。 そしてこれはより高次のレベルの話です。 多くの人が具体的なことについて 質問していました。 特定のプラットフォーム上でこの動作を 実現するためのAPIは何ですか？ あるいは、ビューでこの機能を 実現するにはどうすればよいでしょうか？ そして、もっと高い レベルで興味があるのですが、 さまざまな動作に対応するAPIを見つけるには、 どのような方法が推奨されますか？ SwiftUIを使う場合、 どのようなツールをお勧めしますか？ 私は、私は多くの成功を収めてきました Xcodeへの様々なモデル統合により。 少なくともそれだけは良い。 素晴らしい出発点だ。 どんな言語で話していても、 いつでも言うことができます。 実際、実際には、テストされた モデルを見たことがないんです さまざまな言語で、しかし 自然言語で言わなければなりません あなたが探しているもの、そしてすぐに、 いわばごちゃ混ぜのものが手に入ります。 修飾語と提案について。 それは実際、非常に役立つ出発点です。 うん。インテリジェンス機能は 本当に素晴らしいね。 そして、それらはプロトタイプ作成の 障壁を大幅に低減する。 それは、動き始めるきっかけになると思うんです おそらく私があまり詳しくない分野で そして、私の理解をさらに深めることができる。 最新リリースはその点で本当に素晴らしい。 でも、それは重要なことだと思うんです。 何かを生み出すだろう、 示そうとするだろうあなたに何かを 伝えたいのですが、 デベロッパとしてのあなたの仕事は、 それを疑問視することです。そして、それが 何をしているのかをきちんと 理解するようにしてください。 幻覚とか、そういう類のことは、 私たちみんなよく知っていますよね。 そのため、それを確認することに加えて、 それは強力な学習ツールでもあると思います。 あなたが始めたやり方は、 まあ、悪くないと思います。 この効果を実現するために、 以下の修飾子セットが提案されました。 それぞれの機能が実際に何をしているのか、 私は理解しているだろうか？ そして、それがドキュメントへと繋がるのです。 そして私たちの目標の一つは、各文書が サンプルコードが少し含まれている ので、自分で始めることが できます。この種の学習によって、 メンタルモデルを構築する、 それは素晴らしいと思う。 ええ。そしてそれが今日私たちがここにいる 理由です。基礎、 今日、その言葉を10回くらい、 いやもっと言ったと思う。 数えますよ。でも、時間をかけるように 基礎を理解することで、 自分のコードに自信を持つことができる。 そして、もし何か理解できないことがあれば、 LMMがそれを説明してくれるかもしれません。 あなたはまだその時間を使って、 まだ自信のない分野に触れ、それを学ぶこと。 だから、本当に素晴らしいんです。 それは一つの点だ。 ええ、特に何かを学ぼうとしている 時はそうですね。 私は学習とアプリ開発を同時に 行うことはほとんどありません。 Xcodeのプレビュー機能を使うことで、 常に新しいことを学んでいます。 そして、基礎ができたら、 そしてそれをアプリに持ち込むと、 他のすべての副作用が 発生しますそして複雑さも同時に生じているが、 少なくともそのモデルは存在する。 それは本来あるべき動作方法なのです。 だから、何かおかしいと感じたり、 変なことをしてしまったと思ったりしたら、 どこを探せばいいのか、 どこから始めればいいのか、といったことです。 うん。プレビューは私のお気に 入りのツールの1つだよ。 バグの特定、記述、再現が 容易になるという点だけではない。 もしかしたら、何か 奇妙な行動があるのか​​もしれない そして、状態を素早く注入して、 それがどのように動作するかを 確認することができます。 しかし、素早くプロトタイプを作成し、 レイアウトに関しては、 プレビューをレイアウトに使うのが大好きです。 これは私のお気に入りのツールの1つです。 他に思いついたリソースとしては、 デベロッパフォーラムがあります。 そのため、ドキュメントや WWDCのビデオに加えて、 これは私がさまざまなAPIについて 学ぶ方法というだけではなく、 しかし、サンプルアプリというより 大きな文脈の中でそれらを見てください。 そして、どのような要素が 思い浮かぶか見てみましょう。 そんな感じ。ScrollViewの 動画は最高だった。 アニメーションのアイデアがたくさんあるので、 しかし、デベロッパフォーラムも 素晴らしい情報源です SwiftUIやUIKitのような フレームワークごとに 質問することができるため、 ただし、watchOSや Vision OSなど、 プラットフォーム固有の 質問をすることもできます。 たとえその瞬間に 質問がなくても、もしかしたら、 あなたはただ学びたい、あるいは 様々な種類のあなたが 将来考えるべきことのいくつか。 これは素晴らしいリソースです。 そして、Appleのエンジニアとサポートチームがそれを 管理しています。 これは構築中の素晴らしい参考資料です そして、デベロッパとしての旅を続ける。

そこで、SwiftUIが役立つことについても 少しお話ししたいと思います。 アプリは今年もLiquid Glassで 最新の状態を維持します。 それはiOS 26をはじめとする 他のオペレーティングシステムの開発において、 非常に重要な要素だった。 SwiftUIがアプリを最新の状態に 保つのにどのように役立つかについて、 もう少し詳しく教えていただけますか？ Appleプラットフォーム向けですか？ あなたは＿＿したいですか？ つまり、まず最初に言えることは、 SwiftUIは多くの高レベルのセマンティックAPIを 提供するように、 過去に提供されていたUIKitやAppkitよりもさらに 高いレベル、 これにより、より 多くの柔軟性を提供できるため、 アプリがこれらの意味概念で 実装されている場合、つまり、 Liquid Glassのダイナミックタイプの ダークモードよりもさらに前に、 これらは適応的な概念のようなもので、 それらが変化すると、 アプリがアップデートされ、 Liquid Glass は多くの素晴らしい機能を備えています 構成要素であると同時に、 多くの点でテーマでもある。 そのため、必ずしもアプリのコア構造が 変わるわけではありません。 そして、これらの意味論的概念を 用いて実装することで、 単に更新するだけで済むようになるのです。

しかし、それはカスタムコントロールにも 当てはまる。だから、たとえ カスタムメイドのものを作ったとしても、 それには多少の調整が必要になるかもしれない。 しかし、SwiftUIのようなガラス効果コンテナなどの 他のAPIもあります 特に他のフレームワークが実現した方法を超えて なぜなら、当社の非常に 構成しやすいAPIが気に入っているからです。 ガラス用API表面。 ガラス風の容器は非常に小さいです。 それは、私が思うに、一つの見解です。 そして、おそらく3つか 4つのパブリック修飾子。 それなのに、こうなってしまうのです。 そこには、融合したり変形したりできるような、 様々な変化や類似の要素がすべて含まれている。 そして、命令型UIフレームワークがどのように 苦労するか想像できるでしょう 簡潔なAPIを提供するために、 既存の部品をできるだけ多く 使用したことは理解できる。 だから、SwiftUIは Liquid Glassの開発に 本当に役立ったと思います。 これはニックがかつて学習という 言葉を口にしたことから始まったと思う。 そしてどこにでも適用できます。 そして、フレームワークを超えて 適用されるだけでなく、しかし、 この概念の中でも、それは、あなたが学んだ アニメーション技術のすべてに似ています 他の目的にも同様に適用される。 だから、これもまた、その原則に 基づいた生き方の良い例だと思うんです。 ええ。私にとっては、容器に手を伸ばす タイミングを知るようなものだと思います。 そして、それらの基礎知識を知ることで、 目指すべき土台を知ることが、 繰り返し話題に上る そして、どこに自社のブランドを散りばめるべきかを 正確に把握すること あるいは、あなたのアプリを特別なものにしている ものは何ですか？ そして、それが時間の経過に 対してある程度堅牢であることを確認する、 オペレーティングシステムは進化するので、 あなたはそうではない、 変更に多くの作業が伴うわけではありません アプリの設計方法について。 だから、そういったユニークな体験を 適切な場所に押し込めば、それから、 あなたのものを持って行ってください。 非常に凝ったアニメーションをお持ちの場合。 「いいね！」ボタンをタップすると、 何かが飛び上がって回転し、踊り出す。 そしてそれはすべてのプラットフォームに 即座に適用され、変更にも非常に強い。 そして、非常に将来性も高い。 ええ、開発者とのワークショップを 通して印象に残ったのは、 Liquid Glassショップ、 タブビューのようなネイティブコンポーネントで 構築していれば システム制御を使用して、 iOS 26で再コンパイルするだけで、 それらのアプリが自動的に設定されます。 UIKitでもSwiftUIでも、 Liquid Glassのモダンな 外観を最大限に 活用できる絶好の場所に位置しています Appleプラットフォームおよび。 そして、次のレベルの洗練へと 進み始めるそして、 ナビゲーションやブランディングを見直す 機会についても検討している。 それは本当に素晴らしかった。 まるで魔法にかかったような感覚だった。 そして、それがSwiftUIの 基盤の一部となっていることは 本当に素晴らしいと思います。 枠組みとして、現代性を 保つための障壁を取り除く そして、オペレーティングシステムの高度な 機能を活用する。私たちが検討した 指標の一つは、次のようなものです。 まさにそのことに費やした時間 アプリをプラットフォームの 一部のように見せるため。 私たちはこれをできる限り減らしたい そうすることで、アプリの真の独自性を生み 出すことにすべての時間を費やすことが できるようになります。 それはそれを示す素晴らしい方法だと思います。 はい、もちろんです。 システムコンポーネントについてもう少し 詳しくお話いただけますか？ Wishlistにはまだまだたくさんの魅力的な 要素が詰まっていると思う。 今日そこで紹介されたサンプルアプリについて、 Majoはデザインプレゼンテーションの 中で説明しました。 タブなどの コアシステムコンポーネントがたくさんあります。 アイコンにSF Symbolsを使用して 非常にすっきりとしたタブビューを維持し、 そして、アプリが使い慣れた 標準的なシステムアーキテクチャに 柔軟に対応できるようにする。 しかし、私たちはさまざまなフォントで タイポグラフィを使用します 個性やブランドイメージを表現するため。 そうしたトレードオフをうまく乗り切るための アドバイスについてお話いただけますか？ 内蔵コントロールを使うべきか、 それとももう少し個性を表現するべきか？

ああ、それはいい質問ですね。

男の子。 状況によって異なるため、詳しく 説明する必要があることがたくさんあります。 うん。 本当にそうなんです。 それは本当にデザイン上の決定で、 アプリの独自性はどこで発揮したいですか？ 馴染みのある感じがする？馴染みがあることには メリットがあると思うなぜなら、 初めてアプリをダウンロードする 人のように、彼らに 馴染みのあるものにしてほしい、 アプリを独自に使う 方法を学ぶ必要はありません。 そして、彼らを惹きつける 小さな体験もある。そうでしょう？ それが際立たせるんです。 それは素晴らしいレンズです。 それを通して見ると、 私、ラッセル・ラッセルはたくさんの 仕事をしました。 彼は多くのUIプレゼンテーションコントローラーと シート、 そしてSwiftUIシートを構築しました そしてシートは、そのための私のお気に 入りのコンポーネントの1つです。 テイラーが指摘したように、人々は 物事がどのように進むかをただ知っているのだ。 それはオペレーティングシステムの非常に 重要な部分なので、私は本当に躊躇します 世界的な指針を提供する。 しかし、独自のシートを 作成しないようにしてください。 そうだよね？うん、あるよ。 いや、それは違う。 それは信頼できる情報だ。 そしてそれは私だけの問題ではない。 あなただけのためじゃないよ。わかった。 あなたの言葉を信じます。では。 ここ数回の質問には共通する テーマがあると思うのですが 段階的開示では、ユーザーの観点から はどちらも好ましい。 使うものが多いほど 他のアプリと共通して、ユーザーはより 良くアプリの仕組みを理解する。 しかし、APIでも、 例えば、より高レベルのセマンティックコンポーネントを 使用する場合、 そうすれば、どちらもあなたにとってより 親しみやすいものになるでしょう そして、アプリを使用するすべての人が、 より適応していくでしょう。 しかし、デベロッパであるあなたにとっても 理解しやすいのは、 それは、よりシンプルで、より高次の概念です。 そして、あなたがますます 建物を建てるようになるなら 自分のユースケースに合わせてそれをどんどん カスタマイズしていくと、 それは誰にとってもより複雑になるが、 おそらくそれは適切である。 しかし、私たちは連続性を 確保したいと考えています。 そして、同様の方法をさらに追加する 上位レベルのコンポーネントを 適切にカスタマイズして、 完全にドロップダウンすることが 非常に重要です。 そして私はこれを関連付けていたと思います 最後に話していた内容に 話を戻します。でも、 いや、感じたんだ、感じたんだ。 つまり、ふと思いついたこと 私にとっては、 システムコンポーネントでもできることが たくさんあるということです。 シートやiOS 26の美しい 動作について話すなど、 例えば、シートの高さに応じて 背景が少し変化するような感じ。 シートの動作をカスタマイズするための ツールはたくさんあります。 そして修飾語。だから時々、 ドキュメントを読むには 少し時間がかかりますそして、 どのような選択肢があるのか ​​を調べてください。 しかし、プレゼンテーションの デタントを設定するように、 detente と detent のどちらが正しいのでしょうか？ 私はいつも苦労している、それが私の秘密だ。 私はいつもそれに苦労します。 このAPIの作成。 言葉。 デタント。よし、ペースを落とすよ。 それはデテントです。ああ、そうです。 ほら、私。 まるでマイクロピペットのようだった。 そうでした。 のように。 マイクロピペット。 でも、APIに組み込まれている 機能でできることはたくさんありますよ。 本当に洗練された振る舞いをするために これらの組み込みナビゲーションツールを カスタマイズする さらに、アプリ内で個性を表現するための組み 込みコントロールも用意されています。 ビュー修飾子、フォントなど、 このシステムコンポーネントを使えば、 実に多くのことができるんです。 そして、まだ限界は存在します。 皆さんにその限界を見つけ出し、 私たちに教えていただきたいのです。 そして私たちは、そうした 制限を取り除くために耳を傾けています。 そして、それをさらに強力にする。 まったくその通りです。 真実。 彼女が特にLiquid Glassでやっている ことで私が一番好きなのは、 ここで訂正していただく必要があるかもしれません が、背が高くなるにつれて、 より不透明になる。 しかし、その板自体はガラスでできている。 そして、シートの高さにもよるけど、 ぴったりと収まるんだ。 デバイスのベゼルにぴったり収まるか、 サイズによっては浮いている ように見えるかのどちらかです。 それは、とても、とても。 いいですね。長年にわたって、 シートにはたくさんの動作を追加してきました。 あなたはシーツの王様ですか？ これは。いいえ。ええと、

私たちの中には、その部品を機能させるために シート上で作業している人がたくさんいます。 うん。 いいえ、美しいんです。 私は、これらのシステムの多くがいかに 思慮深く設計されている かを見るのは本当に嬉しいことです コンポーネントはiOSで再考され、 26種類のオペレーティングシステムとLiquid Glassに 対応しています。 そして、見るのも楽しかったキャットは 先に、見る喜びについて語った。 面白いと思うアプリで、そして、 「これはかっこいい」と言う練習をする。 これをSwiftUIで 自分で作ってみようと思います。 それは、空白ページの問題に似ている。 あなたも、レイアウトやデータフローに 関するスキルを身につけたいと 思っているかもしれません。 そして、どこから始めたらいいのか、 本当にわからない。 そしてあなたは、「デザインは 必要だろうか？」と疑問に思っている。 そう、それが最初に 解決すべき問題の一つなんです。 しかし、自主的な運動を試してゼロから自分で 何かを作るというのは、経験を積み、 学んだことを定着させるための 素晴らしい方法です。 うん。 本当にその通り。先日、iOSのホーム画面にある アプリでそれをやったんだけど、 アプリの揺れるアニメーション。 例えば、そういう時。 あなたは何かを押さえつけている。 ええ。そして編集モードにロックされて、 そういう感じになります。 ３つすべてを動かす。 誰がこのやり方で一番良い 成績を収めるか見てみたい。 それはランダムです。 正しく行うのは本当に難しいです。 ラッセルだと思う。うん。 ラッセル。 それは単なる反復的な曲線ではない。 だから、それをSwiftUIの 四角形に実装するだけでも、 ちょっとした楽しい練習になります。 ヒントをあげましょう。 きっとあなたは行くと思います 高度なカスタムアニメーションの「マージ」 プロパティが必要になります。 バズ・アニメーションのことを考えていました。 わかった、いいね。うん。アニメーションの吹き 替え動画で言及されているよ。 それは本当に。 フェーズ方式も非常に 有効な方法かもしれません。 ほらね。問題を解決する方法も複数あるんだよ。 それは本当に楽しいことだと思う。 時々、何かをやり直そうとするのですが、 まずは一つのアプローチから 始めるかもしれません。 そしてそれは確かに存在していて、 私はこれからも続けていくし、 その過程で学んでいく。 そして、こうした漸進的なアプローチ。 それはラッセルが提唱した 漸進的情報開示全体に遡ると思う。 前述の通り、これはAPI設計自体の 核心的な原則のようなもので、 でもそれは、自分を次のレベルに 押し上げるようなもので、 何かをしようとして、「ああ、かなり 近いところまで来たね」という感じですね。 次に学んで実験してみるとしたら、 あなたが望んでいたものにさらに 近づけるため、または 新しいものをもたらすために、 独自の要素を取り入れる？ ええ、SwiftUIの経験レベルに関係なく、 彼らが始めたばかりであろうと、 経験者であろうとそして理解を深めようと、 学ぶべきことや発見すべきことは 常にたくさんあります。新しい API のみを使用した場合と、そして、 物事を実現するためのより 興味深い方法を見つけること。 ええ、素晴らしいですね。 では、お二人、そして皆さん全員に、 最後に一つ質問があります。 今日はウィッシュリストや 様々な旅行についてたくさん話しました そして、これらの旅行で私たちがやりたいこと。 アクティビティも旅行もたくさん。 次の休暇はいつですか？

今年こそスコットランドに 行ってみたいと思っています。 一度も行ったことがないんです。 田舎を見てみたい。 ドライブしたい。道路の左側。

それはあなたの夢ですね。

スコットランドのスラングです。できますよ。 できるよ、できるよ。それはどういう意味？ それは、ほら、そういうことだと思う。 よし、もっと詳しく学ぼう。 現地に着いたら実際に試してみて、 うまくいくかどうか確認する必要があるよ。 観客の中に知っている人がいたら。 私を探しに来て。 ミキサーで。 すごくかっこいい。 実は自分のことはよくわからないんです。 よし、観客席にいる 射手座の皆さんにエールを送ります。 私の誕生日は休暇中で、それで妹は今月末に 延期したサプライズ旅行を計画した。 それに、私たちがどこへ 向かっているのかさえわから ないので、いずれわかるでしょう。 それは冒険だ。そしてウィッシュリストには、 すべてのアクティビティに 疑問符を付けるように。 それは単なる 乱数発生器のようなものかもしれない。 次に何が起こるかは誰にもわからない。 それは未来の姿かもしれない。 ええ、ええ。 私は休暇中にゆっくり過ごすのが 好きではないタイプの人間です。 皮肉に聞こえるかもしれないが、 きっとそうだろう。 あなたはアクティブな休暇を 楽しむタイプですね。 私はアクティブな休暇を過ごすタイプです。 だから私たちは色々なハイキングコースを 歩くのが好きなんです。 そして、これからの取り組みの一つは、 イタリアのドロミテ山脈を 数日かけてハイキングする。 1つ目。今のところ予定はない。 いつそれが可能になるのかを見極めたい。 いいですね。それは素晴らしいですね。 海外出張が2回と、ラッセルに 関する大きな謎が1つあるんだ。 もしかしたら、あなたはクパチーノかどこかへ 旅行に行くのかもしれませんね。 まあ、そのうち分かるでしょう。 ええ、近いうちにフォローアップする 必要がありますね。 皆さん、本当にありがとうございました。 皆さん、一緒に彼らに拍手をお願いします。 これが私です。たくさんのことを学びましたし、 SwiftUIについて話すのはとても 楽しいです。 ありがとうございます。

SwiftUIについてもっと学ぶのはとても 楽しいです。 技術的な詳細だけでなく、そのフレームワークの 背景にあるストーリーも重要です。

今日は盛りだくさんの一日だった。 ビジュアルレイヤーからSwiftUIの 基礎概念を解説しました。 デザイン、レイアウト、モーションから データフローに至るまで、すべてにおいて。 そして、あらゆる段階で、私たちはその 決定の背後にある理論を解説しました。 Wishlistのような実際のアプリでは、 ジェームズ・グラハムは、 SwiftUIがAllTrailsの出荷にどのように 役立ったかを直接語った。 そして、これらの章全体を通して、 機能をより効率的に維持します。 一つだけはっきりしておきたいことがあります。 時間をかけて投資してください。 そして、 SwiftUIの基礎を学びます。 このフレームワークを活用することで、 優れたアプリを開発するのに役立ちます。

私と同僚は本日は Slidoで一緒に学んでいただき、 本当に感謝しています。 私たちは200以上の質問に答え、 会話を続けるために、 Apple Developer Forumsを チェックして質問してください SwiftUIに関する質問など。

Wishlistアプリのコードは ダウンロード可能になります。 今後数週間で。とても楽しいアプリで、 次の旅行を計画しているかどうか あるいは、今日のプレゼンテーションで 取り上げた演習をいくつか 再検討してみるのも良いでしょう。 私と同僚たちはいくつかのビデオについて 言及した。プレゼンテーション中および 今日の後半の資料、 リソースへのリンクを記載した メールを送信します。そうすれば、 あなたは学び続けることができます。

SwiftUIについて学ぶための 最良の方法の1つ その他の技術については、 WWDCのビデオを通じて知ることができます。

何百もの動画があり、 それらはAppleデベロッパの ウェブサイトまたは デベロッパアプリで視聴できます。 今日のプレゼンテーションで、 見覚えのある顔ぶれに気づくかもしれません。

今日は盛りだくさんの一日だった。 でも、その前に、もう 一人特別なゲストをお迎えしています。

基調講演などで彼女を見たことが あるかもしれません。さらに、先日開始した Swift Student Challengeについても ご紹介します。 彼女に一言一言お話してもらい、 番組の締めくくりを手伝ってもらいます。 Appleデベロッパリレーション担当副社長、 スーザン・プレスコット氏を 盛大にお迎えしましょう。

おい！

とてもワクワクしています。 まず第一に、仕事のことです。 皆さんも自分の仕事が好きだといいですね。 でも、ご覧の通り、すごく楽しいですよ。 今日一日を通してできればいいのですが。 そして、今日この場にいなかった 人々は他にもたくさんいます。 情熱が溢れている そして デベロッパコミュニティへの貢献世界中のこの 組織では、 そして、今日は皆さんがそれを実感できた 日の一つだったことを願っています。 ここに来てくれてありがとうと 言いたい。たくさんの人から 連絡をもらいました。皆さんに 感謝の気持ちを伝えたいです。 ステージに参加した人々のうち、 AllTrailsの ジェームズもここにいるだけでちょっとした 金星をもらえるよそして、彼自身の 経験も共有している。 そこで質問なのですが、 皆さんにとって良い一日でしたか？ 非公式アンケートです。いかがでしたか？

ロバート議事規則のようにしなければなら ないのでしょうか？ そして今、ブーイングしたい人たちに 出て行ってもらうよう 頼まなければならないそれとも、 その部分は省略してもいいですか？ 部屋のエネルギーを感じることが できてよかった。 観客から伝わるエネルギーを感じた。 私はそれが本当に大好きなんです。 リアが詳しく説明するように、 この後にはチャンスがあります。 直接お越しいただいた皆様へ、 オンラインで参加してくださっている 皆さんも大好きです。 そしてそれは非常に重要なことだ。 というわけで、私たちはあなたを愛しています。 ジュースは自分でグラスに注いでください ここでは、みんなで 楽しめるミキサーを用意します。 はい、軽食もご用意いたします。 でも一番ワクワクするのは、 あなたが見てきた人々 ステージ上では、そしてAppleのエンジニアリング部門で 働く多くの人々が デベロッパリレーションズチームが皆様の ご相談をお待ちしております。 そして皆さんもお互いに会う機会があります。 なぜなら、コミュニティは、Appleの ハブアンドスポークではないからです。 それは君たち全員の力だ。 そして、私たちもできる限りその活動に 参加していきたいと思っています。 それでは、最後にリサ、リサ、リアに バトンタッチして締めくくりたいと思います。 感謝の気持ちを伝えたいです。 それでは、交流会でお会いしましょう。 ありがとうございました。 うん。

皆様、ありがとうございました。 本日はクパチーノとオンラインでご参加いただいた 皆様、ありがとうございました。 あなたは私たちのデベロッパコミュニティの 心臓であり魂です。 何か新しいことを学び、 次に何を探求したいかという アイデアが浮かんだことを願っています。 直接ご参加される皆様へ。 後ほど外で軽食をとりましょうさらに、 Appleのエンジニアや デザイナーと交流する機会もあります。 直接お会いした方も、 オンラインでお会いした方も、皆様へ。 また近いうちにお会いできることを 願っています。 オンラインまたはお近くのAppleデベロッパセンターにて お手続きいただけます。 ありがとうございます。