トーク

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

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

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

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

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

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

自転車のタイヤがパンクしたら、あなたはどうしますか？自転車屋に持っていって修理してもらうか、あるいは自分で直してしまうかもしれません。まさか自転車ごと買い替えるなんてことはしないですよね。では、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との比較

私自身がこの数年主務としてきた領域はAndroidアプリ開発です。
「Androidアプリ開発のことなら設計からパフォーマンス改善まで何でもござれ！」と言える自負はある程度あれど、iOS開発の議論となると借りてきた猫のようにしおらしくせざるを得ないという場面も多々あります。
そんな私に、iOSアプリ開発者が多数を占めるチームでモバイルアプリ開発のテックリードを務めることはできるのでしょうか？iOS開発未経験というハンディキャップを背負いながら、いかにしてこの重要な役割を果たしていったのか、そのリアルな奮闘と学びを共有します。

テックリードという立場は、多岐にわたる技術課題に対しメンバーと共に立ち向かう深い知識が求められる職能だと解釈しています。このセッションでは開発環境やビルドシステムの違い、Jetpack Composeとは異なるUIKit/SwiftUIの思想など、Androidエンジニアにとって大きなギャップとなる具体的なポイントに焦点を当てます。 そして、私がどのようにこれらのギャップを効率的にキャッチアップし、チームメンバーと効果的なコミュニケーションを図り、さらには技術的な意思決定を行うための知識を身につけたか、そのリアルな体験談をお伝えします。

iOS開発にこれから入門しようというAndroidエンジニアの皆さんにとってはプラットフォーム間の技術的なギャップをいかに乗り越えるかのヒントを、
そしてiOS開発者の皆さんにはAndroidエンジニアから見た世界を知っていただき、ご自身の開発スタイルを客観的に見つめ直すきっかけや、Androidエンジニアとの協業における相互理解を深める視点を提供できるようなセッションを目指します。

visionOS 26 では、iPhone／iPad のホーム画面でおなじみのウィジェットを、壁に貼る置き時計のように、机に置く写真立てのように、現実空間へ自在に配置できます。

本講演では、既存の iOSウィジェットを visionOS 26 へ移植する際の注意点と移行手順を、ソースコードと合わせて詳しく解説します。

まず visionOS におけるウィジェットの基礎を整理し、インタラクション対応の WidgetKit、壁掛け（elevated）／埋め込み（recessed）という二つのマウントスタイルの違いを説明します。
更に、WWDC 25の発表時に気になった「ウィジェットはいくつまで配置できるのか？」「どれほど現実世界に自然に溶け込むのか？」といった疑問についても、調査結果をデモ動画を交えて紹介します。

既存のiOSウィジェットをvisionOSに拡張する際に、利用可能なウィジェット種別の制限や背景色を変更した場合の影響、シミュレーターと実機での挙動の差異など、開発時に押さえておくべきポイントを解説します。
Apple Vision Pro を持っていなくても実践可能な内容となっています。

メルカリでは過去、ネイティブからReact Native、Flutterに至るまで、多岐にわたる方針でモバイルアプリ開発を行ってきました。それらの経験も踏まえ、今回の新規アプリ開発では、既存リポジトリをモノレポとして再定義し、その中で新たなネイティブアプリを開発する戦略を採用しました。

大規模な単一レポジトリ環境で複数のモバイルアプリを開発・運用することは、コードの一元管理、実装の再利用による開発速度の向上、ビルドシステムや周辺ツールの統一といった様々なメリットを享受できます。一方で、複数アプリでの利用を前提としたモジュール再設計の必要性や、各モジュールの影響範囲の拡大、技術的・組織的な依存関係がボトルネック化するといった問題も存在します。

もちろん、こういったメリット・デメリットは、既存のコードベース、目標の時間軸、組織構造、メンバー構成といった様々な変数によって、その性質や度合いは変化します。本トークでは、この点を踏まえつつ、モノレポへの移行からその後のアプリ開発に至るまでの実態を、事例と共に紹介します。主なトピックは以下の通りです。

• 既存のリポジトリ環境から移行するまでの具体的なステップ、Bazelを用いた設計、その過程で直面した課題
• 再利用性と独立性を両立させるモジュール設計の勘所と、実際の再設計事例
• アーキテクチャや個々の実装パターン、技術の選定方針と判断基準（例: swiftui-atom-properties, gRPC, etc.）
• 開発体制および組織面におけるチャレンジ

私たちの戦略と意思決定の過程を一つの実践例として共有します。

Vibe Cooking は、"ノリで料理する" がコンセプトのアプリです。ユーザーが複数のレシピを選ぶと、AI がそれらを組み合わせて一つの新しいレシピを提案し、料理初心者でも効率的に複数の料理を作れるようにサポートします。

これまで Vibe Cooking のレシピ構築機能は、サードパーティ製の LLM を利用して実現していました。今回は、WWDC25 で発表された Foundation Models Framework を活用し、この機能をオンデバイスで実現することに挑戦します。

このトークでは、その挑戦の過程をみなさまと共有し、Foundation Models Framework を用いてどこまで実用的な機能が実現できるのか、具体的な事例を通してその可能性と限界を探ります。Foundation Models Framework の実際の活用イメージを深め、皆様の iOS アプリ開発における選択肢を広げる一助となれば幸いです。

このトークでお話しすること

• Vibe Cooking の概要と従来のレシピ構築方法: コンセプトと、これまでの実装について説明します。
• Foundation Models Framework の基礎: 基本的な概念や、オンデバイスでのモデル実行のメリットについて解説します。
• Foundation Models Framework を用いたレシピ構築の実装: どのようにフレームワークを組み込み、レシピ構築を実現したのか、具体的なコード例や工夫を交えて紹介します。
• サードパーティ製 LLM との比較: 気づいた違い、パフォーマンス、制約、そしてそれぞれの利点と欠点について深掘りします。

複数のiOSアプリを複数人で運用する組織では、共通機能の管理、状態の一貫性、チーム間の開発効率が重要な課題となります。本セッションでは、The Composable Architecture（TCA）を用いた 大規模開発の実例を通じて、これらの課題を体系的に解決する手法を紹介します。

紹介する主要技術パターン：

• 階層的Routerアーキテクチャ → 複雑なナビゲーションを型安全に管理し、画面遷移のバグを大幅削減
• RequestReducerパターン → 非同期処理のボイラープレートを90%削減し、開発効率を向上
• Sharing API活用 → アプリ間の状態共有を一元化し、データ不整合を防止
• リアルタイムデータ統合 → TCA Effectsとの連携により、複雑な状態更新を予測可能に制御

これらの技術が相互に連携することで、従来は困難だった大規模アプリの状態管理が劇的に改善されます。
実際のコード例、包括的なテスト戦略、運用で得られた具体的な成果指標も共有し、TCAの実用性を実証します。

TCA で大規模開発の課題を解決したい方必見のセッションです。

想定視聴者: TCAの基礎知識があり、実際のプロダクション導入を検討している中級〜iOSエンジニア、複数アプリの状態管理課題を抱えるチーム

Gunosyでは、複数のモバイルアプリを少人数のチームで開発・運用しています。
以前はアプリごとに専任を置く体制を取っていましたが、事業やチームのフェーズが進むにつれて、リソース調整や意思決定の硬直化、属人化のリスクといった課題が顕在化してきました。

たとえば、共通モジュールに対する責任範囲が曖昧であったり、特定のプロダクトに負荷が集中しても他のメンバーが支援しにくかったり、類似の施策を各プロダクトで個別に設計・実装することで、二重のコストが発生するような場面も増えていきました。
こうした課題に対応するため、私たちはチーム体制を柔軟かつ安定的に回し続けられるものへと整えていく必要がありました。

プロダクト横断で関与できる「ゆるい主担当・副担当制」、レビューや仕様共有の仕組み、会議体の統合、そしてマネージャーが進行役から支援役へと変わることによる構造的な変化など、一つひとつの現実的な試行錯誤の積み重ねが、いまのチームを支えています。

本トークでは、こうした取り組みのプロセスと背景を、等身大の視点でご紹介します。

「複数アプリ × 少人数チーム」という制約の中で、運用のしなやかさや持続性を模索している方にとって、共感と具体的なヒントをお持ち帰りいただける内容です。
マネージャーに限らず、チームの一員として仕様共有や体制づくりに関わるすべての方にとって、有用な視点をお届けします。

地図アプリのユーザーエクスペリエンス（UX）は、リアルタイムでのインタラクティブな操作、例えばピンの操作や動的な図形描画により大きく向上します。
しかし、その裏側には複雑なロジックの扱いや幾何学的な計算が不可欠であり、パフォーマンスとの両立は開発者を悩ませる課題です。

ここで活きるのが、生成AIと数学分野のアルゴリズム実装の相性の良さです。
生成AIは、その高い実装コストからこれまで試行錯誤が難しかった複雑なアルゴリズムを、AIの補助を受けて手軽に試行できる環境を提供します。

本セッションでは、生成AIを活用した新たな地図アプリケーションの幾何学アルゴリズムの開発手法を紹介し、パフォーマンスを維持しつつリッチなUXを実現する具体的な事例を解説します。
具体的には、インタラクティブなピンの押し出し制御や、動的なポリゴン合成などの実装を取り上げます。

• 地図外のViewへのオーバーレイ描画: 地図上の座標を画面上の座標へ正確に写像変換する技術
• 禁止領域からのインタラクティブなピンの押し出し: ポリゴン上の最近傍点を効率的に導出し、ピンを領域外へ配置するアルゴリズム
• 動的なポリゴン合成: Graham's scanを用いたConvex Hull（凸包）の計算による、複雑な図形の単純化と合成

また、これらのユースケースの解説に加え、生成AIを活用して高速に幾何学アルゴリズムを実装し、選定、比較、そしてパフォーマンスチューニングを行う具体的なアプローチを採用を見送った幾何学アルゴリズムや、その理由とともに紹介します。

このセッションを通じて、地図アプリケーション開発における幾何学アルゴリズム探求の手法と、生成AIがもたらす開発効率の向上、
そしてこだわり抜いた滑らかな地図UX実現のための実践的な知見を持ち帰ることができます！

Metal は Apple が提供する高性能・低レベルなグラフィックス API です。
開発者が GPU を直接制御し、複雑な描画処理を柔軟に実装できるのが大きな特徴ですが、「シェーダー言語や GPU の仕組みを知らないと使えないのでは？」と感じる方も多いかもしれません。実際、Metal は専門的で難しそうという印象を持たれがちです。

近年では SwiftUI でも簡単にシェーダー効果を利用できるようになってきており、Metal は以前より身近な存在になりつつあります。とはいえ、GPU が実際にどう動作し、どんな流れで画面が描かれているのかを理解せずに、なんとなく「雰囲気」で使ってしまっているケースも少なくありません。

このセッションでは、Metal に苦手意識を持っている開発者の方々に向けて、Metal がもはや「一部の専門家だけのツール」ではなく、iOS や macOS アプリでも実践的に使える現実的なレンダリング手段であることをお伝えします。

Metal の基本的なレンダリングパイプラインの流れを丁寧に解説し、最新の Metal 4 を活用した効率的な設計方法についても学んでいきます

セッション構成

1. Metalとは
2. 非ゲームアプリで Metal はどのように活用できるか？
3. レンダリングのための Metal パイプラインを理解する
4. 最新の Metal 4 に基づく効率的なレンダリングパイプラインの構築方法

「またCIが落ちた...」「テスト完了まであと25分...」このような経験はありませんか？私たちのiOSチームでは、ちょっとしたUIの修正でも全テストスイートの実行に30分以上かかり、開発者の集中力とモチベーションを奪っていました。1日に何度もPRを出すアクティブな開発では、この待ち時間が積み重なり、チーム全体の生産性を大きく損なっていたのです。

この課題を解決するため、私たちは「Selective Test」という仕組みを使いました、「変更した部分に関係するテストだけを実行する」というアプローチです。たとえば、ログイン画面のボタンの色を変更した場合、決済機能のテストまで実行する必要はありません。

仕組みはこうです。まず、プロジェクト内のすべてのファイルの「つながり」を把握します。AというファイルがBを使い、BがCを使っているという関係性を地図のように可視化。次に、変更されたファイルから、その地図をたどって影響を受ける部分を特定し、関連するテストだけを選び出します。

実装では壁にぶつかりました。最大の課題は、Swiftの「見えない依存関係」でした。プロトコルやextensionを多用するiOS開発では、静的解析だけでは不十分で、必要なテストが実行されない「見
逃し」が発生しました。私たちは実行時の情報も組み合わせることで、この問題を解決しました。

本セッションは、日々のCI待ち時間にフラストレーションを感じているiOSエンジニア、チームの開発効率を改善したいテックリード、大規模プロジェクトでのテスト戦略に悩んでいる方々に向けた内容です。セッション終了後、あなたは自分のプロジェクトでSelective Testを導入するための具体的な手順と、避けるべき落とし穴を理解し、明日から実践できる知識を持ち帰ることができます。

iOSDC Japan 2023で私たちが発表した「SVVS」。あれから2年、Swiftが大きく進化する中で、私たちの実装もまた大きな進化を遂げました。

本セッションではその続編として、最新のSwiftを活用した「SVVS実装戦略」をお届けします。その進化の過程で、私たちは以下の課題と向き合ってきました。

• アプリ全体で有効なものと、ログイン中にのみ有効なもののライフサイクル設計
• CombineからObservationへの移行とその影響
• DIを用いたUIロジックの単体テスト手法

これらの課題に対する私たちのアプローチを、具体的なコードの変遷と共にお見せします。

近年、セキュリティインシデントの報道が増加し、ユーザーのセキュリティ意識はかつてなく高まっています。特にリスト型攻撃の脅威から、メールアドレスとパスワードの組み合わせに依存しない認証手段は、今や当たり前に求められるようになりました。そして、万が一の流出やアカウント乗っ取りが発生した際の最終防衛線として、多要素認証（MFA）の重要性が再認識されています。

Firebase Authenticationが公式に提供する電話番号(SMS)によるMFAは強力ですが、SMS認証の運用コスト、ユーザーの電話番号提供への抵抗感、UX低下といった課題感を完全に解決しません。
本セッションでは、この課題を乗り越えるため、Firebaseの複数認証方法を「2要素目」として組み合わせ、柔軟なMFAを実装する手法を解説します。これにより、ユーザーは認証方法を自由に選択でき、開発者はコストを抑えつつ高いUXを提供できます。

この実装には、ドキュメントにない挙動や落とし穴が多く存在します。本セッションでは、私が検証・解明したFirebase Authの複雑な内部挙動と未公開仕様を紐解き、具体的な解決策をコードと共に提示します。

• 認証解除後も、なぜか認証が成功するケース
• 特定の認証情報更新時に起こる強制ログアウトとその対策
• メールアドレス変更時に、ユーザーに最大3回の認証を強いる挙動の解決

対象聴衆

• Firebase Authentication利用者/検討中のiOS開発者
• セキュリティ強化やUXバランスに悩む方
• 実践的な活用法を求める方

本セッションを通じ、皆さんのアプリに「ユーザー中心」の堅牢な認証システムを自信を持って導入できるようになることを目指します。

iOS 10でSFSpeechRecognizerが登場して9年。
従来の音声認識技術は、短時間音声処理に限られ、サーバー依存による遅延や言語設定の煩雑さなど、本格的なアプリ開発には多くの制約がありました。

iOS 26で登場するSpeechAnalyzerは、その制約を根本から解決する革新的なAPIです。
長時間音声や遠距離録音に対応し、完全オンデバイス処理により瞬時の応答を実現。
リアルタイム転写機能により、ユーザーが話すそばからテキストが表示される魔法のような体験を提供します。

本セッションでは、従来技術の限界を振り返りながら、SpeechAnalyzerの革新ポイントを解説。
非同期処理によりUI操作を妨げない設計、音声の時刻情報を活用した正確なテキスト同期、そして自動モデル管理により開発者の負担を大幅軽減する仕組みなど、実装者が知るべき技術的メリットをお伝えします。
デモでは、絵本読み聞かせアプリを題材に、転写設定・モデル準備・結果処理の3ステップセットアップから、CMTimeRangeを活用した音声再生と同期するテキストハイライト機能まで実演。
Apple Intelligence連携による自動タイトル生成も披露します。
オンデバイス処理により、会議録音は通信環境を気にせず、講義録音は長時間でも安定動作、ライブ配信では遅延なく字幕生成が可能となり、これまで諦めていたアイデアが現実のものとなる開発手法をご紹介します。