WWDC25:Build a SwiftUI app with the new design

Liquid Glass に関するセッション。概要とベストプラクティスを具体的なAPIをもとに紹介。


0:00 – Introduction

  • iOS 26とmacOS Tahoeで導入された新しいデザイン「Liquid Glass」を中心に、アプリの見た目や操作感が大きく刷新
  • Liquid Glassはガラスの光学特性と液体の流動性から着想を得た新しいマテリアルで、コントロールやナビゲーション要素に適用
  • すべてのAppleプラットフォームで一貫した新しい体験を提供

3:07 – App structure

  • NavigationSplitView TabView NavigationStackSheet などの構造的なAPIが新デザインに最適化
  • NavigationSplitView
    • Liquid Glassサイドバーや背景拡張効果(backgroundExtensionEffect)で、コンテンツの美しさと可視性を両立
  • TabView
    • タブバーはフローティング化し、スクロールで最小化可能
    • tabBarMinimizeBehavior .onScrollDown 
    • @Environment(\.tabViewBottomAccessoryPlacement var placementをもとにアクセサリの表示位置を条件分岐でカスタマイズ
  • SheetはデフォルトでLiquid Glass背景となり、ユーザー操作による展開高さに応じてエッジや透明度が変化
  • プレゼンテーション(シート、メニュー、アラート、ポップオーバー)はトリガーになったボタンからスムーズに展開

7:49 – Toolbars

  • ツールバーはLiquid Glass上に配置され、下のコンテンツに応じて自動適応
  • ToolbarSpacer でグループ分けやスペース調整が容易
  • badge 修飾子で通知バッジを簡単に追加可能
  • アイコンはモノクロレンダリングが基本となり、必要に応じて.tint()で強調
    • モノクロにより視覚的ノイズが減り、コンテンツを強調できる
  • スクロールエッジ効果(scrollEdgeEffectStyle)でコントロールの可読性を維持
    • 不動要素が多く高密度 e.g. カレンダー:.hard

11:10 – Search

  • 検索フィールドはツールバー下部やタブ専用ページなど、柔軟な配置が可能
  • searchable修飾子やsearchToolbarBehaviorで検索体験をカスタマイズ
  • Liquid Glass上に検索フィールドが表示され、デバイスやツールバー嬢のボタン数などの状況に応じて自動的に最適化

14:03 – Controls

  • ボタンやスライダー、メニューなど標準コントロールが新デザインに対応
  • ボタンはカプセル型がデフォルト、ガラススタイルも選択可能
  • 特に注意を引くアクションのために extra large サイズをサポート
  • .buttonStyle(.glass) .buttonStyle(.glassProminent)
  • スライダーは目盛りの表示や中立値(neutralValue)に対応
  • コントロールの高さや角の一貫性(コーナーコンセントリシティ)も強化
  • concentric rectangle shapeや controlSize 修飾子で柔軟に調整可能

17:57 – Liquid Glass effects

  • .glassEffect 修飾子でカスタムビューにもLiquid Glassを適用可能
    • .glassEffect(in: .rect(cornerRadius: 16))
  • tintinteractive修飾子で意味やインタラクションに応じた表現が可能
    • .glassEffect(.regluar.tint(.green))
    • インタラクティブ要素を持つコンテナに対して:.glassEffect(.regluar.interactive())
      • ユーザー操作に追従し拡縮、バウンド、光る
  • GlassEffectContainerで複数のガラス要素を一体的に管理し、自然な反射・屈折・モーフィングを実現
    • glassEffectIDnamespace でアニメーションや遷移も滑らかに制御

21:31 – Next steps

  • Xcode 26で新デザインを導入し、標準コントロールの自動適用を活用
  • アプリ全体のフローや背景色を見直し、不要な装飾を削除
  • Liquid Glassを活かした独自コンポーネントでアプリの個性を表現

WWDC25:Code-along: Bring on-device AI to your app using the Foundation Models framework

前回の「Deep dive into the Foundation Models framework」に引き続き、Foundation Models framework のセッションメモ(今回もAI要約+筆者加筆修正)。前半はだいたい前出の内容と被っていた。UIに組み込む際の体験向上、パフォーマンスの検証や改善のtipsについて。

Foundation Models のデモアプリが結果を逐次表示する際、やたらぬるぬると表示更新される様子が気になっていて、実装難易度高そうだと思っていたが、ストリームで吐き出されるデータ表現が自動的に identifiable であるため、実装者はただアニメーションを指定すれば良いという、にわかに信じがたい魔法のような話だった。


Introduction

  • Foundation Models frameworkを使い、SwiftUIアプリにオンデバイスAI機能を追加する方法を実演
  • 旅行プラン作成アプリを例に、ランドマーク選択→旅程自動生成→外部情報取得→ストリーミング表示→パフォーマンス最適化までを一通り解説

Prompt engineering

  • XcodeのPlayground機能を活用し、プロンプトの試行錯誤を効率化
  • @Generable annotation, @Guide macro
  • Instructions (プロンプトの上位形式 – the higher level form of prompting) により、モデルの役割や期待する出力例を明示し、精度を高める
  • 生成結果は Observable オブジェクトとしてUIにバインドし、リアルタイムに反映
    • 初期化タイミングによっては、不要なタ再生成が行われパフォーマンスに影響するため、Task modfier 内で初期化し、表示時1度だけの生成を保証するべき

Tool calling

  • Tool プロトコルを実装することで、モデルがアプリ内の任意の関数やAPI(例:MapKit)を呼び出せる
  • ツールには名前・説明・call メソッド(引数はGenerable 型)を定義
  • モデルは必要に応じてツールを自律的に呼び出し、外部データ(例:ランドマーク周辺の観光地情報)を取得
    • ツールの有無、ある目的に対して使って欲しい tool の明示、呼び出し頻度はプロンプトや instruction で調整可能
  • Apple Intelligenceの利用可否 = Foundation models の利用可否や、モデルの準備状況も考慮し、UIで適切に案内・制御
    • SystemLanguageModelmodel.availability で判別
    • Xcode の build scheme から、モデルの無効化が可能 (Simulated Foundation Models Availability)

Streaming output

  • 旅程生成の出力をストリーミングで受け取り、部分的にUIへ即時反映
    • session.streamResponse(...) API
    • PartiallyGenerated 型(全プロパティが optional な構造体)を活用し、生成途中のデータも段階的に表示
  • SwiftUIのForEachやアニメーション、トランジションを組み合わせて、スムーズな体験を実現
    • PartiallyGeneratable 構造体は自動的に identifiable、IDの自前管理は不要
  • ストリーミングにより、ユーザーは生成完了を待たずに内容を確認できる

Profiling

  • Foundation Models Instrument を使い、アプリのパフォーマンスを可視化・最適化
  • モデルのロードや推論、ツール呼び出しの各工程の所要時間を計測
  • 初回リクエスト時の遅延対策として「プリウォーム(session.prewarm())」を推奨
    • モデルがリクエストをもらう前に、モデルをロードしておく
    • 例: ユーザーがプロンプトのタイピング開始時
    • 今回はランドマークタップ時(Generate ボタンタップ前)
  • 生成スキーマをプロンプトに含めるかどうかを状況に応じて最適化し、トークン数やレイテンシを削減
    • モデルがリクエスト生成前にレスポンスフォーマットを完全に理解していればincludeSchemaInPromptfalse に指定する
      • 有効ないくつかのケースを紹介
  • 実機での計測を推奨し、シミュレータとの違いに注意
    • Simulator on M4 Mac > iPhone の場合あり

WWDC25:Deep dive into the Foundation Models framework

前回の「Meet the Foundation Models framework」に続いて、Foundation Models framework を深ぼるセッションビデオのメモ。今回もAIに要約してもらったものをベースに理解したことを書き足していった。

Tool は Inputに対してOutput が一定決まっている(連絡先やカレンダー)ユースケースに対応しており、一方でたとえばカスタムデータからインサイトを得るような、ファインチューニング的な方法は現時点での Foundation Models framework ではまだ実現できなさそうだった。あくまで、オンデバイスLLMに外部リソースへの一問一答的な参照手段を与えるという理解。desciriptionを記述することでモデルが勝手に選択して使うという意味では、MCPに近いかも?将来的に、自身が保有するデータをこのツール定義としてアプリ外に公開し、アプリ間でAI同士やりとりできるようになると面白いかも、と妄想が広がった。


Sessions (Prompting / Transcript / Sampling)

  • session.respond(to: userInput)
    • instruction promptをトークン (small substrings) に分解
    • LLMがトークンシーケンスを受け取り、response を生成
    • Foundation Models framework が一連の処理を担うので使い手は気にしなくて良いが、トークンは free ではない:計算コストとレイテンシが生じる
  • ステートフルなセッションとその状態管理
    • セッション(LanguageModelSession)は状態を持ち (statefull)、やりとりの履歴(transcript)を保持する
    • session.transcript: デバッグやUIへの表示に有用
    • ただし、context limit あり:入力・出力のトークン数が多いと遅延やエラー(.exceededContextWindowSize)が発生する
      • 履歴のない新しいセッションを開始
      • 既存のセッションから transcript を要約し引き継げる
        • 例1. 最初(instruction)と最後のやりとりのみ引き継ぐ
        • 例2. transcipt 全体を要約して引き継ぐ (外部ライブラリ or Foundation Models 自体を用いて)
  • サンプリングと出力の多様性
    • 同じプロンプトに対して異なるアウトプットが生じる
    • モデルの出力 = トークンは、確からしさの分布に基づき確率的に選択される(sampling)
      • デフォルトは randam sampling
      • ゲームなどの用途に対して、再現性を求めたい場合:GenerationOptions でサンプリング方法や多様性 temperatureを調整可能 (数値大きい方がアウトプットが多様)
      • 決定論的な出力(.greedy)も選択できるが、モデルのバージョンによって結果が変わる場合がある
  • 言語サポート
    • 入力言語が未対応の場合は .unsupportedLanguageOrLocale エラーが発生
    • モデルが対応している言語かどうかを事前にAPIで確認可能

Generable

  • @Generable マクロを使うことで、Swiftの型に沿った構造化データを安全に生成できる
    • constrained decoding により、特定のスキーマに沿った正しい出力のみが生成される
      • ハルシネーションが発生しても、最終的にスキーマ定義されたトークンのみを採用することで誤りを防ぐ
    • enumやassociated value、配列、数値型など多様な型に対応
    • @Guide マクロでプロパティごとに値の範囲や説明を指定可能
      • @Guide(.range(1...10)) for Int
      • @Guide(.count(3)) for Array
      • @Guide(desciption: "A full name")
    • プロパティの生成順序はソースコードの宣言順に従うため、依存関係やUI表示順に注意
    • 文字列に@Guide(.pattern(...))を指定して 、正規表現(regex)による文字列制約も可能
      • Regex builder syntax

Dynamic Schemas

  • 実行時に構造が決まるデータにも対応可能(DynamicGenerationSchema
    • Dynamic schemas はPropertyのリストを持ち、Propertyごとがnameとpropertyの型を定義するschemaを持つ
    • Dynamic schemas は配列を持つことが可能
    • 他の dynamic schemas をスキーマ名を通じて参照することが可能
  • ユーザー入力などで動的にスキーマを構築し、モデルに渡すことができる
  • 検証済みスキーマに変換してから推論を行うため、動的でありながら同時に型安全性が保たれる

Tool Calling

  • Tool プロトコルを実装することで、モデルがアプリ内の任意の関数やAPIを呼び出せる
    • Tool.name は短く、しかし省略は用いず英語としてreadableで分かりやすくするのが推奨。動詞を使うべき e.g. "findContact"
    • Tool.description も同様に長すぎず (1文推奨)、実装の説明を含めるべきでない
      • この文字列がそのままプロンプトに用いられるため、トークンが長くなりレイテンシが増大する
  • インプットArgument を定義
    • モデルがツールを呼び出す際にArgumentを生成する
    • 入力引数もGenerable で型安全に生成されるため、想定外の値が渡される心配がない
  • ツールはインスタンスで、そのライフサイクルをコントロール可能
    • セッションの初期化時に渡し、セッション中は同じインスタンスが使われる
    •  ツールは状態を持つこともでき、複数回・並列で呼び出される場合もある
  • 例:連絡先やカレンダーの情報を使って、よりパーソナルな体験を実現

まとめ

  • Foundation Models frameworkは、オンデバイスで安全かつ柔軟にLLMを活用できる強力なツール
  • セッション管理、構造化出力、動的スキーマ、ツール呼び出しなど、実践的な機能が豊富
  • プライバシーを守りつつ、アプリに高度なAI体験を組み込むことが可能

WWDC25:Meet the Foundation Models framework

Foundation Models フレームワークが気になっていたので、一度Liquid Glass を離れて3本目に見たのでメモ。オンデバイスモデルならではの制約を実際に使いながら把握していきたい。

前回まで、Liquid Glass の抽象的な思想をしっかり理解する意気で、几帳面にもビデオを頭から見てメモを構築したが、無駄に時間がかかるので今回は先にAIにまとめてもらって、そこに自分の理解を加筆していった。


1. フレームワークの概要

  • Foundation Modelsフレームワークは、Apple Intelligenceを支えるオンデバイス大規模言語モデル(LLM)へのアクセスを提供
  • macOS、iOS、iPadOS、visionOSで利用可能
  • スライドに示された用途例:コンテンツ生成/生成的対話/アプリ内ユーザーガイド/生成的クイズ/パーソナライズ/分類/要約/セマンティック検索/洗練・精緻化/質問応答/カスタマイズ学習/タグ生成/エンティティ抽出/トピック検出
  • オンデバイスで動作するため、プライバシーが保護され、オフラインでも使用可能

2. モデルの特徴

  • Xcode Playgrounds 上の数行のコードで実演
  • 30億パラメータを持つ大規模言語モデル
  • 2ビット量子化
  • 要約、抽出、分類などのタスクに最適化
  • デバイススケールのモデルであり、サーバースケールのLLMとは異なる用途に設計
    • 世界クラスの知識や高度な推論には向いていない
    • タスクを小さなピースに分解することが求められる

3. Guided Generation

  • LLMは自然言語による非構造的なアウトプットをするが、アプリのビューへのマッピングには不向き
    • JSONやCSVへの吐き出しをプロンプトで指示できるが、確率論的なモデルにおいて正確性を保証できない
  • そこで構造化された出力を保証する機能
  • @Generable@Guideマクロを使用
  • Swiftの型システムを活用して自然言語プロンプトを補強
    • @Generable: モデルに生成して欲しい型を定義
    • @Guide: プロパティに対して自然言語による説明を付与し、生成する値を制御する
    • プリミティブ型、配列、Generable型、再帰的な構造もサポート

4. Snapshot Streaming: ストリーミング機能

  • デルタではなくスナップショットを使用
    • 典型的なストリーミングアウトプットはデルタが用いられる
    • 生成した結果を組み立てる責務はデベロッパー側にある:構造的になると難しい
  • スナップショット:モデルの生成したデルタを部分的な生成結果として表現
    • @Generated マクロを展開するとPartiallyGenerated
      • すべてのプロパティが Optional
  • SwiftUIとの統合が容易
    • streamResponse(to:options:)
    • stream responses aync sequences
      • ↑ snapshot を逐次的に受ける
  • Best practices
    • SwiftUI によるアニメーション/トランジションを考慮する:レイテンシを隠すために
  • view identity を考慮する:特に配列において
  • プロパティの順序が重要
    • アニメーション/モデルのアウトプット どちらに対しても大切
    • summary を表すプロパティは最後に定義するのが良い
    • 参照:Code-along: Bring on-device AI to your app using the Foundation Models framework

5. ツール呼び出し機能

  • 外部情報源との統合
  • モデルがアプリ内のコード(Tool)を実行可能
    • e.g. struct GetWhatherTool: Tool
    • name description
    • call(arguments:) async -> ToolOutput
      • 外部情報源とのやり取りを実装(e.g. ジオコードから住所、位置情報から天気)
    • ツールの説明をもとに、モデルがツールを自律的に呼び出し、最終レスポンスに組み込む
  • よりダイナミックな定義が可能
    • 動的生成スキーマ
    • 実行時の引数/動作の定義

6. ステートフルセッション

  • セッションベースの設計
    • instruction: モデルがどう応答するべきかを定義:e.g. 口調や言葉数
    • カスタム指示の提供が可能
  • インストラクションとプロンプトと指示の違いについての説明
    • instructions should come from you
    • propmts may come from you / users
    • 前者が優先され、prompt injection 攻撃を予防する
  • multi-turn interactions
    • モデルとのインタラクションはコンテキストに保持され、1セッション内での 過去のやりとりを参照、理解できる
    • session.transcriptで過去のやり取りを出力可能
  • 組み込みのユースケース (built-in use cases)
    • e.g. SystemLanguageModel(useCase: .contentTagging)
    • Content taggin adapter の説明
  • エラーハンドリング
    • ガードレール違反
    • 未対応の言語
    • コンテクストウィンドウの超過

WWDC25:Get to know the new design system

昨日に続けてデザインシステムのセッションの備忘録。コンテンツ重視の姿勢は iOS 7 から一貫しており、そのための Liquid Glass だし、それゆえに Liquid Glass は装飾ではなく導入においてまずアプリの構造を見直すべきである、という趣旨と受け取った。

既存のアプリに Liquid Glass を導入は、ただ 最新の Xcode でビルドすれば対応が完了するというレベルでないことを示しており、デザイナーはもちろんだが、開発者もこの思想を深く理解した上で取り組む必要のある大仕事だと心構えるべきだと感じた。


  • Design language
    • デザインシステムの設計において:
      • 細かなディテイルの及ぼす影響に焦点を当て
      • すべてのレベルに意図を込め、小さなコントロールから大きなサーフェスまで、すべての要素と全体との関係性を考慮した
    • システムカラーファミリー:ライト/ダーク/コントラスト比を上げた状態(Increased Contrast appearances)すべてにわたって機微に調整され、Liquid Glass と調和を持っている
    • タイポグラフィの再定義:明確さと構造を強めるため、bolder かつ left-aligned として視認性を高めている
    • もっとも意義深い変更:シェイプの扱い方
      • ハードウェアの一貫したベゼルと同じ精度でUIを揃える(曲率/サイズ/比率)
      • 3つのシェイプタイプ
        • Fixed:一定の角丸
        • Capsule:高さ / 2 の角丸
          • 自然と同心性が与えらえれる:システム全体で用いられている(スライダー、スイッチ、バー、ボタンなど)
          • タッチフレンドリーなレイアウトに focus と clarity をもたらすが
          • 高密度なレイアウトを持つデスクトップ環境では:
            1. mini, small, medium controls: rounded rectangle
            2. large controls: capsule
        • Concentric:親要素とのパディングから計算した同心な角丸
        • プロダクトのUI要素が Liquid Glass と調和することが重要(システムのリズム&トーンを破壊せず、引き立てるべき)
        • 3つのシェイプを使い分けることで、システムと親和性を持ち、Apple API の扱いも容易になる
      • 自身のアプリをアップデートする際、角丸が詰まりすぎたり flared でないことに注意
        • e.g. nester container → concentric or capsule
        • tips: use concentricShape
  • Structure
    • Liquid Glass を最大限活用するために:
    • アプリが immersive かつ content-focused になるにつれ、必要に応じたインタラクションのサポートが必要:落ち着き (unobtrusive) を維持しながら
    • Liquid Glass:コンテンツに浮かぶ新しい funcitonal layer
    • Depict relationships
      • サーフェスとの関連性を明確に表現すること
      • どのように出現し、その source と関連し続けるか、空間的でもあり grounded でもありながら
      • 旧来の action sheet:画面下から出現 → どのアクションと紐づくか不明瞭
      • Liquid Glass ではアクションボタン (source) から action sheet を出現させる
      • 関連付けを明確にするため、それがタップ要素から直接拡張したようにインタラクションを ancohring する
    • Reflect navigation focus
      • マテリアルの細かなバリエーションにより、ナビゲーションが深まったりシフトする際に、その意図を引き立たせる
      • cue: モダリティを示唆する dimming layer e.g. sheet
        • タスクがメイン導線を interrupt していることを、Liquid Glass と dimming layer とをあわせて表現する
        • sheet が引き上げられるごとに、さらに不透明度を高め、より深いエンゲージメントを与える
    • Elevate controls
      • 旧来はコントロールはその背景に溶け込んでいた
      • Liquid Glass はそれらを持ち上げ、背景のコンテンツとより分離をもたらし、インタラクティブ可能であることを強く示唆する
      • Clean up your bars
        • 装飾にこだわるよりも、階層がレイヤやグルーピングによって表現されるべき
    • Organize for legibility
      • 正しくAPIを用いることで自動的にバーアイテムはグルーピングされ、背景を共有することで、見やすさと空間的な明確さをもたらす
      • もし期待通りにならなければ
        • bar がごちゃついていたら: 不要なアクションを secondary action に移動する
      • シンボルとテキストをグルーピングしないように
      • プライマリアクションは分離させ、色をつけること
      • tab bar:
        • 検索が基本
        • accessory view:画面固有のアクションを置かないように (e.g. checkout button)
    • Prioritize content
      • Liquid Glass はその見やすさを維持するために、コンテンツとの分離が必要
      • Scroll Edge effect
        • decorative ではない:オーバーレイのようにblock したり暗くしたりしない
        • スクロールビューは自動的にそれを覆うコントロールがあれば edge effect を表示する (soft / hard)
    • Extend to the edge (e.g. sidebar)
      • Background extension effects
  • Continuity
    • 他のデバイスを行き来して作業してもユーザー作業は継続している
    • デバイス・キャンバスサイズごとに最適化されたレイアウト
    • User shared content
      • 意図的にグルーピングはレイアウトに寄らず維持されるべき
      • 同じ意味に同じシンボルを使うべき
        • しかしラベルを用いた方が伝わりやすい場合もある
      • Liquid Glass において bar はテキストよりもシンボルに依存しており、この変化はプラットフォームによらない
        • メニューではラベルに加えてシンボルを伴った方が認識を助ける
        • ただし共通のアクションに対するシンボルの反復や異なるアイコンを割り当てることは避け、省略する
    • Structure components to scale
      • Define a shared anatomy:コンポーネントのある部分はプラットフォームをまたいで共有されるべき
      • Support core interactions:核となるインタラクションを共有することで、プラットフォーム間における構造の変化を、その振る舞いが埋める

WWDC25:Meet Liquid Glass

WWDC25セッションビデオのはじめに、「Meet Liquid Glass」を観たのでメモ。1日3本くらい観られるかと思ったが、このビデオの内容が思いのほか深く何度も見返したので時間がかかった。日本語字幕を読んでも腑に落ちない部分があり、特に抽象的な説明は英語字幕も併用し、英単語を調べなおしながら何度も見返した。

fluid という単語が何度も登場し、Designing Fluid Interfaces で語られていたことをLiquid Glass というマテリアルとして体現したものと理解した(発表者も同じ方)。ユーザー操作に対する即応性に加えて、コンテンツとコントロールとを区別させる表現手法として、光の屈折現象を活かしているという理解。

Liquid Glass への塗り色指定(従来のベタ塗りに対して new tinting と強調されていた)は背景のコンテンツに応じて微調整されるらしい。これは実際の色付きガラスを参考に実現したようだ。実際にどんな挙動をするのか確かめてみたい。

一部、自動的に処理されるのか、開発者が意識して実装する必要があるのかが分からなかったので、他のセッションを見ることで理解が補完されるかもしれない。


  • 動的に光を屈折させる「デジタルメタ素材」
  • Dynamics(動的特性)
    • 形状
      • 丸みがデバイスのカーブに馴染む
      • 形状の定義が明確でタッチしやすい
      • 指の自然な幾何特性を反映しタッチ操作時に親しみを感じる
    • レンズ効果
      • 従来のブラー効果が光を散乱するのに対し、自然界に存在し日常的、直感的、生得的に知っている光学特性を反映(instinctive visual cues)
      • コントロールは超軽量に感じられ、視覚的な区別を維持しながら透明
      • Liquid Glass において、visual と motion は一体として設計されている
        • 生得的に知っている液体の動き:滑らか、responsive、ごく自然 (effortless) な動きやふるまい
        • 操作に対し即座に反応し、光により活力を帯びる (energize)ことで、responseive で、満足感と溌剌を感じられる
        • ジェルのような flexibility, fluidity が、思考や動作のダイナミズムと一致する
      • UI 要素を一時的に Liquid Glass として浮かび上がらせることも可能
        • コントロールに有効:操作時と非操作時の区別
        • 透過してコントロールの値を見ることができる
    • Fluidity
      • この fluidity は操作への反応性に加え、アプリ動的な環境変化への反応性も拡張する
      • コンテキストに応じて動的に変形するコントロール:1枚の浮き上がった平面にこのコントロールが配置されている、というコンセプト
      • アプリ内異なるセクション間の移行において、コントロールが絶えず変形することで、fluid でシームレスに感じさせる
        • e.g. メニュー
        • タップしたその場所にメニューが展開される(in-line transition)ことで、ボタンと展開したコンテンツとの関係性を明確に伝える
    • Liquid Glass によってアプリ体験を根本的に、有機的・イマーシブ・fluid に変革する
  • Adaptivity(コンテクストへの自動適応)
    • 明瞭さ
      • コンテンツレイヤーと区別できる視覚的な明瞭さを持つ
      • そのために、常に微妙な変化を持たせている
        • スクロールやコンテンツのライト/ダークに応じ
      • 大きなサイズに変化する(toolbar button → menu)時、厚みと素材感を高める(影や屈折が顕著、光を柔らかに散乱)よう変化し、奥行きを生み、ガラス上のコンテンツを読みやすくする
    • プラットフォーム間の統一
      • 隣接するコンテンツからの光、色を反映し、浮き上がりを強める
      • iPad/Mac の floating sidebar:アプリの画面サイズに応じて柔軟に拡縮し、統一感と一貫性を生み、単一のナビゲーションであることを示す
    • Scroll Edge Effects
      • Liquid Glass と連携、特にスクロールするコンテンツの読みやすさを高める
      • ナビゲーションバーなどタイトルを浮立たせるぼかし効果のこと
      • hard style effect: 固定されたアクセサリビューなど、視覚的に分離したいときに有効 e.g. Finder
  • Liquid Glass の構造と挙動(自動で処理される)
    • 複数の層から成り立つ
    • Highlights layer ハイライトレイヤー
      • 周囲の物理世界と同じく、光源からの光を受け、エッジにハイライトを生む
      • ロック/解除のような状態変化に伴って、空間内を光源が移動する
        • ガラス周囲を光源が移動することで、シルエットが浮き立つ
        • デバイスの動きにも追従し、実世界に位置するような感覚を生む
    • Shadow 影
      • Liquid Glass が平面上にある (grounded and defined) 認識を手助けする
      • 背景のコンテンツレイヤーに応じて、コンテンツの上では不透明度を高め、逆に明るい無地上では不透明度を低めることで、見つけやすくなる
    • Illumination
      • 操作されると素材の中から光が生じることでフィードバックを与える
  • どのように/いつ 使うべきか
    • ナビゲーションレイヤーに留めるべき
    • glass-on-glass を避けるべき
      • 上の要素に 塗りつぶし、透明性、vibrancy を適用し、オーバーレイとして表現する
  • Variants(バリエーション)
    • Regular / Clear
      • Regular は汎用的、サイズに多様性あり、全面背面のコンテンツを問わない
      • Clear は3つの条件を満たす場合
        • media-rich なコンテンツの前
        • dimming layer によってコンテンツが悪影響を受けないこと
        • 要素の前面に、bold (明るくはっきり) content を置くこと
      • Clear の読みやすさを確保するために(自動で処理される??)
        • ラベルの読みやすさを確保するには「レイヤーの光を微弱にし」背景を暗くするべき
        • Liquid Glass が小さい場合は localize dimming (光の抑制) により、元の vibrancy を維持することが可能
  • Legibility(読みやすさ)
    • 小さな要素(nav bar, tab bar)
      • 背景コンテンツに応じ見た目を適応(constantly adaptive appearance)
      • 背景に基づきライト/ダークを切り替える
    • 大きな要素(menu, sidebar)
      • コンテキストに応じ適応するが、
      • ライド/ダークを切り替えない:表面積広くユーザーの気が散るため
    • ラベル上のシンボル・グリフも、ライト/ダークに応じ、ガラスと共にコントラスト比を維持する(自動的に)
    • カスタムカラー
      • ラベルの配色
        • 注意を引くアクションにのみ色を使用する
      • 背景色:背後のコンテンツの明るさに対応した色調が生成される (new tinting)
        • 強調する目的でのみ使うべき(アプリの主なアクション)
    • 動きのない画面(初回起動など)ではコンテンツと Liquid Glass を重ねるべきではない(??)
  • アクセシビリティ
    • 透過度を下げる、コントラストを上げる、示唆効果を減らす に対応

WWDC25:開幕、基調講演の感想

今年もWWDCの季節がやってきた。例年と変わらず、2時前に起きて基調講演をリアルタイム(録画だが)で視聴し、5時からの Platforms State of the Union もチェックした。

筆者のWWDC初日の楽しみ方は、前夜から始まっている。コンビニでお菓子など買っておき、早めに就寝。といってもすんなり寝付けた試しはなく、だいたい眠れたかどうか分からないまま、午前 1:45 のアラームで起床。前夜に揃えた食べ物飲み物を準備して、ストリーミングを画面を前に待機、、例年、基調講演は iPad やデスクのモニターに映すのだが、今年は Vision Pro 上で観てみた。WWDC24 期間後に販売開始されたので、初の試みである。

WWDC keynote on Vision Pro

基調講演中は自分用に気になった点をメモしている。外部公開用ではないので、本当に個人的な感想や妄想を書き記している。今年は Vision Pro を被りながらなので、視界の下隅で MacBook の画面を見ながら映像とメモとを行き来してた。基調講演後は、気になったスライドやシーンを写真やスクショにおさめて、それらを日記にまとめるまでが、初日のルーチンになっている。

今年も例に違わず、仕事以外の時間はそんなことをして過ごした初日だった。特に今年は、かねてより噂されていたデザイン刷新をはじめ内容が盛りだくさんだった。


とはいえその大半が、Marc Gurman 氏によって事前にリークされた情報通りであった。日が近づくにつれてリークの頻度とディティールが増していったため、当日はただの答え合わせだけになってツマらないかも、と懸念していたが、蓋を開けるとそれはまったくの杞憂だった。今回の基調講演の内容には、そんな暴かれた筋書きを凌駕するサプライズが詰まっていた。

まず、新デザイン言語の Liquid Glass について。グラス調UIへの転換は今日を迎えるまで数々のリークやモックがインターネット上で量産され続けてきたが、蓋を開けてみればそのすべてが、実際のほんの表面しかなぞらえていなかったことが明らかになった。誰の想像をも圧倒する美しさ、完成度を Liquid Glass は携えていた。

「グラス」モーフィズムとは、iOSのデザイン刷新が噂にのぼるたび、それがいつからか思い出せないほどに長い間ささやかれ続けてきた言葉だが、liquid の名が示すように、このデザイン言語が示したのは只の見た目やあしらいではなかった。実際に beta 版を触ってみて感じたのは、どんなユーザー操作も逃さずにフィードバックしてくれるUIの即応性、それは指によるタッチやドラッグ操作に限らず、アイコンなどのエッジに輝くハイライトがデバイス本体の傾きに追従することも含む。従来スクリーンがアプリ世界だけを映し出していたのに対して、Liquid Glass の表現する世界観は、アプリという物体を如何に実世界に溶け込ませるか、であると感じる。それはまるで visionOS が仮想コンテンツをリアル空間に持ち出したように。そしてこうした視覚的な変化に加えて Liquid Glass の実現した高い精度の光学的表現が、ソフトウェアへ実存感を与えるにとどまらず、むしろ現実を超えてシュールささえもたらすことで、親しみや楽しみを醸成していると感じた。

そういえば、最近気に入ったアプリ、(Not Boring) Camera も、物理を模したUIの影が、デバイス傾きに追従している。

https://twitter.com/p0dee/status/1930867577104044193

いっぽうで今、Xをはじめとして Liquid Glass は手離しで評価されているわけではない。特にグラスマテリアルはその背景に対しコントラスト比が低く視認性が悪い。betaを触っていて、筆者はあまり気にならないが、アクセシビリティの観点では確かに片手落ちに感じた。が、iOS 7の時もそうであったように、Apple は初版ではコンセプチュアルな方向に振り切りつつもマイナーチェンジを重ねながら実用性に擦り合わせていく傾向があると思っているので(Apple Watch や Vision Pro もそう)、9月のリリースには致命的な点は解消されていると思う。

視認性や統一性の課題やバグを多く含み、混迷を極めた iOS 7 の初期 beta

その他、iPadOS の macOS 回帰が印象的で、macOS ではおなじみの Exposé 搭載が今このタイミングで発表されたことは、同機能がリリースされた Mac OS X 1.03 からたどった進化の系譜を20年越しに引き継いだという歴史の重みを感じて心が熱くなったし、ここ近年 iPadOS や macOS にばらばらと搭載され無秩序に感じていた、ウインドウマネジメントシステムの数々が、ようやく秩序だって集結したことにも、これまでの「仕込み」の点同士が一気に像を描くようで強く納得感を覚えた。さすがアップルだな、、と。

iOS 18 における Control Center のリデザイン、Apple Intelligence のチグハグ感否めない独特なデザインや使い勝手、唐突なホーム画面のカスタマイズ機能、少し遡るとこれもまた独特な使い勝手の Widget 選択画面に至るまで、、あちこちに散りばめられていたパズルのピースが、すべてこの日のために用意されていたと思うのは、考え過ぎだろうか。

まだ他にもある。macOS の Spotlight 機能が高機能化したのは、⌘+space が手癖となっている Spotlight ヘビーユーザーの筆者としては嬉しいポイント。作業コンテクストに応じてショートカットコマンドを組み込む Quick keys は、Spotlight という羊の皮を被った Shortcuts ないし Apple Intelligence ではなかろうかと思っている笑 完全に、Alfred に代表される 3rd-party ロンチャーアプリキラーだった。

あと、Xcode へのコーディングエージェントの搭載は、筆者が感知した範囲ではリークになかったので、個人的には実質の One more thing… であった。


手元メモにはもっと雑多にいろんな感想を記しているが、キリがないのでここまでとする。最後に基調講演の締めに流れた「Real App Store review」について。レビューを歌に乗せて紹介するというユニークな演出だが、可笑しさとともに Apple の一貫したある姿勢を垣間見て素晴らしいなと思った。 AI が発展し続けるこの先も、作り手である人間が価値創出の中心である、、そんなクリエイターに対する賛美だと感じた。

と、、Apple 信者感全開な投稿になったが、本当は1日1セッション紹介しようと思いつつもまだ何も観れておらず、ありものの情報で書いただけである。明日からはしばらくセッションの内容メモを綴っていきたいと考えている。