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 で制御(再生・停止・シーク)が可能
        • AnimationPlaybackControllerObservable に(例:time の変更監視)
    • ConfigurationCatalog からの読み込み
      • ConfigurationCatalogModel3D を初期化し、複数の外観やボディタイプを切り替えられる(@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 エンティティに統合するための3つのコンポーネント
    • ViewAttachmentComponent:SwiftUIビューをエンティティに直接追加
    • GestureComponent:エンティティに通常の SwiftUI ジェスチャをアタッチ、ジェスチャー値はエンティティの座標空間で報告
      • ジェスチャー対象のエンティティに、InputTargetComponent, CollisionComponent 両方を追加
    • PresentationComponent:RealityKit シーン内から SwiftUI ビューを popover のように表示

19:08 – Information flow

  • visionOS 26 で EntityObservable になり、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 プロパティが含まれる
  • volatileTranscriptfinalizedTranscript を個別に管理し、UIに反映
  • audioTimeRange 属性(CMTimeRange)を使って、音声再生とテキストのハイライトを同期
  • AVAudioEngine を使って音声入力ストリームを処理し、SpeechTranscriber に渡す
  • 録音停止時は、finalize を呼び出して volatile results を確定させることが重要
  • FoundationModels API と連携して、文字起こし結果からタイトルを生成するような応用も可能

WWDC25:Dive deeper into Writing Tools

作文ツールについて。カスタムテキストエンジンでも適用できるらしい。あの独特な編集アニメーションの仕組みに言及されていたのが個人的なハイライト。実装する機会はないと思うけど、、


0:00 – Introduction

  • Writing Tools はテキストのリライト 校正 要約などをテキストビュー内で実現する機能
  • 今年は ChatGPT 連携によるコンテンツ生成や画像生成も可能に
  • visionOS でも利用可能になり iOS, iPadOS, macOS 26 ではリライト後のフォローアップリクエスト(文体や調子の調整)も対応
  • Writing Tools の各機能は Shortcuts からも自動化可能(校正、書き直し、要約など)
  • アプリでサポートするための新しい API でツールバーやメニュー項目

2:21 – Customize native text views

  • システム標準のテキストビューは Writing Tools を自動サポート
  • ライフサイクルメソッドで同期停止や挙動カスタマイズが可能
  • 書き換え禁止範囲やリッチテキスト/リスト/テーブル対応も result options で制御
  • テキストヘビーなアプリはツールバーやメニューに Writing Tools ボタン追加推奨
    • UIBarButtonItem / NSToolbarItem
  • コンテクストメニューには作文ツール項目が自動挿入
    • カスタムメニュー実装時は
      • automaticallyInsertsWritingToolsItems を false
      • WritingToolsItems API で標準項目を取得

4:00 – Rich text formatting

  • テキストビューの種類に応じて .plainText, .richText, .presentationIntent など WritingToolsResultOptions を指定
    • 例: 検索フィールドではリッチテキストをサポートしない
  • RichText では display attributes: 表示属性(太字 斜体等)や presentation intent(見出し/リスト/テーブル等)を使い分け
  • Notes などセマンティックスタイル対応アプリは presentation intent でネイティブな見出しやリストを活用
  • 表示属性 と presentation intent は併用される場合もあり アプリ側で適切に変換が必要
    • TextEdit の場合具体的なフォント情報を含むが、セマンティック情報を含んでいない
    • Memos はセマンティックスタイルをフル活用する → 内部で独自の表示属性に変換する必要がある
    • 表示属性は下線や上下付き文字に使用
  • requestContexts メソッドで文脈情報や presentation intent を提供するとセマンティクスの理解精度が向上

7:41 – Custom text engines

  • カスタムテキストエンジンでも共通プロトコル対応で Writing Tools の基本機能が利用可能
  • さらに WritingToolsCoordinator API でリライトや校正のアニメーションやインライン反映も実現
    • coordinator をビューにアタッチし delegate 実装で文脈取得、変更反映、プレビュー生成、校正マーク描画などを制御
    • delegate メソッドは非同期(@escaping callback)で挙動、大規模テキストにも対応
  • 処理中のテキストアニメーション表示のために、coordinator はテキストのプレビュー画像をリクエスト(透明背景のテキストレンダリング)
    • テキストでなくこの画像にエフェクトを適用する
  • 状態変化時の undo や同期停止、外部変更の通知も coordinator で一元管理

Liquid Glass(物理)を購入した

先日の Recap イベントで、temoki さんによって紹介され界隈をどよめかせた、Liquid Glass もどきのガラスペーパーウェイトをようやく手にすることができた。

Amazon にて購入。実は、このペーパーウェイトが紹介されたLTの間に楽天で注文したのだが、欠品連絡があり、しばらく後に再注文したのだった。

誌面の上にペーパーウェイトを乗せてみた

この写真のとおり、垂直に見下ろすと確かにレンズ効果で湾曲して見えるけれど、それだけだとイマイチ Liquid Glass 感がない。一体何が足りないのかと、ズラしてみたり、敷くもの(コンテンツレイヤー)を文字から写真に替えてみたり、試行錯誤の末ふと仰角を浅く覗いてみたところ、黒い印字が虹のようにスペクトラムに分解されて映ることを発見。これこそが Liquid Glass らしさだと気がついた。

ガラスの境界線付近で、黒文字が虹色に分解されている

このドーム状のペーパーウェイトのように、ガラスが設置面(コンテンツレイヤー)に対し垂直に切立つのでは、こうした視覚効果は生まれない。撥水面に垂らした液体のように断面が湾曲することで、色の分解が生み出されるのではないか、、実物(?)を観察したからこそ得られた発見だった。実際、Liquid Glass のイントロダクションビデオでデザインチームが扱っているガラスオブジェクトも、よく見るとそうした形状をしている。


余談だが、ペーパーウェイトの下敷き(コンテンツレイヤー)になっている雑誌は、Wallpaper 誌が Apple Design team を特集した2022年1月号。WWDC25 の基調講演で Liquid Glass を世に紹介した Alan Dye 氏も、もちろん文章と写真の両方で登場する。

Inside Apple Park: the design team shaping future tech | Wallpaper

聴講メモ:try! Swift Tokyo WWDC Recap 2025

今月何度目かわからなくなってきた、Apple Japan での Recap イベントに参加してきた。今回は、筆者も当日スタッフとして参加した try! Swift Tokyo 主催のもの。登壇は visionOS と Foundation Models のふたつとも筆者的関心の高いテーマでありがたかった。特に Foundation Models adapter training は未遂に終わっていたので、実際に触った所感を聞けたのが良かった。

タイムテーブルは筆者が確認していた限り直前まで公開されておらず、個人的に最もサプライズだったのは、 Swift Student Challenge に日本から入賞された学生さんがスピーカーとして登壇されたこと。Apple の Newsroom で取り上げられていたのを拝見していたので、すぐに分かった。入賞とひと言で言っても、世界 TOP50 に選出され WWDC に招待された上に、さらに11名だけが得られる Tim Cook へのピッチ機会も設けられた、とのこと。しかし彼のプレゼンを聞いていて、堂々とした語りと、なにより入賞した花札アプリのコンセプトが素晴らしく、これが世界レベルかと感動。ちなみに花札アプリは実際に触らせていただくこともできた。花札という古典ゲームにオリジナルの概念を盛り込んでいて、サウンドにも見た目にも細かな工夫が凝らしてあり、誰でも楽しみながら花札を覚えられるつくりとなっていた。

イベントページ:https://lu.ma/kd101ho8


visionOS 26 のアップデート内容と所感

satoshi さん

  • What’s new
    • Widget
    • instancing: メモリ効率がかなり上がった
  • 他セッション
  • 実機デモ
    • Enterprise APIでの両眼映像の取得
      • シェーダーを通したリアルタイム画像加工ができる(高速処理のためMetal使った)

Unleashing Foundation Models

shu223 さん

  • Tool calling
    • 制約:modalilty – multi-modal ではない
      • テキストのin/outのみ
      • 音声や画像の入出力はない → tool calling でやった
    • Tool calling の処理実装はなんでも実装可能
      • Speech + Image Playground
      • ツールとして渡しているだけなので、使わないという選択をモデルがすることもできる
        • → 画像生成を依頼しなければ使われない
  • Custom adapters
    • モバイルで動く小さめなモデル(Llama, Gemma の同程度のサイズのモデル)と比べてもやや劣る
    • Custom adapter で大幅に性能が向上した:すべてのベンチマークで、はるかに大きなモデルよりも優れた性能を発揮
      • GPT-4.1 や 4o を含む大規模モデルすらも超えるケースも
    • アダプター
      • 特定ケースにチューニングされた追加アダプター
        • e.g. .contentTagging
        • たくさんある?とおもっったら、general / contentTagging しかない
        • ほとんどのユースケースが、general に内包されている
          • tag, entity topic は tagging
    • 概要
      • LoRAを使用
      • ベースモデルの重みは固定し、アダプターの重みのみ更新
      • 必要なデータ量の目安
        • 単純タスク:100-1000 サンプル
        • 複雑タスク:5000サンプル以上
    • ツールキット
      • 必要なサンプルデータやコードが揃っている
      • .fmadapter ファイルがカスタムアダプターの実態
        • Xcode でプレビュー可能
    • Entitlement
      • アダプターのデプロイは、サイズがでかいのでバンドルするのではない、background assets フレームワークを使う
        • テストはアプリに組み込んでOK
    • サンプル(演劇)を使った学習結果のデモ
      • エポック(学習サイクル)を重ねるごとに、タグ構造を学習しフォーマットに沿った台本生成が可能になる(らしい)
      • 学習時間はMBPで10分程度:OSバージョンアップごとの再学習も現実的かも
  • Q&A
    • 回答のばらつきは temperature で指定可能
    • 基本メジャーバージョンごとにモデルが変わる sticky patch で上がることはない
      • 追従できなくてもアダプター自体は通るが、精度が落ちる

WWDC25:Automate your development process with the App Store Connect API

CI/CDにとどまらず、リリース情報、フィードバックの変更をトリガーにした自動化を加速できる。


0:00 – Introduction

  • App Store Connect は開発プロセス自動化のための多くの API を提供
  • 今年は app management や TestFlight など主要分野で API が大幅拡張
  • Webhooks API や Apple-Hosted Background Assets API など新機能も追加
  • Webhook 通知 Build upload API Feedback API などが開発サイクル高速化に寄与

1:56 – Webhook notifications

  • Webhook 通知によってイベント駆動型のワークフローを組むことができる
    • Webhook はサーバー間のプッシュ通信で イベント発生時に App Store Connect から HTTP コールバックを受け取る仕組み
    • Webhook listener の URL を App Store Connect に登録し イベント発生時に POST リクエストを受信
    • 通知 payload にはイベント情報が含まれ 必要に応じて追加 API コールも可能
  • Webhook 通知は Build upload state イベント, Feedback イベント, Build beta state イベントなど多様なイベントに対応
  • Webhook 設定は UI でも API でも可能 シークレットキーで署名検証もサポート
    • Integretions > Workfows の設定方法説明

6:50 – Build upload API

  • Build upload API でビルドのアップロード自動化が可能に
  • 任意の言語やプラットフォームから利用でき 柔軟な自動化が実現
  • BuildUploads を作成し build 情報を登録 → BuildUploadFiles でファイル詳細を通知 → 指示に従いバイナリをアップロード
  • アップロード完了後 PATCH リクエストで完了通知し App Store Connect がビルド処理を開始
  • Webhook 通知で処理完了を即時把握可能、署名検証で信頼性も確保

11:18 – Beta testing builds

  • TestFlight API でビルドのベータ配信も自動化可能
  • ビルドをテスターグループに割り当て、外部テスターには Beta App Review 提出も API で対応
  • Build Beta State Webhook event でベータ審査完了を即時通知
  • 通知 payload でビルド ID や状態を確認し次のステップへ進める

12:51 – Feedback API

  • TestFlight のフィードバック(スクリーンショットやクラッシュ)も API で取得可能
  • Webhook で新規フィードバック到着を即時検知しフィードバックの ID で詳細取得
  • Feedback API でデバイス情報やスクリーンショット URL などを取得 クラッシュログも API でダウンロード可能

15:05 – Additional development APIs

  • Apple-Hosted Background Asset 管理用 API も新登場
  • app version state webhook event で App Store 上の状態変化も通知
  • 既存の多様な API も活用し 開発からテスト リリースまで自動化可能

WWDC25:Customize your app for Assistive Access

先日の Recap イベントにて、LTのひとつで取り上げられていた Assistive Access。発表者の方とお話しし、超高齢化社会を迎えるこれからの日本でこそ有用な機能であると伺いなるほどと思った。Dynamic Type を使って文字を拡大して使われている方は多いが、一定大きくなると表示との整合性を取ることが難しくなる。一定以上の文字サイズ設定のレイアウトを Assistive Access と分離すると良いかもしれない。


0:00 – Welcome

  • Assistive Access は Apple が iOS と iPadOS で提供する 認知障害のある人向けのシンプルな体験
  • アプリやコントロールを本質に絞り込み 誰でも簡単かつ自立してデバイスを操作できるように設計されている
  • iOS と iPadOS 26 では Assistive Access scene type を使ってアプリをこの体験に統合できる

0:59 – Meet Assistive Access

  • Assistive Access は iOS と iPadOS 17 で導入された
  • 認知負荷を減らすために シンプルなインターフェースと一貫したデザインを提供
  • Camera や Messages などのビルトインアプリは 大きなコントロールや視覚的な要素を重視した共通スタイルを持つ
  • 最適化されていないアプリは 画面下部に常に表示される戻るボタンのために縮小フレームで表示される
  • 認知障害向けに設計されたアプリは UISupportsFullScreenInAssistiveAccess キーを Info.plist で true に設定することでフルスクリーン表示が可能
  • SwiftUI や UIKit で Assistive Access セッションの検出も可能
  • フルスクリーン対応アプリは Accessibility 設定の Optimized Apps リストに表示される
  • 一般的なアプリは iOS と iPadOS 26 で Assistive Access scene を作成し 専用の UI 体験を提供できる

4:09 – Create a scene

  • UISupportsAssistiveAccess キーを Info.plist に true で追加し Optimized Apps に表示されるようにする
  • Assistive Access scene を追加し シンプルな UI 階層を設計
  • Assistive Access で起動時 この scene がアタッチされる
  • SwiftUI コントロールは自動的に大きく明確なスタイルで表示され grid や row レイアウトも自動適用
  • SwiftUI preview macro で Assistive Access trait を渡してレイアウトをテスト可能
  • UIKit アプリでも SwiftUI scene を定義し scene delegate でアクティブ化できる

7:08 – Tailor your app

  • アプリの体験を本質に絞り込み 理解しやすくサポート的な UI を設計することが重要
  • 主要な1〜2機能に絞り 他の機能は Assistive Access 外で提供する
  • 画面上の選択肢や要素を減らし 誤操作や混乱を防ぐ
  • 隠れたジェスチャやネストした UI は避け 明確で目立つコントロールを使う
  • タイムアウトによる UI の自動消失や状態変化は避ける
  • ステップバイステップのガイドフローを設計し 一度に多くの選択肢を提示しない
  • 取り消しや削除など回復困難な操作は極力排除し 必要な場合は二重確認を行う
  • テキストだけでなく アイコンや画像など視覚的な情報も併用する
  • SwiftUI の assistive access navigation icon modifiers でナビゲーションタイトルにアイコンを追加
  • ユーザーからのフィードバックを重視し Assistive Access コミュニティでテストを行う

Foundation Models adapter training toolkit を試してみたが

結論から言えば、実行環境がツールキットの必要条件を満たしておらず失敗した。

Foundation Models adapter training – Apple Intelligence – Apple Developer

このページに説明がある通り、adapter training toolkit が必要とするマシンスペックはメモリ32GB。対して筆者私用の MacBook Air (M2) は16GBしか積んでいない、、

Requirements

  • Mac with Apple silicon and at least 32GB memory, or Linux GPU machines
  • Python 3.11 or later

ツールキットのセットアップ自体は、ページの手順に従って難なく完了したのだが、テストコマンド実行で失敗した。

adapter_training_toolkit % python -m examples.generate --prompt "Prompt here"
Traceback (most recent call last):

(省略)

RuntimeError: MPS backend out of memory (MPS allocated: 18.13 GB, other allocations: 384.00 KB, max allowed: 18.13 GB). Tried to allocate 16.00 MB on private pool. Use PYTORCH_MPS_HIGH_WATERMARK_RATIO=0.0 to disable upper limit for memory allocations (may cause system failure).

ChatGPT 先生によると、

メモリ 32 GB 推奨という前提に対して物理メモリ 16 GB の Mac で動かしている ことが、今回の MPS out-of-memory エラーの根本原因と考えてかまいません。

要素おおよそのメモリ消費
7 B パラメータ級モデル (FP16)7 B × 2 bytes ≒ 14 GB
ロード直後の重複バッファ(重み再配置や勾配用の一時領域)+2 〜 4 GB
トークン埋め込み/ KV キャッシュ(推論時)数百 MB 〜 数 GB (入力長/バッチで変動)
Python / PyTorch 自身・OS・他プロセス2 〜 4 GB

16 GB machines の場合、Unified Memory 全体が 16 GB = GPU が占有できる上限も 16 GB 未満 です。

PyTorch-MPS の既定 “high-watermark” が 90 % なので、確保できるのは最大でも ≈ 14.4 GB 程度。

上の表の時点でオーバーしており、転送途中でエラーになります。


Mac Studio 買うか、、

WWDC25:Wake up to the AlarmKit API

地味に反響の大きな AlarmKit について。筆者は10年以上前にポモドーロタイマーアプリをリリースしたことがあったが、ローカル通知頼りにならざるを得ず、体験的にイマイチだったし、通知が溜まりまくってカオスになってしまっていた。AlarmKit があれば、ポモドーロ以外にも細かなシーンを補えるので嬉しそう。(例えば筋トレアプリだとインターバルの残り時間とか)


0:00 – ようこそ

  • AlarmKit はアプリでアラームを作成できるフレームワーク
  • スケジュール型とカウントダウン型の2方式目立つアラートを提供
  • サイレントモードやフォーカスを突破してアラートを表示
  • カスタムアラームタイトルとアプリ名を表示し、停止やスヌーズ機能を提供
  • StandBy や Apple Watch でもサポート
  • Live Activities を使ったカスタムカウントダウンインターフェースも可能

0:32 – 概要

  • アラーム機能はユーザーが各アプリごとにオプトインで有効化
  • 許可は手動で要求するか、最初のアラーム作成時に自動要求
    • 設定アプリでいつでも許可状態を変更可能
    • NSAlarmKitUsageDescriptioninfo.plist に追加して使用目的を説明
    • AlarmManager.requestAuthorization() で手動許可要求
  • authorizationState で許可状態を確認してからアラームをスケジュール
    • 拒否時の制限明示も重要

1:39 – 作成

  • アラーム作成に必要な要素:
    • カウントダウン時間(pre-alert/post-alert duration)
    • スケジュール(固定日時または相対パターン)
    • 外観設定
    • カスタムアクション処理
    • 関連サウンド
  • スケジュールの指定:
    • 固定スケジュール:特定の未来日時を指定(タイムゾーン変更に影響されない)
    • 相対スケジュール:時刻と週次繰り返しパターンを指定(タイムゾーン変更に対応)
  • アラーム外観のカスタマイズ:
    • AlarmButton でボタンのテキスト、色、アイコンを設定
      • アイコン(SF Symbols)は Dynamic Island 表示に使用
    • AlarmPresentation でアラートタイトルを設定
    • AlarmAttributes でアラーム属性を設定
      • 表示のレンダリングに必要な情報
      • tintColor の設定:アラームとアプリの関連性を伝えるのに役立つ
    • AlarmConfiguration に、duration と attributes を含める
  • カウントダウン表示の設定:
    • 繰り返しボタンを AlarmPresentationsecondaryButton / scondaryButtonBehavior に指定 (.countdown)
    • Live Activities を使ったカウントダウン UI
      • Live Activity を Widget Extension に追加
    • 追加情報の表示設定:
      • AlarmMetadataAlarmAttributesmetadata に指定
      • Live Activity 側で context.attributes.metadata を抽出して表示に活用
    • カウントダウンインターフェイスの表示はシステムが保証:システム表示のカスタマイズ(一時停止/再開ボタン等)
  • カスタムアクション:
    • App Intent を使ったカスタムボタンアクション
    • アプリを開く、詳細表示等の処理
    • アラームに一意の識別子を定義して追跡できるようにする
  • サウンド設定:
    • デフォルトシステムサウンドまたはカスタムサウンド
    • ActivityKit の AlertSound 構造体を使用
      • サウンドファイルはメインバンドルか、Library/Sounds に格納

16:32 – ライフサイクル

  • AlarmManager クラスでアラームのライフサイクルを管理
  • 一意の識別子を使ってアラームを追跡
  • カウントダウン状態への移行、キャンセル、停止、一時停止、再開が可能
  • ベストプラクティス:
    • 特定間隔のカウントダウン(料理タイマー)や繰り返しアラート(目覚まし)に適している
    • 重要な通知や時間敏感な通知の代替ではない
    • アラート表示は明確で理解しやすく(何のアラームか、どのようなアクションが可能か)
    • Live Activities には残り時間、停止ボタン、一時停止/再開ボタンを含める

WWDC25:Meet PaperKit

新登場の PaperKit。がっつり UIKit ベースの実装で懐かしさを感じた。Apple Pencil 結局使いこなせていない、、空間アクセサリとして対応する日が来たら、また変わるのかもしれない。


0:00 – イントロダクション

  • PaperKit は Apple のシステム全体で使われているマークアップ体験を支えるフレームワーク
  • Notes やスクリーンショット、QuickLook、Journal アプリなどで利用
  • キャンバス上で描画や多様なマークアップ要素(図形、画像、テキストボックス等)を追加できる
  • macOS Tahoe でも同様のリッチなマークアップ体験を提供

1:36 – PaperKitの基本知識

  1. PaperKit の主な3コンポーネント
    1. PaperMarkupViewController:インタラクティブなマークアップ・描画の提供
    2. PaperMarkup:データモデルコンテナ・PaperKit マークアップ、PincilKit 描画データの保存・読み込み、レンダリング
    3. MarkupEditViewController or MarkupToolbarViewController(macOS):挿入メニュー

3:35 – PaperKitの導入

  • iOSアプリへの導入例:
    • UIViewControllerviewDidLoad() 内で PaperMarkupPaperMarkupViewController を初期化
      • PaperMarkup は初期化時に bounds を指定
    • PencilKit のツールピッカー(PKToolPicker)と連携し、ツールの表示や操作を制御
      • paperViewController と紐づけツールピッカーの状態変化に動的に応答
    • UIResponder.pencilKitResponderState.activeToolPicker / .toolPickerVisibility
    • アクセサリボタンから挿入メニューを呼び出し、マークアップ要素を追加
      • MarkupEditViewController
  • macOS アプリでも同様の手順で導入可能。ツールバーUIで挿入メニューを提供
  • SwiftUI 環境でも UI/NSViewControllerRepresentable で統合可能
  • デリゲートや Observable 対応で状態管理や自動保存も柔軟
  • ディスク読み込みのデータに対し、前方互換性のためコンテンツバージョンの検証が必要
    • 不一致時はアラートでアップグレードを訴求/あらかじめレンダリングされたサムネイル表示
    • PaperKit の前方互換性担保の仕組み:CGContextmarkupModel.draw(…)

8:37 – 機能セットのカスタマイズ

  • PaperKit の全機能は FeatureSet で管理
  • FeatureSet.latest で最新機能を一括利用可能
  • remove/insert で利用可能なツールやインクを細かく制御
  • HDR対応も可能(colorMaximumLinearExposure プロパティで設定)
  • カスタマイズした FeatureSet を各コントローラに適用し、アプリ全体で一貫した体験を実現
  • paperViewController.contentView のカスタマイズで独自テンプレートや背景も設定可能(カスタムビューを指定することで、マークアップの下のレイヤーとしてレンダリングされる)