投稿者: p0dee

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 で紹介

OS 26 beta 5 の Foundation Models framework アップデート内容

Foundation Models の開発者からこんな投稿があったのでチェック。

  • ガードレイルに permissiveContentTransformations オプションが追加
    • 要約やスタイル調整といったユースケースにおいて原文にセンシティブなトピックを含む可能性があるケースを想定（政治記事など）
    • 含んでいてもテキスト応答にへ関することを許容し、LanguageModelSession.GenerationError.guardrailViolation エラーを投げないガードレイル設定
    • permissiveContentTransformations | Apple Developer Documentation
  • 新しい「拒否」エラーの追加
  • #Praiground 使用時にフィードバックボタンを追加
    • Xcode 上で直接、モデル動作に関するフィードバックを送信可能に
  • GeneratedContent を透明化（“no longer opaque”）
    • GeneratedContent.Kind が追加され、任意の生成コンテンツを表示するビューの構築が可能
    • プリミティブ型、配列、構造化オブジェクトを含む、JSON互換のデータ種類を表す
      • .array([GeneratedContent]), .bool(Bool), .number(Double), .string(String), .structure(properties: [String.: GeneratedContent], orderedKeys: [String]), .null
    • ユーザーが設定可能な生成スキーマの取り扱いに有用
  • 推論スタックの最適化が含まれており、トークンの処理速度が向上

聴講メモ：SPARKS #1 – AR/AI Glass Hands on!

MESONさん主催の新企画・XR/空間コンピューティング系ミートアップの第1弾が開催されたので参加してきた。

イベントページ：https://meson.connpass.com/event/362171/

今回特に期待していたのは、トークセッションやクリエイターLTも然ることながら、さまざまなARグラスが集結し、体験できるというハンズオンが設けられているということだった。特にここ最近はAR系の新製品が目まぐるしい勢いで登場し、それぞれが高額なのもあってまったくキャッチアップできていなかったので、大変ありがたかった。

共催４社の代表４名によるトークセッションは、AI時代におけるARデバイスのありかた、HMDとグラス型との対比に関するトピックが主軸。（以下、４名の登壇者の発言が混在しているので、どんなトピックが話されたかの参考程度）

最近注目しているグラスデバイス

  • Even G1
    • １日中着用可能、Apple Watch をつけなくなった、食事中スマホ見なくなった
    • デフォの時計：商談中コミュニケーションが分断しない
    • 通知、時計機能メインで利用
      • マイク x AI の機能はあるが、使ってない
      • デフォルトは精度高くない、3rd Party がアプリ開発可能
    • Even G1 のような AR グラスは、カメラ相性が良さそう
      • 視界のコンテクストを共有できることが重要、言葉で説明せず指示語が使える
  • XREAL One Pro
    • ディスプレイ使用。視野角狭いことでかえって目の前の作業に集中できる
    • 映像で使うシーンがライフスタイルにない
      • これから出てきそう？
  • カメラの要不要はデバイス将来を決定づける分岐点
    • マイクスピーカーだけで良いか、映像含めたマルチモーダルか、まだ未知数
    • AIの精度を上げるためには、コンテクストとしての映像、カメラが必要
    • 気づかないものにAIが先に気づいてヒントを与えてくれる世界（ゼルダの妖精）
    • AIのパーソナル化、パーソナルアシスタントとしての機能性
      • データ量が重要、ユーザーどこでなにをしたか、AIグラス経由でスキャンできることで収集

HMD vs Glasses

  • HMD は「やるぞ」のモードが必要 → グラスは日常でカジュアルに利用可能
    • HMD：企業向け、家、仕事使い
    • グラス：日常使い
  • コンテンツの作りやすさでは HMD ＞ グラス
  • 来年は AR グラスがますます浸透する
  • HMD とグラスとで、ユースケースが収斂し始めている
    • 技術登場当初から社会に受け入れられるまでに形態は変化する
    • 例）電話：ラジオ的な 1toN から、1to1 の受話器型へ
    • スクリーンレス、AIとの融合、へ収斂するのでは
  • 現状 AVP はディスプレイの代替になっていっている
    • 目や手の操作の快適性は企業に刺さってない
    • それよりもディスプレイの高精細さ

ビッグテックのグラス戦略

  • 「ディスプレイいらない」となりそう
  • リアルタイム性とファッション性、マルチモーダル（マイクスピーカーカメラ）の形態が普及しそう
    • その後、AR Glass「Pro」で、ディスプレイ付きが普及する？
  • 普及のしやすさで言えば、カメラなし、ディスプレイあり
  • ハードウェア側のエコシステムが整うことで、クリエイターが未来創造の速度が加速する
  • コンシューマー側は 3D を扱うための学びのハードルが高い
    • 普及するまでの時間は予想よりも長引く（グラス型の普及期が長く続く）かも
トークセッションの様子
“聴講メモ：SPARKS #1 – AR/AI Glass Hands on!” の続きを読む

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）
    • 一貫性により、アプリを使用する人々に明確さを提供

Foundation Models の RAG に Core Spotlight を活用できそうか超簡単な実験

WWDC24：Support semantic search with Core Spotlight で記したように、日記データを処理するオンデバイス LLM の実験のために Foundation Models の活用を検討しており、エントリ検索のための RAG として Core Spotlight が使えないか考えている。

ユーザー質問を受けた Foundation Models 側で、適切なクエリを生成できることが分かれば何かは作りだせそう。しかし以前の反省のとおりいきなりモデルの実装をし始めるのは悪手。まずは Foundation Models に対し自然言語でやりとりをし、狙う用途を満たす知識や能力があるかを先に検証するべき。

ということで、次のプロンプトを投げてみた。

あなたはCore Spotlightにインデックスされた日記データをもとにユーザーからの質問に答える役をします。Core Spotlightから情報を引き出すためには、ユーザーの質問を解釈し、Core Spotlightに投げるクエリを考える必要があります。ユーザーから「最後に散髪したのはいつ？」と尋ねられたら、どんなクエリを投げますか？

返ってきた答えは以下。

「最後に散髪したのはいつ？」という質問に対して、Core Spotlightに投げるクエリを考えるには、以下のようなアプローチが考えられます。このクエリは、ユーザーの行動履歴や、関連するキーワードを考慮して作成されます。

```plaintext
Core Spotlight Query:

- Type: Query
- Language: Natural Language
- Query: 最後に散髪したのはいつ？

- Context:
  - Keywords: 散髪、カット、美容室、ヘアスタイル、ヘアサロン
  - Date Range: 最近までの履歴を考慮

- Filters:
  - Category: Personal Care
  - Action: Haircut
  - Location: Salon/Barber Shop
  - Date: Last occurrence

- Constraints:
  - Language: Japanese
  - Language Preference: Japanese

```

このクエリは、ユーザーの行動履歴を基に「散髪」に関連するキーワードを特定し、最近までの履歴を考慮して「最後に散髪したのはいつ？」という質問に応答します。また、日付範囲を最近のものに限定し、具体的な場所やアクションを強調することで、より正確な情報 retrieval を促進します。

Context / Filters / Constraints をクエリ設計に含めているあたり、同じ Apple の技術である Core Spotlight のコンセプトを理解できているのかは怪しいが、少なくとも質問内容から的確にキーワード抽出ができそうなことは分かった。（まあここはさすがにLLMの得意分野だろう、、）

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 など）を使用して動的な色の変化に対応（外観でなく目的にちなんで命名）
      • コントラスト設定、画面環境、ダーク／ライトモード…

WWDC24：Support semantic search with Core Spotlight

日記データとローカルLLMを組み合わせて何かできないか考えているが、Foundation Models の adapter training は日々更新される情報の追加学習には向いていない（し、そもそもユーザー生成データを学習させることもできない）。文書データと相性が良さそうな RAG を iOS でうまいこと活用できないか ChatGPT に壁打ちしていたら、Core Spotlight によるセマンティック検索が有効と教えてくれたので、去年の WWDC セッションビデオを見てみた。

完全一致でなくともある程度文脈を汲み取ったコンテンツ検索ができるようで、さすが Spotlight 技術なのでバッチ更新も可能だし、Core Spotlight でアプリ内から検索処理が行えるのなら、Foundation Models に tool calling 経由で自律的に検索させることができるだろうか？

0:00 – Introduction

  • CoreSpotlight フレームワークでアプリ内に強力な検索体験を構築する新しい API を紹介
  • セマンティック検索により、意味的に類似した検索語でも適切な結果を取得可能
  • 完全にローカルでプライベートな検索インデックスを提供
  • ジャーナルのエントリ検索アプリを例に、検索体験の構築方法を説明

1:37 – Searchable content

  • 検索可能なコンテンツを設計 → 検索インデックスを構築 → Spotlight に提供
  • CSSearchableItem に uniqueIdentifier, domainIdentifier, attributeSet を設定
  • CSSearchableAttributeSet で contentType, title, textContent, contentURL を設定し、セマンティック検索に最適化
    • アイテムが画像、動画アセットの場合は、アセットへのパスを contentURL に指定
    • 添付ファイルやWebコンテンツへの参照は、独自のコンテンツタイプと属性をインデクスに提供
    • ソースアイテムとの関係に relateUniqueIdentifier を指定
  • バッチインデックス作成と client state で効率的な Spotlight への提供を実現
  • item.isUpdate を使い、すでにインデックス済みの属性上書きを防ぎ、必要なものに限り提供可能

4:10 – Migration and Recovery

  • 移行と復元：一貫性を維持するために重要
  • なんらかの問題で移行と復元を要する場合、Spotlight がアプリに際インデックス化を要求
  • CoreSpotlight Delegate extension で Spotlight からの再インデックス要求に対応
    • Spotlight はアプリとは別にこの Extension を呼び出すことができる（デバイスがアイドル状態の時にバックグラウンドで再インデックスを実行）
  • mdutil ツールでデバッグとテストが可能

6:56 – Results and suggestions

  • CSUserQueryContext でクエリを設定し、セマンティック検索を有効化
  • ランク付けされた結果とサジェスションを取得、最大結果数も指定可能
  • メタデータ構文でフィルタクエリを構築し、結果をカスタマイズ
    • 検索結果をUIにに合わせる最適な手法（e.g. 画像のみ表示時は画像のみとするようクエリ指定）
  • 検索バーからのクエリ文字列とクエリコンテクストから CSUserQuery を生成
  • 非同期バッチで結果を取得し、compareByRank でソート
    • 候補（CSSuggestion）は入力文字列の補完として返却
  • セマンティック検索はプロセスに必要な学習モデルのダウンロードが必要
    • ロード・アンロードでメモリ容量を節約（CSUserQuery.prepare, .prepareWithProtectionClasses を検索UI表示時に実行）

9:18 – Ranking

  • エンゲージメントと鮮度のシグナルでランキングを改善
  • lastUsedDate プロパティでコンテンツの使用頻度を記録
  • ユーザーの検索行動（閲覧、スクロール、詳細表示）を追跡
  • 適応的なランキング体験でユーザーが最も関心を持つコンテンツを優先表示

10:17 – Wrap-up

  • CoreSpotlight で完全にプライベートなオンデバイス検索インデックスを構築
  • セマンティック検索により、より強力で直感的な検索体験を提供
  • 複数プラットフォームとロケールに対応した多様なコンテンツ検索を実現
  • App Intents や CoreData との統合でさらなる検索機能を拡張

WordPress：テーマをアップデートしたらCSSカスタマイズが消えた

WordPress の 外観＞カスタマイズ＞追加CSS に書いていたつもりが、一部はサーバー上のCSSを直接上書きしていたっぽく、テーマをアップデートしたらカスタマイズしたはずのデザインが消失してしまった。

また何かあった時のために残しておく。CSS 詳しくないのと、動けばいい程度のノリなので適当。ちなみに今使っているテーマは WordPress が提供する Twenty Sixteen。

div.entry-content, aside {
  font-family: Montserrat, "Helvetica Neue", sans-serif;
}

blockquote {
  font-size: 1rem;
}

code {
  background-color: #eeeeee;
  border-radius: 4px;
}

@media screen and (min-width: 61.5625em) {
  body:not(.search-results) article:not(.type-page) img.below-entry-meta,
  body:not(.search-results) article:not(.type-page) figure.below-entry-meta,
  body:not(.search-results) article:not(.type-page) .wp-block-image figcaption.below-entry-meta 
{
  margin-left: auto;
  max-width: 100%;
}

聴講メモ：集まれSwift好き！Swift愛好会 vol.94 @ ウェルスナビ株式会社

Swift 愛好会に現地参加。

コーディングエージェントでの開発に関するテーマが半分。codelynx さんの発表は月初のMOSAでも聴いていたが開発事例が増えていて、スピード感がすごい。GitHub Copilot for Xcode、仕事で使っているが、エージェントモードは使ってなかったし、画像アップロードに対応しているのは知らなかった。実用性高そう。

Icon Composer は iOS 26 対応では一番取り組みやすい＆効果が見えやすい部分なので、落とし穴が聞けてよかった。ユニットテストでの小数点の扱い、Apple がテストライブラリでの対応を放棄しているのが悲しい、、笑

イベントページ：https://love-swift.connpass.com/event/361053/

Icon Composer のいろいろ

Megabits_mzq さん

  • レンズをモチーフにしたアイコンを Icon Composer で再現した時に発生した課題
  • レイヤーに分ける必要がある：アートボードを分割した
  • Composer にインポートする際の問題
    • ガラス効果が見えない：svgファイルにキャンバスサイズと同じ四角が存在した、Composer がこの外周をエッジと認定
      • 解決策：svgでなくPNGで書き出すこと
      • PNGはぼやけるのでsvgがよいが、、
    • Mono モード、なんか暗い？：元の緑色の明度が暗かった
      • 解決策：Composer 上で Mono モード専用に色を調整できる
    • レイヤーが多すぎるという警告：4レイヤーのみ
      • 解決策：デザイン調整するしかない、背景は Composer で設定でき、自分でレイヤー用意する必要ないので節約できる
    • 下半分をぼかす視覚効果：iOS 26 では無理そう
      • 解決策：ぼかしをなくす
  • .icn を Assets の隣におけば表示される
  • 新しいSDKでコンパイルすれば古いOSでもこのバージョンが使われる
    • → コンパイル途中で画像に変換される（多分）

Claude Code で創る世界と壊れる世界

codelynx さん

“聴講メモ：集まれSwift好き！Swift愛好会 vol.94 @ ウェルスナビ株式会社” の続きを読む