トーク

「Human Interface Guidelines (HIG)、重要だとわかってはいるけれど、全部読むのは大変…」
多くのiOS開発者が一度は抱えるこの悩み。私たちのチームも例外ではなく、UI実装の際に「これで本当に良いんだっけ？」と自信が持てなかったり、他職種とのコミュニケーションで認識の齟齬が生まれたりする課題を抱えていました。

iOSエンジニアとして、イケてるアプリを作るにはプラットフォームへの深い理解が不可欠です。
そこで、私たちはiOSメンバー全員でHIGの輪読会を始めることにしました。

本セッションでは、この輪読会を企画・運営した経験を元に、チームでHIGを学び、開発に活かすための具体的なノウハウをお伝えします。

【本セッションでお話しする内容】

• HIG輪読会を開催するに至った背景・目的
• HIG輪読会を無理なく進めるための運営方法
• HIG輪読会の成果とメリット
• 「実はHIGにこんなことが書かれている！」興味深いトピックの紹介
• HIG輪読会ならではの課題点と改善策

このセッションを通じて、「自分のチームでもやってみたい！」と思っていただけるような、輪読会を始めるための具体的なノウハウとモチベーションを持ち帰っていただければ幸いです。

App Intents フレームワークは、Shortcuts、Spotlight、Siri、Control Center、Widgets など、iOS 全体とアプリをつなぐ「共通言語」としての役割を担う存在となっています。
WWDC 2025 でもアップデートがあり、さらに Apple Intelligence でも活用可能になることが発表された今、App Intents を理解し、活用方法を学んでおくことは非常に重要です。その重要性は多くの開発者が感じていると思いますが、実際には、気になってはいたけどあまり触れられていないという方も多いのではないでしょうか？
App Intents を活用することで、アプリが起動していなくてもユーザーとつながることができる仕組みを実現できます。アプリが開いている状態に依存しない価値提供が当たり前になる中で、App Intents を取り入れたアーキテクチャは、AI 連携を含む今後の拡張性とも自然に結びつくと感じています。
本トークでは、Shortcuts、Control Center、Widgets など実際に対応してみた中で得られた知見をもとに、 App Intents の設計や使いどころを実装例を交えながら、お話しします。

• App Intents の基本的な実装方法と構成要素
• 開発中に直面したはまりポイントとその回避法
• App Intents をアプリ開発においてどう位置づけるか？
• 複数の機能間で再利用しやすい App Intents 設計の考え方
• Apple Intelligence 時代に向けて今やっておくべきこと

このセッションを通じて、実務にすぐ活かせる具体的な設計のヒントと、Apple の目指す未来に対応するための考え方をお持ち帰りいただければと思います。

チーム開発において、一貫性はとても大切です。
一方でルールを運用していくのは大変で、生産性を悪化させるリスクもあります。

そのバランスのため、多くのチームでLinter, Formatterなどを使って一貫性を担保していると思います。
しかし、インデントやimport順といった一般的なルールは簡単に適用できても、
ドメイン依存など、凝ったルールを導入したいケースでは工夫が必要です。

shellなどのカスタムスクリプトによって実現しているチームも多いと思いますが、
AIの流行もあり自動化ツールの実装コストも大幅に下がってきているため、
より凝ったツールを作る時代が来ています。

かつてxcodeprojのコンフリクトに困らされた我々は、XcodeGenによる生成に助けられました。
今そのコンフリクトはなくなったものの、Package.swiftは依存やターゲットを手動更新せねばなりません。
そのため追加忘れ・削除忘れ・重複をはじめ、並び順やグルーピング、推移的依存をどこまで書くかなど、
linterでは対応しきれない揺れや負債が多く生まれます。

弊社のiOSチームではgo modulesに学び、swift-syntaxを活用したスクリプトによって、Package.swiftを自動で更新しています！
完全ではないのですが、Swiftファイルを記述するだけでターゲットやその依存関係が自動的に追記・削除されるようになっています。

とっつきにくいイメージのswift-syntaxですが実装にも触れつつ、このスクリプトのアイデア・実装例をご紹介いたします。

「誰もやらないなら、自分がやる。」
大学生活の中で感じた不便さを解決するため、学内情報を一元化するiOSアプリ「トクメモ＋」を開発しました。これは、ログインのたびにID・パスワードを何度も入力させられ、講義、レポート、図書館など、バラバラに存在する大学の情報を“毎日使いたいもの”としてまとめあげたアプリです。

結果としてこのアプリは、学部生の60%以上（月間3500MAU）に使われる学内最大のアプリとなり、自分の手を離れることが決まりました。
しかし、そこに至るまでには数えきれないほどの失敗と学びがありました。

このセッションでは、個人開発からチーム運営、そして譲渡に至るまでの過程で直面した3つの失敗談と、その乗り越え方をお話しします。

① 大学からのサポートがないからこその落とし穴
ログイン処理が無限ループする致命的なバグや「URLをまとめれば便利」と思った設計が、唐突な仕様変更で崩壊。
仕様が不明な環境で、何を頼りに設計すればよかったのか？ 実例をもとに振り返ります。

② 学生開発チームならではの壁
広報と開発を分担した11人の学生団体は、いつしか“熱意はあるけど動かない”チームに。やがて団体は解散し再び立ち上げたのは、「やってほしいこと」ではなく、「やりたいこと・できること」を尊重する体制でした。 学生開発チームを動かすために必要だった視点をお話しします。

③ 属人化が生んだ“引き継げないアプリ”
コードが複雑化しすぎて、「開発したい初学者がいても触れない」と気づいたとき、iOSアプリを作り直す決断をしました。Keychainやオンボーディングなど技術面の引き継ぎ課題に対して何を諦めたか。引き継ぎの“壁”と“選択”の話をします。

順調な成功談ではなく、「ちゃんと失敗した話」から得たリアルな知見を、学生・個人開発者・引き継ぎに悩む方々へお届けします。

WAVファイルのバイナリフォーマットを知り、Swiftを使ってゼロからWAVファイルをつくってみましょう。

iOSで録音される音声データを調査する中で、WAVファイルに触れる機会がありました。
音声データを数値に変換し、ひとつひとつの音を決まったフォーマットで組み立ててWAVファイルを完成させるまでの過程をご説明します。

このセッションは以下のような内容を含む予定です。
・音声データとリニアPCM
・WAVファイルのバイナリフォーマット
・エンディアン
・SwiftのDataからファイルを構成する
・WAVファイルをリアルタイムで組み立てる
・波形を確認する

トークを通じてバイナリデータに親しむことで、いつも扱っているファイルをより自由にいじれるようになりましょう！

ネイティブアプリ開発において、ユーザーが「迷わず」「快適に」「自然に」操作できるUXを実現することは重要です。

しかし、なぜユーザーは特定のUIでつまずくのか、なぜこのデザインが使いやすいのか、その背後にある心理メカニズムを理解していますか？
本セッションでは、認知心理学の基本と、ユーザーの脳や行動の仕組みを活用した実践的UIデザインテクニックを解説します。

特に、体験全体の印象操作、モチベーション維持 、ボタン配置の最適化など、アプリUI/UXの具体例を交えながら、明日から実践できる「ツボ」を伝授します。

これらの原則は、ユーザーの認知負荷を軽減し、直感的な操作感を高める上で非常に強力です。
セッションのゴールは、参加者の皆さんが、自身の開発アプリのUI/UXをユーザーの認知プロセスに基づいて見直し、より魅力的でストレスの少ない体験へと改善するための具体的な思考フレームワークとヒントを持ち帰ることです。

さあ、認知心理学の知見で、あなたのアプリを「ユーザーに愛されるアプリ」へと一歩進化させましょう！

デジタルプロダクトの成功には、ユーザー体験の最適化が欠かせません。そこでよく用いられる手法の一つに A/B テストがあります。
A/B テストは、Webサイトやアプリなどで、異なるバージョン（バージョン A と B）をユーザーにランダムに表示し、どちらのパターンがより効果的かを検証する手法です。新しい機能や、既存の機能を削除した時の影響を定量的に評価することができます。

一見簡単そうに思える A/B テストですが、適切に実施することは難しく、様々な罠が潜んでいます。例えば、ユーザーに表示するバージョンをサーバーから取得できない時、どちらかのバージョンにフォールバックしてそのログを送信してしまうと、結果にバイアスがかかってしまいます。このように、アプリ側の実装によって A/B テストが失敗してしまうことがあります。

本トークでは、A/B テストの基本的な考え方と、アプリでの実装・実施時に気をつけた方が良い点を、実体験を交えながらお話します。A/B テスト結果の具体的な分析方法についてはお話しません。
参加者はこのトークを聞くことによって、A/B テストの設計とアプリ実装時の注意点を学ぶことができます。

私たちのiPadアプリはリリースから約15年が経過し、長年の機能開発の結果、技術的負債を抱えるに至りました。
具体的には、

• 肥大化した "Fat ViewController" が多数存在し、改修時の影響範囲の特定を困難にしています。
  • シングルトンやAppDelegateへの過度な依存が、クラス間の密結合を生み出しています。
  • 上記の結果として、ユニットテストを書くことが極めて難しい、あるいは不可能なコードベースとなっています。

また、コードの大部分は歴史的経緯からObjective-Cで書かれており、今後の採用観点からSwift化への置き換えとこれらの負債を解消しながらが大きな課題です。
本セッションでは、これらの技術的負債に対し、日々の機能開発を止めることなく、いかにして立ち向かっているか、そのアプローチを共有します。

主にお話しする内容：
Fat ViewControllerの分割戦略: 巨大なViewControllerの責務を、Presenter/ViewModel//UseCaseといった単位へ安全に分割していくか、具体的なリファクタリング手法をコードと共に解説します。
依存関係の解消プロセス: DI（依存性注入）の考え方を導入し、AppDelegateやシングルトンへの直接参照をどのように剥がしていくか、その段階的なプロセスを共有します。
テスト可能なコードへの改善: 既存のコードにユニットテストを追加するための、インターフェース導入や副作用の分離といった具体的な手法を紹介します。

このセッションを通じて、同様の課題を抱える開発者の皆さんが、明日から自身のプロダクトで試せる具体的な一歩を踏み出すための、現実的な選択肢と知見を持ち帰っていただくことを目指します。

私たちは普段Swiftのコードを通じて、画面に美しいUIを表示したり、スピーカーから音を鳴らしたり、ユーザーのタップを受け取ったり、ネットワーク越しにデータを送受信したりしています。

しかし、Swiftで書かれたプログラムが、どうやってiPhoneやMacで実行されるのか、考えたことはありますか？

コンピューターはどのような仕組みで動いているのでしょうか。コンピューターの頭脳とも言えるCPUからは、世界がどのように見えているのでしょうか。

Swiftのプログラムではなかなか見えてこないコンピューターの世界が、OSを介さずに動くEmbedded Swiftだと少し見えてきます。
　
このトークでは、Embedded Swiftを活用してプログラムが動く仕組みを解き明かしていきます。

プログラムがどうやってコンピューターで実行されるのか、メモリや入出力装置とどのようにコミュニケーションするのか、知識だけでなくコードとデモを交えて解説します。

普段のアプリ開発では見えない、低レイヤーの世界を一緒に覗いてみましょう！

Apple Watchのようなリソース制約が厳しいデバイスで、音・振動・UIアニメーションをリアルタイムに動かし続けるにはどうすればいいのか？
watchOSを使った開発では、シミュレーターでは軽快に動いても実機では長時間安定して動作しないことが多々あります。

私がwatchOS向けのメトロノームアプリを開発した時はwatchOSでリアルタイムな処理を安定させるための設計が欠かせませんでした。

本発表では、watchOSで高負荷な処理を安定して動かすための設計とパフォーマンスチューニングの実践知見を、背景から具体的な施策事例まで解説します。

具体的には

• AVAudioEngineの基礎知識とwatchOS実機での注意点
• watchOSにおける触覚フィードバック(WKHapticType、SensoryFeedback)の概要
• 音・振動・UIアニメーションを同時に動かすタイミング制御の実装
• 実機で発生しやすい処理落ち・中断のパターンと防止策
• AVAudioEngineをwatchOS上で効率良く動かすためのパフォーマンス改善施策

について詳細に話します。

また、実用に耐えるようにチューニングが成功した証としてメトロノームアプリで練習した作品をチューバで実演奏します。

Apple Watchで高負荷なリアルタイム処理に挑む方へ向けて役立つノウハウをお伝えできれば幸いです。

iPadは、iOS 9でマルチウィンドウ機能が導入されて以来、複数のアプリを同時に利用できるよう段階的に進化してきました。そして、今年登場予定のiPadOS 26ではその機能がさらに進化し、各ウィンドウのサイズを自由に変更したり、複数のアプリを重ねて表示したりと、macOSのような、より自由度の高いマルチタスク環境が実現します。

この変化は、私たちiOSエンジニアにとって、単なるUI表現のバリエーションの追加にとどまらず、アプリの設計思想そのものに影響を与える可能性があります。

もちろん、macOSでさえマルチウィンドウの活用が自然に馴染むのは一部のアプリに限られており、すべてのアプリで多ウィンドウ対応が最適解になるわけではありません。しかし、特定の用途、例えばドキュメント編集やクリエイティブツール、情報集約型のアプリにおいては、ユーザー体験を大きく向上させる可能性を秘めています。

本トークでは、iPadOS 26における新しいマルチウィンドウ環境を最大限に活かすために、どのようなアプリ表現が可能になるのかを具体例とともに紹介しつつ、その実装方法を解説します。

想定視聴者:
マルチウィンドウ対応に関心があるiPadOSやvisionOSのアプリエンジニア

話す内容:
・ マルチウィンドウだからこそ実現できるアプリの表現例
・ マルチウィンドウ環境におけるUISceneのライフサイクルの要点
・ 具体的なマルチウィンドウの実装方法
・ マルチウィンドウでできること・できないこと
・ 既存アプリのiPadOS 26への移行で押さえるべき注意点

サブスクリプションの機能をアプリに導入する際に、ペイウォール（サブスクリプションの登録を促す画面）のデザイン、文言、表示タイミングで悩んだことはありませんか？Human Interface Guidelinesにはアプリ内課金についてのドキュメントがあり、自動更新サブスクリプションに関してはデベロッパー向けのドキュメントがあります。ペイウォールをガイドラインに沿って設計することは、サブスクリプションの機能をリリースするための前提です。しかし、そのことと、ペイウォールが効果的であることは別の事象です。ガイドラインに沿っていたとしても、ペイウォールを前にしたユーザが好意的に受け取るとは限りません。

では、効果的なペイウォールとはどのようなものでしょうか？世界中のアプリの中から、サブスクリプションの機能があり、かつ売上も十分に立っている人気アプリを、リージョンとカテゴリを分散させて100個ピックアップし、実際のペイウォールを気合いと根性で分析しました。

本セッションでは、まず前提であるアプリ内課金が従うべきHuman Interface Guidelinesに軽く触れます。次に100個のアプリのペイウォールを以下の7つの観点から分析した結果とその考察を共有します。そして、それらを踏まえて実際のアプリに適用して得られた結果をお伝えします。最後に、ペイウォールを設計する際に重要となる心得および今日から使えるTips集を紹介します。

分析の7つの観点
（1） UIの構成要素
（2） 情報量・情報強度およびレイアウト
（3） コピーライティング
（4） 訴求ポイント
（5） 価格とプランの構成
（6） ペイウォールを表示するタイミング
（7） 無料の機能群と有料の機能群の比率

自転車のタイヤがパンクしたら、あなたはどうしますか？自転車屋に持っていって修理してもらうか、あるいは自分で直してしまうかもしれません。まさか自転車ごと買い替えるなんてことはしないですよね。では、iPhoneの画面が割れたら？あれ、買い替えるかも…？

こう考えてしまうのには訳があります。私たち消費者を修理から遠ざける要因が、ハードウェアの設計やソフトウェアの制限、知的財産権、さらにはマーケティングメッセージにまで、至るところに潜んでいるのです。例えば、AirPodsのネジがない設計は、修理の第一ステップである「デバイスを開ける」ことをほぼ不可能にしています。

修理の疎遠化は企業に大きな利益をもたらす一方で、消費者には経済的負担を、地球には環境負荷を与えています。こうした状況を打破するために、「修理する権利」を求める運動が、欧米やヨーロッパを中心に世界中で広がっています。もちろんAppleも例外ではありません。

本セッションでは、次のような内容をお話しします。

• なぜ修理が重要なのか？
• Apple製品から修理を遠ざけている要因たち
• 「修理する権利」を求める運動と、それを受けてAppleが変えたこと
• 日本で「修理する権利」を阻む壁: 技適
• 私たちiOSエンジニアにできること: Minimum deployment targetを再考する

修理がもたらすのは、金銭的・環境的価値だけではありません。修理は、デバイスの仕組みをより深く理解することに役立ち、自分が所有するモノを最大限に使いこなすことを可能にします。Appleプラットフォームでサービスを提供する者として、「修理する権利」について一緒に考えましょう。

WWDC25で発表されたAIツールの進化は凄まじく、Foundation Modelは実際に触った人も多いのではないでしょうか。
そして今、多くの開発者がAI機能の導入を検討している時期かと思います。そこで、導入に際して何が課題点なのか、精度はどのくらいなのかについて私が皆さんの代わりに検証を行います。
ただ、昨今は自然言語の話題が多いので、今回は敢えて視点を変え画像認識に焦点を当てます。そして、その中でも特にオンデバイスの良さが活かせる「顔認証」を調査します。

「VisionフレームワークやCreateMLを使ったお手軽実装」から、「PyTorchやMLXで独自モデルを構築する本格実装」まで、具体的な実装方法をコードと共に紹介します。
それぞれのメリット・デメリット、そして「実装難易度」と「認証精度」を徹底的に比較・解説します。

今回は顔認証を題材にしますが、ここで得られる知見は、画像分類や認識などの他のモデルを扱う上でも必ず役立つはずです。
あなたのアプリに最適なAI技術を見つけるための、実践的なヒントをぜひ持ち帰ってください！

【構成】
・難易度別の実装方法とその詳細
・実機で動かした場合の精度や負荷
・実装途中の失敗談やTips

「エンジニアの価値は技術力だ。それが正義で、格好いい」
そう信じたい一方で、世の中技術力に長けている人ばかりではありません。そして自分より遥かに優れた同期と比べて無力感を覚えてしまうものです。
もしあなたが今、技術力に絶対の自信が持てなくても大丈夫です。 入社時はoptionalの存在すら忘れていた私が、社内で新人賞を受賞できたのです。

このLTでは、技術で突き抜けられない自分が社内で少しでも認めてもらうためにどう戦ってきたのか、そのリアルな姿をお見せします。
社内でiOSエンジニアとして働く上で本当に必要だったスキルやスタンスを全て詰め込みました。

あなたの明日からの働き方に、何か一つでもヒントを持ち帰っていただけたらそれ以上に嬉しいことはありません。
覗きにくるだけでも結構ですので、お気軽に足をお運びください。

【構成】
・iOSエンジニアの評価と会社のカルチャー理解
・外部登壇が引き起こすキャリアへの影響
・エンジニアの特性と差別化
・キャリアを豊かにする「複利効果」

皆さん、普段コードレビューを行なっていますでしょうか？

もし、そうならこんな悩みや不安を抱えたことはありませんか？

• コメントはいつも「LGTM👍🏻」だけ。本当にコードは読まれているのだろうか？
• レビュー依頼を出しても一向に反応がなく、開発が進まずに焦りを感じる。
• 人間関係を気にするあまり、本当に伝えるべき指摘を躊躇してしまう。

これらの課題は、コードレビューの目的や手法をチームで共有できていない「雰囲気レビュー」が原因かもしれません。

「雰囲気レビュー」を放置すると、

• コードレビューがただの承認作業と化し、品質向上の機会を失う。
• レビュアーの経験や気分によって指摘の質が大きく変わってしまう。
• 終わらないコメントの応酬で開発が遅延する。（あるいは、諦めてマージしてしまう）

といった事態を招き、チーム全体の生産性を下げかねません。

本トークでは、これらの課題を解決するため、明日からすぐに実践できる具体的なノウハウを解説します。

• コードレビューの本質とは何か？
• コードレビューの登場人物とそれぞれの責務
• 関係を悪化させる不安をなくしつつ、的確に意図を伝えるコメント術

などについて、私自身のこれまでの経験と『Looks good to me』という書籍の翻訳を通じて得られた知見を基に、皆さんと一緒に考えていきます。

さらに、避けては通れない未来として、AIを活用したコードレビューについても深掘りします。AIツールがどのようにコードレビューを効率化し、どのような新たな課題が生じる可能性があるのか、皆さんと共に考えます。

本トークが、皆さんのコードレビューに対するモヤモヤを少しでも解消し、自信を持ってレビューができる一助となりましたら幸いです。

「Siriで自分のアプリを操作したい」「Spotlightから直接アプリの機能を使いたい」「Apple Intelligenceと連携させたい」—そんな願いを叶えるのがApp Intentです！
iOS 26では、Apple Intelligenceが本格始動し、App Intentがそのゲートウェイとしてますます重要になりました。

従来、アプリの機能はアプリ内でしか使えませんでした。
ユーザーがメモアプリでメモを作りたいとき、アプリを開いて、画面をタップして、やっと作成できる。
この「アプリを開く」という壁が、ユーザー体験の大きな障害でした。

App Intentは、この壁を取り払います！
Siriに話しかけるだけでメモを作成、Spotlightから検索して直接アプリの機能を実行、ウィジェットやコントロールセンターからワンタップでアクション実行。
さらにiOS 26では、Visual Intelligence（カメラでの画像検索）、Spotlight上でのアクション実行、Apple Intelligenceとの深い連携が可能になりました。

基本的なIntent作成から始まり、App Shortcutの設定、Entity（動的データ）の扱い方、Query（検索機能）の実装、そして最新のVisual Intelligence連携まで。
Apple Intelligence時代に必要な実装パターンを、実際のコードと共にお見せします。
App Intentで、あなたのアプリをApple エコシステムの一等市民にしましょう！

SwiftUI における Container views （以下「コンテナビュー」という）とは、複数の子ビューを内部に持ち、それらを管理・配置する役割を持つビューのことです。代表的なものとして、子ビューを縦方向に整列する VStack、横方向に整列する HStack、スクロール可能なリストを構成する List などが挙げられます。

WWDC24では、こうしたコンテナビューをより柔軟にカスタマイズできる新しいAPIが発表されました。これにより、たとえば「子ビューを横方向に整列しつつ、横幅の上限に達した場合に自動で折り返す HStack」のような独自のレイアウトコンテナを、SwiftUIの構文のまま実装できるようになります。

ただし、この新APIはiOS18以降でのみ利用可能です。iOS17以前をサポートするアプリは依然として多く、なかにはiOS16を対象とするアプリも少なくありません。

そこで、iOS17以前の環境でもSwiftUIらしい記述でカスタムコンテナビューを構築可能な、非公開APIである Variadic View に注目します。これを活用すれば、iOS16やiOS17をサポートする環境でも柔軟なレイアウトを実現できます。

本セッションでは、まずSwiftUIにおけるコンテナビューとは何かを説明し、その中で、コンテナビューを定義する際に重要な概念となる2種類のsubviews（Declared subviewsとResolved subviews）に触れます。その上で、iOS18以降で使える新しいAPIによってカスタマイズしたコンテナビューを定義する方法を実例を用いて紹介します。次に、Variadic Viewの仕組みを解説します。最後に、新APIにより実装したコンテナビューと同様のものをVariadic Viewを用いて定義する方法を詳しく解説します。

Xcodeでコードを読む際、依存関係を理解するために定義ジャンプやシンボル検索を利用した経験はありませんか？
それらの機能はコードジャンプであり、依存関係を1階層しか調べられません。例えば型やメンバの構造を上下に、そこから選択した要素の依存関係を左右にそれぞれ階層構造で可視化するツールを自作できると、より調べやすくなります。
そのようなツールを開発する際にまず思いつくのが、SwiftSyntaxです。

SwiftSyntaxでは、抽象構文木を走査することでSwiftソースコードの構造を抽出できます。
しかし、SwiftSyntaxを使って依存関係を自力で抽出することは困難です。あるプロパティについて依存関係を抽出したい場合、抽象構文木の各ノードの名前に注目したらいいでしょうか。この時、複数の名前空間があると対応が困難です。

そのような場合に、IndexStoreという強力な仕組みを使うことができます。IndexStoreから各シンボルの位置や一意な識別子、その役割を抽出できます。さらに、シンボルが他のどのシンボルを参照しているかを抽出できます。
一方で、IndexStoreから得られるシンボルの情報だけでは、その型やメンバの構造は分かりません。

そこで、SwiftSyntaxとIndexStoreを組み合わせることで、「この型はこんなメンバを持っていて、それは何に影響を与えていて、何に依存しているのか」という情報を抽出することができます。

本トークでは、以下をお話しします。

• SwiftSyntaxを使ってソースコードの構造を維持しながら宣言を抽出する方法
• IndexStoreの概要
• シンボルの一意な識別子を使って、ネストした宣言に効率良くアクセスする方法
• SwiftSyntaxとIndexStoreを組み合わせたツールの実装例
• Xcodeとの比較

サードパーティアプリ開発者は長年、Appleの純正アラーム機能に制約を感じてきました。
Silent modeやFocus modeに阻まれ、重要な通知が届かないリスクは、開発者とユーザー双方にとって深刻な問題でした。

iOS 26のAlarmKitは、この技術的障壁をついに解放し、開発者にも革命的なアラーム機能の実装を可能にします。
従来のローカル通知の根本的問題は、デバイス設定への依存性でした。
AlarmKitを使用することで、重要な通知がどんな状況でもユーザーに確実に届くようになります。

AlarmKitの主な革新として以下の特徴が挙げられます。

1）あらゆるシステム設定を突破するアラーム実行により、Silent modeやFocus modeの影響を受けない確実な通知を実現
2）Live Activitiesと連携したDynamic Island統合により、ユーザーの目に留まりやすい視覚的なアラーム表示を提供
3）Apple Watchでの自動同期により、デバイスを問わない一貫したアラーム機能
4）App Intentsによるカスタムアクション実行により、アラーム後の独自ワークフローを組み込み可能

実装デモを行い、料理タイマーアプリを題材に段階的な構築過程をお見せします。
AlarmKitの登場により、開発者はユーザーにとってより信頼性の高いアラーム機能を提供できるようになります。