カテゴリー: WWDC25

WWDC25：Integrate privacy into your development process

プライバシーをプロダクトに組み込むための観点、手法を開発ステップごとに解説。

0:00 – Intro

  • プライバシーは単なるバズワードではなく、誰もがデータを注意深く尊重して扱われるべき
  • Steve Jobs の定義：人々が何にサインアップしているかを平易な言葉で繰り返し理解できること → 人々がデータに対して正しい選択ができるようになる
    • 人々の意図に対する一貫性をためつためにできること：尋ねること
  • プライバシーの 3 つの重要な概念：人々(People)、データ処理の影響(Data)、情報の文脈(Context)
  • Apple のプライバシー原則：data minimization, on-device processing, transparency and control, security protections

0:38 – How does Apple think of privacy?

  • People：プライバシーとは人々がテクノロジーとどのように相互作用し、それがどのように影響するか
  • Data：データ処理の影響：アプリを使用する人々について知っていることを何に使用するか
  • Context：情報の文脈、特に期待と好みを考慮する必要がある
  • 人々のデータを委託された際に、その文脈を尊重すること
  • データを使って「何ができるか」ではなく、ユーザー利益のために「何をすべきか」を問うこと
  • データ最小化、オンデバイス処理、透明性と制御、セキュリティ保護の 4 つの柱
  • ソフトウェア開発のライフサイクル：計画→設計→開発→テスト→展開

3:47 – Planning (計画)

  • プライバシー保証（privacy assurances）を定義して、アプリのプライバシーストーリーを書き始める
  • プライバシーは開発の最初から組み込む必要があり、後から追加するのは困難
  • Data minimization: 人々の期待に合わせるために必要最低限のデータのみを使用
  • Strong defaults: 人々のプライバシー選択について最小限の仮定から始める
    • e.g. 近くの場所を検索するときのデフォルト→現在地は保存されない
  • On-device processing: データが文脈を越えてデバイス→サーバー、アプリ間などの境界を越える際の必要性を慎重に検討
  • Transparency and control: データの使用方法について期待を設定し、カスタマイズオプションを提供
    • e.g. 「アップロードした写真はAI機能改善目的にopt-inした場合のみ利用される」
  • Security protections: 技術的制御でプライバシーをサポート
    • e.g. end-to-end encryption

7:13 – Design (設計)

  • 優れたデザインにより、人々とコミュニケーションし、教育することができる
  • Proactive expectation setting (積極的に期待を設定): 起動時に提示し、アプリが収集するデータや使用方法について、人々が不意を突かれることがないようにする
  • Clear state changes: プライバシーに影響するデータフローの変更を理解できるようにする
  • Meaningful and contextual choices: データに関する選択は意味があり、文脈に適したものであるべき
    • アクセスが必要になった際に初めて有効オプションを提示する
  • 選択が最も関連性が高いときに表示し、適切なバランスの粒度を研究する

9:27 – Development : User interface

  • デバイスリソースへのアクセスは、異なる文脈間で機密データを共有することを意味
  • PhotosPicker: 写真ライブラリのプロンプトを完全に回避し、選択された写真のみを受け取る
  • Location Button: ワンタップで現在位置を共有でき、ユーザーインタラクションでトリガーされることを検証
  • Secure UI elements: 連絡先の out-of-process picker, UIPasteControl button, ハードウェアアクセサリの設定フロー
  • 必要最小限のデータにアクセスするオプションを確認してから、より広範な API を使用

12:48 – Development : Client-server

  • Advanced Data Protection: iCloud に保存されたデータの end-to-end 暗号化を有効化
  • CloudKit: 暗号化されたデータ型を使用し、encryptedValues API でデータを取得・保存
  • Homomorphic encryption: 暗号化されたペイロード上で計算を実行
  • Private Information Retrieval (PIR): サーバーがクエリや結果を復号化された形式で利用できないようにする
  • Private Access Tokens: 正当なデバイスからのリクエストを保証し、使用する人々を特定しない
  • DeviceCheck: デバイス識別子を追跡せずに、特定のデバイスに最大 2 ビットの情報を関連付け
  • AdAttributionKit: プライバシーを維持しながら広告キャンペーンの成功を測定

18:20 – Development : local resources

  • Core ML: 機械学習モデルを完全にオンデバイスで実行、トレーニング、ファインチューニング
  • App group containers: 異なるアプリ間でデータを共有し、そのデータを保護
  • Process cleanup: macOS でアプリを終了する際にすべてのプロセスを終了
  • Third-party SDKs: プライバシーマニフェストファイルで収集するデータと使用する API を記述

20:46 – Testing (テスト)

  • プライバシー保証を提供することを確認するテストを構築することは重要なベストプラクティス
  • Testing Pyramid
    • Unit tests: 個々の関数を検証し、プライバシー制御をサポートするアプリロジックを検証
    • Integration tests: 異なるコンポーネントが正しく連携することを確認し、システム間のデータフローを検証
    • UI tests: ユーザー向けの動作を観察し、オンボーディングやプライバシー設定の変更などの一般的なシナリオを確認
  • App Privacy Report: iOS 15.2 以降で、データアクセス、センサーアクセス、ネットワークアクティビティを確認

22:28 – Deployment (展開)

  • Privacy nutrition labels: App Store がアプリのプライバシー慣行を理解するのに役立つ重要な方法
    • アプリアップデートなしに更新が可能
  • Privacy policy: 明確なプライバシーポリシーが必要
  • Privacy manifests: アプリとすべてのサードパーティ SDK のプライバシーマニフェストを Xcode に含める
  • Purpose strings: デバイスリソースにアクセスする権限プロンプトに必要 (Info.plist)
  • Privacy Choices link: App Store のリストに含めて、データの管理について詳しく学べるようにする (Optional)

WWDC25：Evaluate your app for Accessibility Nutrition Labels

Accessibility Nutrition Labels の解説に加えて、アクセシビリティ機能のひとつひとつを説明。以前聴講したアクセシビリティLT会の内容を思い出した。

当事者でなければ障害により生じる困りごとや不便は想像がつかないもの、、かくいう筆者も左耳難聴。某オーディオメーカー大手の某MP3プレイヤーにモノラル再生がなく驚いた経験があるが、多くの人にとってはなぜその機能が必要かは、すぐには理解できないとも思う。

かたや自らの携わるアプリが、Dynamic Type に対応できているか、Voice Over で不自由なく操作できるか、と問われると耳が痛い。このセッションビデオでは、4分以上にわたって Voice Over によるアプリ操作が実演されており、それを眺めるだけでも大きな示唆が得られた。標準的なデザインシステムに則ることが、単に視覚的一貫性をもたらしているだけではなく、その標準性を頼りにせざるを得ないユーザーがいることを、意識から欠いてはいけない。

あるアクセシビリティの専門家が、アクセシビリティ対応ができていないことは「バグ」であると声を大にして言い続けていた。しかし実情は残念ながら、多くの開発現場では「アクセシビリティ対応」に優先的に工数を割くことはない。ただ開発者が常日頃、アクセシビリティの担保を念頭に実装することはできる（レイアウトの組み方やアクセシビリティラベルの付与）。

またいきなり完璧を目指さずとも、Principles of inclusive app design のセッションでも語られていたように、できていない現状を分析し、計画立てて段階的に解消していきたい。そういう意味で、Accessiblity Nutrition Labels の存在は対応状況を可視化し、他アプリとの比較を容易とするので、対応の取り組みを後押ししてくれそうである。

0:00 – Welcome

  • Accessibility のソフトウェアエンジニアとデザイナーによる、Accessibility Nutrition Labels の評価方法について紹介
  • アプリのアクセシビリティを App Store の商品ページでハイライトする方法
  • コアとなるアプリアクセシビリティの原則と、サポートできる機能の説明
  • VoiceOver, Voice Control でのテスト方法、アクセシブルなメディアの提供方法をカバー

0:58 – Meet Accessibility Nutrition Labels

  • 最高のテクノロジーは誰もが使えるものであるという信念
  • Accessibility を考慮したアプリデザインにより、より多くの人々にアプリを提供
  • Accessibility Nutrition Labels は App Store でアプリがサポートする機能を紹介
  • ユーザーが依存する重要な機能をサポートしているかを知ることができる
  • アプリの common tasks（主要機能）すべてをユーザーが実行できなくてはならない
    • 主要機能を定義する
      • ダウンロードしたきっかけとなる機能
      • それ以前に不可欠な機能（e.g. 初回起動、ログイン、購入、設定）
    • 基本タスクに対し Accessibility Nutrition Labels の機能ごとにアプリを評価する
    • 対応できている機能／できていない機能を特定する
  • アプリがサポートするすべてのデバイスでテストする必要がある
  • 機能がアプリの機能に関連しない場合は、サポートを示さない
  • 正確性を確保するため、Accessibility Nutrition Labels のドキュメントを参照

3:06 – Evaluate your app

  • アクセシビリティはデザインから始まる（Design for everyone）
  • アクセシビリティ機能について理解する（Learn accessibility features）
  • 障害者コミュニティとつながる（Connect with community）
    • 障害当事者によるテストが、アプリのアクセシビリティを知る上で重要
    • “Nothing about us withou us”（私たちのことを私たち抜きに決めないで）
  • Sufficient Contrast: 前景色と背景色の間に十分なコントラストが必要、Increase Contrast 設定でも確認
    • Light/Dark mode 両方で対応が必要
  • Dark Interface: 光に敏感な人や暗い背景を好む人のため、dark mode 設定をサポート
    • Smart Invert の有効時に、どのメディアの色も反転しないように
  • Larger Text: テキストサイズを少なくとも 200% 大きくできるように設計、Dynamic Type の使用を推奨
  • Differentiate Without Color Alone: 色だけでなく、形状、アイコン、テキストも使用して情報を伝達
  • Reduced Motion: めまいや吐き気を引き起こす可能性のあるアニメーションを特定し、変更または削除
    • ズーム、スライドトランジション、フラッシュ、点滅、自動再生アニメーション、視差エフェクト
    • Reduced Motion 設定をオンにして、上記アニメーションがないか確認
  • Voice Control: 音声コマンドでアプリのすべての部分とインタラクションできるようにする
    • ボタンタップ、スワイプジェスチャー、文字入力、といった操作がもれなくできるか確認
    • accessiblityLabel に設定されたボタン名をシステムがオーバーレイ表示、その名前が読み上げられたら Voice Control が操作してくれる（e.g. ボタン名）
  • VoiceOver: 画面を見ずにインターフェースをナビゲートできるようにする
    • 使い方：VoiceOver を有効にし、右スワイプしてボタンをひとつずつフォーカスしてみる（名前と要素タイプが読み上げ）
    • 指をドラッグして VoiceOver に読み上げさせ、画面のレイアウトを把握する
    • （VoiceOvevr で特定タスクの完遂を実演）
  • Captions: 動画や音声コンテンツにキャプションを提供
  • Audio Descriptions: 視覚コンテンツの説明を音声で提供
    • ADアイコン

21:44 – Indicate feature support

  • App Store Connect で商品ページに Accessibility Nutrition Labels を追加
  • アプリのアクセシビリティに関する追加詳細を提供するウェブサイトへのリンクも追加可能
  • サポートする機能を選択し、準備ができたら公開
  • 障害を持つ人々とパートナーシップを組み、VoiceOver, Voice Control などの機能の使い方を学ぶ
  • デザイン段階からアクセシビリティを考慮し、common tasks を通じて各機能をテスト
  • アプリのアクセシビリティサポートを Accessibility Nutrition Labels で紹介

WWDC25：Make a big impact with small writing changes

UXライティングに関するセッション。Don’t use をまとめるのは良さそう。

0:00 – Introduction

  • UX ライターによる、アプリの文章を改善するための 4 つの小さな変更について紹介：簡素化が重要
  • Apple の新しいデザインシステムを考える際に、文章も見直す絶好の機会
  • 4 つの修正を提案：フィラーワードの削除、繰り返しの回避、why を先に述べる、word list の作成
  • これらの小さな変更がアプリに大きな影響を与える

1:18 – Remove fillers

  • アプリには最小文字数がないため、不要な単語を削除することが重要
  • 副詞（easily, quickly）や形容詞（fast, simple）は多くの場合 filler として機能
  • 例：「Simply enter your license plate number to quickly pay for parking」→「Enter your license plate number to pay for parking」
  • 感嘆詞（oops, oh no）や丁寧語（sorry, thank you, please）も意味を追加しない場合は削除
  • 配達遅延の通知例：「Uh oh. We’re running late」→「We’re running late」
  • 各単語に付加価値があるかを確認し、そうでない場合は削除

6:12 – Avoid repetition

  • 繰り返しの言語も filler の一種
  • 同じことを異なる方法で言うことで空きスペースを埋めようとしない
  • 例：「Your delivery driver won’t make it on time」→「We’re running late」は同じ意味。「Delivery delayed 10 minutes」のように 1 つの文にまとめる
  • UX writing は言語の経済性が重要
  • 利用可能なスペースを繰り返し情報で埋めようとしない

7:13 – Lead with the why

  • メッセージは、次のステップを取ることが楽しい、興味深い、有益である理由を最初に伝えると最も効果的
  • 「To do or get one thing, first do another thing」のパターン
  • 例：「Enter your phone number to get reservation updates」→「To get reservation updates, enter your phone number」
  • エラーメッセージ、プッシュ通知、指示文でよく見られる
  • 利益を文の最後ではなく最初に移動することで、メッセージの影響力を向上

9:23 – Make a word list

  • アプリで使用する単語と使用しない単語をリスト化
  • 開発の初期段階で行うのが理想的だが、どの段階でも可能
  • 表形式で、使用する単語、使用しない単語、簡単な定義を整理（Use / Don’t Use / Definition）
    • 例：ゲームアプリで「alias」を使用し、「Handle, User Name, Title」は避ける
  • 包括的な word list を作成することに圧倒されず、まずは一度に 1 つの単語を追加
  • Apple Style Guide を参考にすることも推奨
  • ボタンラベルなども word list に追加することで一貫性を保つ
    • 同じアクションに同じボタン名（e.g. Next）
    • 一貫性により、アプリを使用する人々に明確さを提供

WWDC25：Principles of inclusive app design

インクルーシブデザインの中でも障害（disability）に焦点を当てたセッション。インクルーシブデザインやアクセシビリティデザインの文脈において、身体的に永続的な障害に目が向けられがちだが、環境要因で誰しもその状態に当てはまりうることは常々意識したい。またインクルージョンへの考慮は果てしないものだと思っていたが、現状理解と計画を持って解決していくこと、ギャップをイノベーションの機会と捉え取り組むことというメッセージに心に火がついた。

0:00 – Introduction

  • アクセシビリティデザイナーによる、障害を持つ人々を含むインクルーシブなアプリデザインについて紹介
  • 世界の約 7 人に 1 人が何らかの障害を持っており、障害は人間の普遍的な部分
  • 障害をデザインに含めることで、より多くの人々にアプリを提供し、創造性も向上
  • インクルーシブデザインにはアプリ多言語の翻訳、人種、民族への影響への配慮、世界中の文化の包摂などの観点もあるが、今回は障害に絞る
  • 大音響後の一時的難聴、大声の会話ができない、多言語環境に身を置くといった環境的要因で障害を経験することもある
  • Vision, Hearing, Motor, Speech, Cognitive の 5 つのカテゴリで障害を考える
    • 障害の有無は全か無かだけでなく、その間の「いくらか」の程度が存在する

3:55 – The inclusion gap

  • 障害は身体や心の特性ではなく、環境に大きく依存
  • 社会が期待することと個人が実際にできることの間にギャップが生じる
    • 生まれて死ぬまでの能力の曲線は人により様々
    • この「インクルージョンギャップ」が障害を生み出す
  • 人のできることは、環境のデザイン、構築により左右される→「できる力」を与えるモノ作り
    • エレベーター、マイク、メガネ、curb cuts など、多くのイノベーションがこのギャップから生まれた
  • 「Nothing about us without us（私たちのことを私たち抜きに決めないで）」の原則で、障害を持つ人々を意思決定に参加させる重要性
  • アプリをよりインクルーシブにするための4つの実践を紹介

8:55 – Support multiple senses（複数の感覚に配慮する）

  • 複数の感覚を通じてアプリとインタラクションできる方法を提供
    • 動画のキャプション、視覚的な情報、音声での体験など、様々な方法で情報にアクセス可能に
  • 情報の取得方法、入力方法を多様化（視覚、聴覚、触覚、声、認知能力）することが、インクルージョンギャップを埋める第一歩
    • Accessibility Reader の例：視覚的テキスト、音声読み上げ、ハイライト付き読み上げの 3 つの方法
    • Crouton アプリの例：画像、カメラ、テキスト、Hands Free モードなど多様な入力方法

12:36 – Provide customization（カスタマイズ性を持たせる）

  • UI とインタラクションを個人のニーズに合わせてカスタマイズ可能に
    • Accessibility Reader の例：テキストサイズ、色、フォント、音声設定の調整
    • Carrot Weather の例：データ豊富なレイアウトからシンプルなインターフェースまでカスタマイズ可能
  • アプリが人に適応するのではなく、人がアプリに適応することを期待しない

14:27 – Adopt Accessibility API（Accessiblity API を採用する）

  • アシスティブテクノロジーと連携するために Accessibility API を採用
  • VoiceOver, Switch Control, Voice Control, Larger Text などの機能をサポート
  • Accessibility API により、開発者が独自に実装することなく、障害者インクルージョンを簡単にサポート
  • アクセシビリティリーダー：Accessibility API を統合、スイッチコントロールにより画面に触れずに操作可能（iPhone とペアリング可能な物理ボタンにアクション割り当て）
  • Blackbox ゲームの例：オーディオや触覚デザインに加えて VoiceOver API で視覚障害者もパズルを解けるように設計

18:46 – Track inclusion debt

  • インクルージョンは旅であり、一度限りのものではない
  • inclusion debt（インクルージョン不足）を認識し、計画を立てて意識的な決定を行う
  • アプリに存在するギャップを理解し、障害を持つ人々と協力してギャップを埋める
  • インクルージョンギャップは創造性とイノベーションの機会
  • App Store でアプリのアクセシビリティをハイライトすることで、ユーザーが重要な機能をサポートしているかを知ることができる

WWDC25：Design foundations from idea to interface

デザインに関するセッション。情報設計が主な内容。普遍的な内容なので開発者やデザイナーだけでなく、プロダクトに携わるあらゆるロール・ポジションが把握するべき内容。

0:00 – Introduction

  • デザインエバンジェリズムチームによる、アイデアからインターフェースまでのデザイン基盤について紹介
  • アプリが「うまく動作する」体験と「動作しない」体験の違いを理解し、シームレスな体験を構築する方法を説明
  • 構造、ナビゲーション、コンテンツ、ビジュアルデザインの 4 つの基盤要素を体系的に解説

1:11 – Structure

  • 次の質問に明確に答えられるか？
    • Where am I?：現在地と、どう辿り着いたかがすぐに分かる
    • What can I do?：動作は明確で理解しやすく、推測が不要である
    • Where can I go?：次のステップを明確に意識できる
  • 情報アーキテクチャの重要性：情報を整理し、優先順位をつけて、ユーザーが必要なものを簡単に見つけられるようにする
  • 1 List every feature：アプリの機能、ワークフロー、ニーズをリストアップし、ユーザーの使用シーンを想像して整理（ここでは省かない）
  • 2 Learn from peaple：ユーザーがどう使うかを想像する。いつどこで？ルーチンにどう合わせる？助けや邪魔になるもの。答えをリスト化
  • 3 Organize insight：本質的でない機能を削除し、明確でないものを名前変更し、自然にグループ化
  • 明確な構造により、ユーザーが「どこにいるか」「何ができるか」「どこに行けるか」を理解しやすくなる

4:55 – Navigation

  • Tab bar コンポーネントを使用して主要機能へのアクセスを提供
    • What deserves a tab?：タブ数を最小限に抑え、本質的な機能のみをタブに配置
    • アクション（Add）はタブではなく、使用される場所（Records）に配置
    • 迷ったら HIG に立ち返る
    • SF Symbols を使用して視覚的に一貫性のあるアイコンを提供
  • Toolbar でスクリーン固有のアクションを配置し、ユーザーの方向感覚を向上
    • タイトルと画面の名称を表示：画面が明確になり、移動やスクロール時の方向感覚を維持
    • アクション：タブバーの代わりに使用
  • Where am I? / What can I do? が明確化

8:19 – Content

  • コンテンツを重要度順に整理し、ユーザーが期待する順序で表示
  • Progressive disclosure（段階的開示）で、必要最小限の情報から始めて、インタラクションに応じて詳細を表示
    • Disclosure control の使用
    • 遷移前後でレイアウトを一致させ、前後の繋がりを与える
  • Grid の代わりに List コンポーネントを使用して構造化された情報を効率的に表示
  • コンテンツを時間、進捗、パターンでグループ化して整理
  • Collection を使用して画像やビデオのグループを動的に表示

13:28 – Visual Design

  • カラフルな要素にまっさきに目がいってしまう
  • 視覚的階層でユーザーの視線を重要な要素から順に誘導
    • 重要なものを大きく、コントラストを高く
    • テキストを長く、大きくしたり、言語を変えて検証：柔軟性が重要
    • System text styles を使用して一貫した階層と可読性を実現
    • テキストと画像の重なりでは、グラデーションやブラーで可読性を確保
  • 必要なのはまとまりのあるビジュアルスタイル（Use a cohesive style）
    • アプリの個性を表現する色パレットとビジュアルスタイルを確立
    • Semantic colors（label, secondarySystemBackground など）を使用して動的な色の変化に対応（外観でなく目的にちなんで命名）
      • コントラスト設定、画面環境、ダーク／ライトモード…

WWDC25：Meet SwiftUI spatial layout

SwiftUI による 3D レイアウトについて。

0:00 – Introduction

  • visionOS 26 で SwiftUI の新しい Spatial Layout 機能について紹介
  • 既存の 2D レイアウトツールとアイデアを使って 3D アプリケーションを構築可能
  • アニメーション、リサイズ、状態管理の組み込みサポートを活用

2:47 – 3D views

  • visionOS では全ての View が 3D になり、width, height に加えて depth, Z position も計算される
  • カスタムの debugBorder3D modifier を用いて解説
  • Model3D は Image と同様に固定の width, height, depth を持つ
  • Image, Color, Text などは depth が 0 で iOS と同様の動作
  • RealityView や GeometryReader3D は利用可能な depth を全て使用
    • 従来の SwiftUI と同じレイアウトシステム
  • scaledToFit3D モディファイアでアスペクト比を維持しながら 3D 空間にフィット可能
    • Window では width-height のアスペクト比はユーザー操作によって代わるが、奥行きの提案はウインドウで固定されている
    • Volume は深さもサイズ変更可能
  • ZStack の挙動

7:18 – Depth alignments

  • visionOS 26 で DepthAlignments が追加され、既存の Layout タイプを 3D View に適応
    • VStackLayout などで depthAlignment モディファイアを適用して深度方向の配置を制御 (e.g. VStackLayout().depthAlignment(.center)  {…)
    • front, center, back の標準的な depth alignment を提供
  • Custom Depth Alignment で DepthAlignmentID プロトコルに準拠した独自の配置を定義可能
    • e.g. .alignmentGuide(.customAlignment) { $0[DepthAlignment.center] }

11:41 – Rotation layout

  • rotation3DLayout モディファイアで View の回転をレイアウトシステムに反映
    • 従来の rotation3DEffect は視覚効果のみでレイアウトには影響しなかったが、rotation3DLayout はレイアウトも変更
  • 任意の角度と軸での回転をサポート
  • 例：カスタム実装の RadialLayout と組み合わせて 3D カルーセルを構築可能
  • 複数の rotation3DEffect を組み合わせて複雑な 3D 配置を実現

16:28 – Spatial containers

  • SpatialContainer で複数の View を同じ 3D 空間に配置（入れ子人形方式）
  • 3D alignment（bottomFront, topTrailingBack など）で配置を制御
  • 選択状態の表示や UI 要素の重ね合わせに活用
  • spatialOverlay で単一の View を別の View と同じ 3D 空間に重ねる
  • debugBorder3D modifier の実装方法
    • spatialOverlay で実装

WWDC25：Enhance your app’s audio recording capabilities

Vision Pro 用にオーディオを扱うアプリを開発しているのでチェック。実はオーディオ周りはほぼ体系的な理解なしに、つぎはぎで作ってきた経緯あり、ちゃんと勉強しようと思っている。

オーディオの記録とその編集や視覚化を同時に行えるのは魅力的。これまでオーディオファイルをローカルに保存し、その後ファイルを読み込んで波形表示するよう実装していた。このため、録音→UI反映に時間差が発生してしまっていた。ここで紹介されたアップデートで解決できるのかも。

0:00 – Introduction

  • iOS 26 で追加された音声録音機能の強化について紹介
  • 入力デバイス選択、音声キャプチャ、再生の API 更新を説明

1:02 – Input route selection

  • iOS 26 で AVInputPickerInteraction が追加され、アプリ内から音声入力デバイスを選択可能に
  • システム設定を開かずに、アプリ内で直接デバイス切り替えができる

3:06 – Recording with AirPods

  • iOS 26 で AirPods の高品質録音モード（bluetoothHighQualityRecording）が追加
  • コンテンツクリエイター向けのメディアチューニングで、音声と背景音のバランスを最適化
  • AVAudioSession と AVCaptureSession の両方でサポート
  • AirPods のステムボタンで録音開始・停止も可能

5:11 – Spatial Audio capturing

  • Spatial Audio の仕組み
    • マイク配列から3Dシーンを録音
    • ambisonics と呼ぶ形式に変換
    • 1次 ambisonics（FOB: First Order Ambisonics）として保存
      • 4つの9面調和関数コンポーネント（omni-component, x/y/z方向の垂直双極子）
  • 空間オーディオ再生だけでなく、オーディオミックスエフェクト用のAPIにより前景背景のバランス調整が容易に
  • iOS 26 で AVAssetWriter を使った Spatial Audio 録音が可能に
  • 新しい QuickTime Audio（.qta）形式で音声のみの Spatial Audio ファイルを保存可能
    • 複数のオーディオトラックをサポート
    • 2 つの音声トラック（ステレオ + Spatial Audio）と再生用情報のメタデータトラックで構成
      • ステレオは空間非対応デバイスでの互換性担保のため
  • MovieFileOutput でない独自ファイルを AVAssetWriter で構築する方法
  • AVCaptureSession で MovieFileOutput と AudioDataOutput の同時動作もサポート
    • AudioDataOutput はサンプルバッファへのアクセスを提供、エフェクトや波形描画が可能
    • 同時動作をサポートすることで、ファイル書き込みとサンプルへの処理や視覚化を同時に行える

11:04 – Audio Mix

  • iOS 26 と macOS 26 で Cinematic Framework に Audio Mix 効果の制御機能が追加
  • 前景音（音声）と背景音（環境音）のバランスを調整可能
  • ミックスモードは Cinematic, Studio, In-Frame の 3 つの基本モードと 6 つの追加モードを提供
  • AVPlayer では CNAssetSpatialAudioInfo と AVAudioMix で実装
  • AVPlayer を使わず AUAudioMix で直接処理も可能（AU: Audio Unit）
    • e.g. 話し声と環境音の分離
    • AU を使用し多くの設定が自動で行われる
    • AUAudioMix の使い方、SpatialAudioMixMetadata
    • 録音停止時に自動生成されるメタデータでチューニングパラメータを適用

WWDC25：Set the scene with SwiftUI in visionOS

シーン復元や物理空間との連携について。Clipping Margins でボリュームの領域外部にコンテンツを描画できるようになったのはありがたい。システム許容のマージン領域としてどんな値が取れるのか（たとえば床より下、天井より上、壁より向こうは許容されない？）が気になっている。

ユーザーの視点移動に応じたコンテンツの変化（onVolumeViewpointChange）も具体的にどのような情報の取れ方や、コンテンツへの活かし方が可能か実験してみたい。

0:00 – Introduction

  • visionOS 26 で追加された新しいシーン機能の概要を紹介
  • Window, Volume, Immersive Space の シーンタイプに追加されたAPI の解説

2:11 – Launching and locking

  • シーンのロックと復元（locking, restoration）API が追加され、物理空間の特定の部屋にウインドウやボリュームを固定できる（イマーシブ空間は復元されない）
    • ほとんどのユーザーが復元できることを望むため、シーン復元を優先するべき
    • 一時的、コンテンツ依存なUI、ワンタイムアクションなどには .restorationBehavior(.disabled) で復元を無効化可能
  • defaultLaunchBehavior でアプリ起動時に表示するウインドウを柔軟に制御できる
    • e.g. ウェルカム画面の表示
    • Info.plist Preferred Default Scene Session Role と起動ウィンドウの役割との一致が必要
      • e.g. Window Application Session Role 指定はボリュームが無視される
    • .defaultLaunchBehavior(.supressed)でアプリ再起動時の再表示を抑制
  • Unique Window で重複しないウインドウを作成可能
    • WindowGroup → Window

8:15 – Volumetric enhancements

  • surface snapping（物理環境へのスナップ）の対応
    • ウインドウは壁など垂直面に
    • ボリュームは机など水平面に
    • ウィジェットは垂直水平どちらも
    • surfaceSnappingInfo environment でスナップ状態を取得可能
      • isSnapped
      • ARKit によるスナップ表面の分類情報を取得可能
        • ユーザー許可が必要：Info.plist に設定
  • onVolumeViewpointChange modifier で、視点の切り替えに表示を追従
    • 例：視点を遮る壁を非表示にする
  • Presentations（popover, menu, sheet など）が Volume, RealityView, RealityKit でも利用可能に
    • presentationBreakthroughEffect で 3D コンテンツとの重なり方を制御
  • Clipping Margins API の追加
    • preferredWindowClippingMargins で、シーン境界外にビジュアル表現を拡張できる
    • 視覚のみでインタラクティブではない
    • windowClippingMargins environment で、システムによって許可されたマージンを取得

15:58 – Immersive space

  • Immersive Space で world recentering イベントや immersion style のカスタマイズが可能に
  • .onWorldRecenter でリセンタリングを検知（位置の再計算）
  • Progressive immersion style でのポータルのアスペクト比や範囲を調整可能に
    • .landscape, に加え .portrait
    • .portrait は iOS ゲームや多くの動きが含まれる体験に有効
  • Mixed immersion style で周囲環境に溶け込む
    • システム環境（e.g. 月）との共存も実現 .immersiveEnvironmentBehavior(.coexist)
  • Remote immersive space で macOS から Vision Pro へ Metal レンダリングを転送し、即時プレビューが可能
    • CompositorContent で CompositorLayer に SwiftUI の環境変数やモディファイアを適用可能

22:16 – Scene bridging

  • UIKit アプリでもシーンブリッジングにより SwiftUI の Volume, Immersive Space を統合可能
    • Safari なども Spatial Browsing でこの仕組みを活用
  • UIHostingSceneDelegate を使い SwiftUI シーンを UIKit/macOS アプリに追加できる
  • configurationForConnectiong でホスティングデリゲートクラスを設定し外部イベントにも対応可能

WWDC25：Better together: SwiftUI and RealityKit

SwiftUI と RealityKit の相互連携に関するアップデート。盛りだくさんすぎた。オブジェクト操作を細かくハンドリングできるのは良い。ポップオーバー表示など自前でやっていたことも実装が楽になりそう。update クロージャーについては、無限ループの危険性を含めてかなり尺を使って解説しており、使いこなすのは難しそう。

CESや「モデル」の意味違いなど、アップデート以外の基礎的なテーマも網羅していて、情報量の多さをフォローする優しさを感じた。

0:00 – Introduction

  • SwiftUI と RealityKit の連携強化について紹介
  • 3D モデルと UI を組み合わせた新しい体験を実現

1:24 – Model3D enhancements

  • visionOS 26 で強化された二つの機能
    • Model3D にアニメーション再生
      • Model3D は SwiftUI ビューとして SwiftUIレイアウトシステムに従う
      • Model3DAsset でアニメーションリソースを読み込み、AnimationPlaybackController で制御（再生・停止・シーク）が可能
        • AnimationPlaybackController が Observable に（例：time の変更監視）
    • ConfigurationCatalog からの読み込み
      • ConfigurationCatalog で Model3D を初期化し、複数の外観やボディタイプを切り替えられる（@State で参照）

6:13 – RealityView transition

  • ParticleEmitter などのコンポーネント追加には Model3D が対応していないので RealityView への切り替えが必要
    • Model3D が intrinsic size に基づいてレイアウトされるのに対し、SwiftUI の与えたられたスペースを RealityView がすべて占有し、レイアウト崩れが発生
    • realityViewLayoutBehavior 修飾子：.fixedSize, .flexible, .centered で制御
      • make クロージャ実装後 1度だけ評価される
      • RealityView の原点を再配置するだけ
  • RealityKit の Entity に直接アニメーションやエフェクトを追加可能
    • ParticleEmitter で作成したエフェクトをコンポーネントに適用可能
    • RealityKit がプリセット値を提供し、Reality Composer Pro で調整可能
    • entity-component system
  • RealityView / Model3D の使い分け観点

11:52 – Object manipulation

  • visionOS 26 で Object Manipulation API が追加され、SwiftUI, RealityKit 双方で 3D オブジェクトの移動 回転 拡大縮小が可能
    • SwiftUI では manipulable モディファイア
      • orientation でサポートする操作
      • intertia で慣性(重さ)設定
    • RealityView では ManipulationComponent
      • メモ：hoverEffect に .spotolight 指定
      • ManipurationEvents で ユーザー操作の開始終了、ハンドオフ（e.g. 右→左）などに応じた応答を実装可能（サウンド再生）
      • カスタムサウンド再生は、manipulationComponent.audioConfiguration = .none で無効化し、イベントサブクライブ内部で自前実装

15:35 – SwiftUI components

  • SwiftUI を RealityKit エンティティに統合するための３つのコンポーネント
    • ViewAttachmentComponent：SwiftUIビューをエンティティに直接追加
    • GestureComponent：エンティティに通常の SwiftUI ジェスチャをアタッチ、ジェスチャー値はエンティティの座標空間で報告
      • ジェスチャー対象のエンティティに、InputTargetComponent, CollisionComponent 両方を追加
    • PresentationComponent：RealityKit シーン内から SwiftUI ビューを popover のように表示

19:08 – Information flow

  • visionOS 26 で Entity が Observable になり、SwiftUI との双方向データ連携が可能
  • Entity の位置、拡大縮小、回転など状態変化を SwiftUI View で監視し、UI に反映できる（withObservationTracking ブロック or SwiftUI 組み込みの監視）
  • SwiftUI と RealityKit の双方向連携
    • 従来：SwiftUI → update クロージャ → RealityKit
    • 逆方向も可能：RealityKit → Observable → SwiftUI
    • update クロージャの無限ループ回避策や、状態管理のベストプラクティス：
      • update クロージャで 監視対象のステートを更新しないこと
      • 更新する必要がある場合は、同値チェックを挟むこと
      • システムの更新関数（SwiftUIビュー本体評価外）から更新すること：e.g. gesture クロージャ
      • などなど
      • そもそも update クロージャを使わなければ避けられる

24:56 – Unified coordinate conversion

  • 新しい CoordinateSpace3D プロトコルで SwiftUI, RealityKit 間の座標変換が容易に（抽象座標空間）
  • GeometryProxy3D, Entity, Scene などが CoordinateSpace3D に準拠し、異なる空間間での距離計算や位置変換が可能
  • これにより 3D UI と 3D オブジェクトの連携がより直感的に

27:01 – Animation

  • SwiftUI のアニメーション API で RealityKit のコンポーネント（Transform, Audio, Model, Light など）を暗黙的にアニメーション可能
  • realityViewContent.animate() や Entity.animate() で状態変化に応じたアニメーションを実装
  • Object Manipulation API と組み合わせてカスタムリリース挙動やバウンス効果も実現
    • 例：manipulation.releaseBehavior = .stay で無効化し、ManipulationEvents のイベント捕捉でアニメーションを自前実装

WWDC25：Bring advanced speech-to-text to your app with SpeechAnalyzer

speech-to-text に関するセッション。段階的に音声を追いながら精度を高めているというところが興味深かった。タイムコードをもとに、音声再生とテキストとを表示の上で対応づけられる点も面白い。

0:00 – Introduction

  • 新しい speech-to-text API SpeechAnalyzer を紹介
  • SpeechAnalyzer は Notes, Voice Memos, Journal など多くのシステムアプリで採用
  • Apple Intelligence と組み合わせることで通話要約などの強力な機能を実現
  • iOS 10 でで導入された SFSpeechRecognizer：音声テキスト変換モデルを提供
  • 短い音声入力で高い精度、Apple のサーバー活用
  • 一部ユースケースで期待に満たなかった
  • このセッションでは API の概要、新モデルの機能、実装デモを解説
  • iOS 26 で導入された SpeechAnalyzer
  • 高速かつ柔軟な新しい speech-to-text モデルを採用し
  • 長文や遠距離の音声（会議、会話など）に強い

2:41 – SpeechAnalyzer API

  • SpeechAnalyzer は分析セッションを管理し、SpeechTranscriber などの用途に応じたモジュールを追加して使用
  • 音声バッファは非同期で処理され、入力と結果は AsyncSequence で処理を分離
  • タイムコードを使って音声と結果を正確に関連付け
  • すべての API 操作はタイムコードでスケジュールされ、処理順序が予測可能に
  • モジュールの処理範囲が順番かつ重複せず、オーディオ全体を網羅
  • オプションで 暫定結果を有効にし、段階的な結果表示が可能
    • 発話と同時のリアルタイムで推測結果をおおまかに表示（Volatile results）
    • 音声とコンテクストを追加してあとから精度を上げて更新する（Finalized results）

7:03 – SpeechTranscriber model

  • SpeechTranscriber は Apple が設計した新しいオンデバイスモデルを採用
  • マイクから遠い話者がいる会議など、長文や会話のユースケースをサポート
  • 低遅延、高精度、高い可読性を実現し、ユーザーのプライバシーを保護
  • AssetInventory API を介して必要なモデルアセットをオンデマンドでインストール
  • モデルはシステムストレージに保持され、アプリのダウンロードサイズやメモリ使用量を圧迫しない
  • アップデートは自動的にインストール
  • 多くの言語に対応し、watchOS を除く全プラットフォームで利用可能
  • 未対応の言語やデバイス向けに、従来の SFSpeechRecognizer と同等の機能を持つ DictationTranscriber も提供

9:06 – Build a speech-to-text feature

  • SpeechAnalyzer を使ってライブ文字起こし機能を実装するデモを紹介
  • 音声を再生すると再生中に対応するテキストセグメントが自動でハイライト
  • 3つのステップで実装：SpeechTranscriber の設定、モデルの存在確認、結果のハンドリング
  • SpeechTranscriber を初期化し、volatile results や finalized results などのオプションを設定
  • AssetInventory を使って、文字起こしに必要な言語モデルがダウンロードされているか確認し、なければリクエスト
  • AsyncStream を介して返される結果オブジェクトには、AttributedString 形式のテキストと、isFinal プロパティが含まれる
  • volatileTranscript と finalizedTranscript を個別に管理し、UIに反映
  • audioTimeRange 属性（CMTimeRange）を使って、音声再生とテキストのハイライトを同期
  • AVAudioEngine を使って音声入力ストリームを処理し、SpeechTranscriber に渡す
  • 録音停止時は、finalize を呼び出して volatile results を確定させることが重要
  • FoundationModels API と連携して、文字起こし結果からタイトルを生成するような応用も可能