プロポーザル

ますます勢いを増す日本のiOSアプリ開発者コミュニティ。しかし、そこで生まれるすばらしい知見は、まだまだ日本の中だけに留まっています。
今こそ、自分のトークを日本だけでなく世界中のみなさんに届けてみませんか？

このトークでは、海外登壇を夢見るみなさんのために、カンファレンスの見つけ方から登壇準備、実際に参加した時の様子や海外iOSコミュニティのノリまでギュギュッと5分にまとめてお送りします。
海外登壇にはお金がかかる？いえいえ、旅費を出してくれるカンファレンスも世の中にはあるんですよ！
このLTの直前にもどこかで登壇してきたばかりなので、情報の鮮度はきっとバッチリです。

「海外登壇ってハードル高そう…」と思っているあなたへ。その一歩を踏み出すための全てをお届けします。
海外登壇の流れを広げていくことで、日本から生まれる知が世界中に広がる世の中を一緒に作っていきましょう。

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

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

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

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

対象聴衆

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

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

「長時間の会議や講義を正確に転写できるアプリを作りたい」多くのiOS開発者が抱いてきたこの夢が、iOS 26のSpeechAnalyzerでついに現実となります。
従来のSFSpeechRecognizerは短時間音声処理に限られ、サーバー依存による遅延や複雑な言語設定が開発の障壁となっていました。
これらは技術的制約というより、当時の設計思想によるものでした。

SpeechAnalyzerは、これらの制約を根本から見直した革命的なAPIです。
完全オンデバイス処理により瞬時の応答を実現し、長時間音声にも対応。二段階処理（即座の仮結果と最終確定結果）により、リアルタイムでテキスト化される驚きの体験を提供します。

本セッションでは、従来技術の限界を踏まえながら、モジュール式設計による柔軟性、非同期処理でUI処理を妨げない仕組み、音声時刻情報による正確な同期技術など、SpeechAnalyzerの設計思想を深掘り。
専門用語を実装メリットと共に分かりやすく解説します。

実装デモでは、絵本読み聞かせアプリを題材に、転写設定・モデル確認・結果処理の3ステップから、CMTimeRangeを活用したテキストと音声の完全同期まで段階的に実演。
Apple Intelligence連携による自動要約機能も披露し、従来不可能だった高度な機能実装を具体的にお見せします。

オンデバイス処理により通信制約から解放され、これまで諦めていた音声認識アプリのアイデアが現実のものとなる開発手法をお伝えします。

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

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

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

昨年、私が寄稿したiOSDC Japan 2024のパンフレット記事においてSwift Playgroundsを紹介した際、教育分野での活用の可能性に触れました。 今回のLTでは、その着想を実際に形にした、ZOZOでの「Girls Meet STEM」プログラミング体験イベントの学びを共有します。

イベントでは、AppleのSwift Playgroundsに標準搭載されているレッスンを活用し、中高生がプログラミングの基礎（条件分岐やループなど）を楽しく学べるよう取り組みました。実際に開催してみて、Swift Playgroundsはビジュアルプログラミングからのステップアップに適しており、教える側にとっても扱いやすいツールだと分かりました。LTでは、具体的な事例から見えてきた活用メリットとデメリットについてお話しします。

本イベントで得られた知見が未来のiOSエンジニアを育むきっかけとなり、iOSコミュニティのさらなる発展に繋がればと思います。

SwiftUIを使った機能開発が主流となり、複雑な動作も十分実装することができるようになりました。
iOS16以降ではmodifierが充実しており、大抵の機能はSwiftUIのみで実装可能です。
またWebSocketによる双方向リアルタイム通信もiOS13より標準でサポートされ、以前より導入しやすくなっています。

技術的には「簡単にできそう」に見えたリアルタイムチャット機能の実装でしたが、実際にプロダクションレベルで動くものを作ると想像以上に複雑でした。

このLTでは、実装過程で遭遇した「チャットUIのスクロール位置制御の困難さ」と「WebSocket通信のエラーハンドリングの複雑さ」について、実際のコード例を交えて紹介します。

SwiftUIでチャット機能を実装予定の方や、WebSocketを使ったリアルタイム通信を検討中の方に実践的な知見をお届けします。

WWDC25 で公開された Foundation Models framework により、ついに iOS 公式のオンデバイス LLM へ直接アクセスできる時代が到来しました 。
本セッションでは Apple​純正モデル（Apple Intelligence 3B）と、MLX-Swift／MLC-LLM／llama.cpp など OSS ベースの手段を横並びで比較し、iPhone 16 Pro 相当の端末で “どこまで動くか・どう組み込むか” を具体的に解説します。

「オフライン AI チャット」「リアルタイム文章要約」「リアルタイム文章校正」 を ひとつの SwiftUI アプリに統合しながら、３つのオンデバイス LLM を 同じプロンプト・同じ iPhone でベンチマークします。

比較軸は下記 5 点です。

1. 導入工数とビルド手順（Swift Package／Core ML 変換／モデル配布方法）
2. モデルサイズ／RAM 使用量
3. 推論レイテンシ
4. バッテリー消費
5. ライセンスと運用

Apple Intelligence 3B がもたらす省電力性と高レベル API の手軽さ、
llama.cpp-Swift の自由度と暗黙の落とし穴、
MLC-LLM の柔軟性と量子化チューニングの難しさ――
それぞれを可視化し、実装方法も併せて紹介します。

オフラインでも瞬時に動き、個人情報をクラウドへ送らず、運用コストを抑えられる オンデバイス LLM は iOS アプリの新たな武器になりつつあります。

本セッションを通じて、より実用的なオンデバイス LLM を活用した iOS アプリ開発 のイメージを掴めます。具体的なユースケースと実装手順を知ることで、新規アプリの着想や既存アプリ進化のきっかけとなることを目指します。

我が家には2歳の猫がいます。とても可愛く、ときに予測不能で愛くるしい動きをします。そんな一瞬を撮影するのは至難の業ですが、DockKitがこれを可能にします。

DockKitは、iPhoneカメラとDockKit対応デバイスを連携させて被写体を自動追尾するAppleのフレームワークです。WWDC 2023で発表され、昨年対応デバイスが発売されました。iPhone標準搭載のカメラアプリもDockKitに対応しており、DockKit対応デバイスとiPhoneを連携することで人物を自動で検出しトラッキングすることが可能ですが、標準では人物のみに限定されます。

しかし、DockKitには豊富なAPIがあり、Vision frameworkとの相性も抜群です。VNRecognizeAnimalsRequestで猫を識別し、Core MLと連携することで、人物以外の高精度なトラッキングが実現できます！

本セッションでは、Vision frameworkで猫の特徴を捉え、DockKitと連携させる具体的な実装方法と、DockKitをより高度に使いこなすテクニックについて解説します。デモでは我が家の猫が出演する動作映像をお見せし、iOSDC史上最高の癒しも提供予定です。

本セッションを通じて、これらのフレームワークをみなさんのアプリ開発や身近な課題の解決にも活かせるようになるかもしれません。

近年のSwift言語やXcodeの進化に伴い、従来のXCTestに代わるモダンなテストフレームワーク「Swift Testing」が注目されています。本セッションでは、ココナラiOSチームが実際にXCTestからSwift Testingへ移行した事例をもとに、導入の背景や具体的な手法をご紹介します。

まず、なぜ移行を決断したのか。急速に機能が増える中で、XCTestでは「テストが仕様書として機能しない」「分岐の多いテストはボイラープレートが増える」「テストケースに依存したセットアップが煩雑化」などの課題が浮き彫りにしたいと思います。

特にViewModelのテストにおいては、BDD（Given‑When‑Then）スタイルで記述できる点が大きな魅力です。

続いて、Swift Testingの特徴とメリットについて。マクロベースで直感的な構文や、型安全かつ並列実行対応、パラメタライズテストやtrait機能（OSや時間帯によってテストを制御）など、XCTestよりも柔軟で表現力豊かなテストが可能になります

ココナラでの具体的な移行ポイントは以下の4つ
setUp()に頼らず、各テスト内でViewModelやMockを初期化
@Suiteを使って条件ごとにネスト構造を整理
@Testやメソッド名を日本語で書き、仕様の可読性を重視
複数分岐のテストは@Suite内の独立した@Testで構造化

そして、パラメタライズテストにも対応可能ですが、ViewModelのようにロジックが複雑なケースでは適切でない場合もあるため、要件に応じて使い分けています。

最後に、実際のコード例（XCTest→Swift Testing両対応）や、BDDコードが「仕様書としても読める」利点をお見せしつつ、フレームワーク選定・チーム規約への組み込みなど実務ベースでの導入ノウハウを共有します

エッジAIとは、iPhoneなどの端末上で直接動作するAI技術のことで、プライバシー保護やネットワーク帯域の節約など、さまざまな観点から注目を集めています。近年ではエッジデバイスの高性能化により、その存在感がますます高まっています。

しかし、実際にアプリにAIを組み込もうと思うと、さまざまな「迷いポイント」に直面します。
私自身、個人開発アプリにAIを導入する際に、

• 本当にエッジAIを使うべき？
• Apple純正からサードパーティ製まで多くのAPI・ツールの中で、どれを選べばいい？
• モデルやデータセットのライセンスは大丈夫？

といった疑問に悩み、何度も手が止まりました。

このLTでは、そんな試行錯誤の中で得た「迷いポイントの全体像」をベースに、iOSエッジAI導入の判断プロセスをフローチャート形式でサクサク整理していきます。
iOSアプリにAIを組み込みたいが、何から始めればいいか分からない──そんな開発者に向け、Apple公式資料だけではカバーされない導入判断フェーズの実践知を凝縮し、5分間でスッキリ理解できる判断軸をお届けします。

Swift 6.1から、引数の末尾に , （カンマ）を付けられるようになりました。

func foo(
    a: String,
    b: String, // !!!: カンマを付けてもビルドが通る
) {
}

みなさんはこちらの新機能をご存知でしたか？

このようにSwift 6.1と6.2の主な新機能を5分でサクッと紹介します。

サクッと理解したあとは、公式ドキュメントを読んで正しく理解を深めてくれよな！

本セッションでは、Swift-DocCとAI agentの活用によって、ドキュメントを設計・実装・運用の全プロセスの中心に据え、より柔軟で再現性の高い開発体験を実現する“ドキュメント駆動開発”のアプローチを共有します。

これまでドキュメントは、実装の後に作成される補足資料や説明書として捉えられることが多く、設計意図や仕様の認識ズレ、保守コストの増加など、さまざまな課題がありました。しかし、Swift-DocCの普及により、ソースコードと設計情報が密接に結びつき、チーム全体で設計や仕様を共通言語として扱える基盤が生まれています。さらにAI agentの登場によって、DocCを起点とした情報が実装・テスト・レビュー・運用まで幅広く自動化・補完される時代が始まっています。

このセッションでは、

• DocCによる設計・仕様の明文化
• 仕様整理・設計段階でDocCを作成（ドライバー部分は人間、実装はAI）
• AI agentによるコードやテスト、ドキュメント自動生成・補完
• CI/CDやプレビュー環境による継続的な品質維持と自動チェック

という“ドキュメント中心”のワークフローが、どのように現場を変えるかを解説します。

ドキュメントは従来、「保守やリリース直前になってようやく整備される存在」となってしまうことが少なくありませんでした。

これからは、ドキュメントを「設計・実装・運用すべてをつなぐ開発の核」として活用するための実践的な視点を、iOSエンジニアの皆さんと共有したいと考えています。

Webブラウザ操作の自動化ツール代表的なものの一つとしてSeleniumが挙げられます。
SeleniumはJava、JavaScript、Python、Ruby、.NET、Rustといった言語をサポートしており、高い汎用性を誇ります。
しかし、何かが足りません。そう、Swiftです。

本トークではSeleniumとそれが動かすWebDriverの仕組みについて解説し、SwiftでWebDriverを動かしてブラウザ操作を実現することを目指します。

Swiftでもブラウザ自動化の可能性を切り拓いていきましょう。

iOSは言語やフレームワークの進化が早く、技術的負債が溜まりやすい領域です。私が携わっている大規模サービスは約10年にわたり運用が続いており、その中で技術の進化に合わせて複数のアーキテクチャが共存しています。各アーキテクチャに適したライブラリやツールが導入されてきたことで、プロジェクト全体の構成が複雑化し、技術の全体像を把握するのが難しくなっていました。

こうした状況では、新しい技術の導入判断が難しく、技術選定が特定のメンバーの知見に依存してしまうことや、オンボーディング時の使用技術のキャッチアップに時間がかかるなど、複数の課題が浮き彫りになります。これらを解決するため、チームではThoughtWorksが提唱する「Technology Radar」を導入しています。

Technology Radarは、技術の採用や評価を4段階（Adopt / Trial / Assess / Hold）に分類し、意思決定を支援するフレームワークです。私たちはこのモデルをiOS開発に合わせてカスタマイズし、チームメンバー間でディスカッションを行い、現在プロジェクトに導入されている技術を網羅的に分類し可視化しています。

この取り組みにより、技術選定に一貫性が生まれ、レビューや設計の議論でも各技術の扱いが明確な前提のもとで議論できるようになりました。チーム内で“技術の地図”の共通認識があることで、意思決定のスピードと納得感が大きく向上したと感じています。

このトークでは、Technology Radarの基本的な概念から、iOS開発に合わせてカスタマイズしたフレームワーク、そしてチーム内での運用方法を紹介します。

Swiftの勉強を始めたばかりの頃は、自分のアイデアをアプリとして形にすること自体がとても楽しく感じられました。 しかし、学習や開発を重ねるうちに、エンジニアにとって重要なのは単なる実装に留まらず、いかに効率的かつ安全に実装できるかであるという考えを持つようになりました。

その中で「クラスと構造体を使い分ける際、メモリの観点ではどのような違いがあるのだろう？」という疑問が生まれ、やがてそれはより根本的なメモリ構造、つまりハードウェアレベルでのメモリの仕組みへの関心へと広がっていきました。 メモリにはコード領域・データ領域・ヒープ領域・スタック領域があり、それぞれの役割について図解しながら調べて学習を進めました。

この学習を通して、COW（Copy-On-Write）構造、クラスと構造体の選定基準、ARCやクロージャのキャプチャの仕組みなど、これまで何となく知っていたけれどうまく説明できなかった概念を、より明確に理解し、自分の言葉で説明できるようになりました。 今回のルーキーセッションでは、こうした学びと気づきを皆さんに共有したいと思います。

トーク内容

• コード・データ・ヒープ・スタックに関する概念の解説と図解
• クラス vs 構造体、値型 vs 参照型 ― 実際のメモリ使用の違いと選定基準
• Swiftにおける自動メモリ管理（ARC）とメモリリーク、クロージャのキャプチャ問題

サブスクリプションの価格変更は一大イベントですが、頻繁に実施するものでもないためその手順についての情報は多くありません。
本LTでは実際に価格変更を実施した経験に基づき、見落としがちな罠や、Tipsについてご紹介します。

・ 申請手順と必要な確認事項
・ 新規 / 継続ユーザーへの価格変更の反映タイムライン
・ サマータイムの罠
・ 価格の変更時刻を厳密にコントロールするTips

価格変更の際にはこれを思い出せば大丈夫！という内容をお届けします。

我々が作る iOS アプリと OS や他アプリの連携を実現するために App extensions という仕組みが Apple から提供されています
ですが多くのサービスでは iOS アプリと同時に Android アプリを提供しているケースが多く、アプリ内の UI 一つとっても「これはAndroid はどうやったら提供できるだろう？」という疑問を持つことも多いでしょう
App extensions を使った機能を提供する際も Android で似た機能はないのか、サービスとして OS が違ったとしても統一性のある UX を提供出来るかどうかを考えることになるでしょう
勿論似た機能が提供されていることも多く、例えば Siri との連携を提供する Intents に対し Android には Google アシスタント連携を提供する App Actions が存在します

そこで今回は iOS で提供できる AppExtension を振り返りつつ、 併せて Android においてそれと近しい機能がないか、どのような違いがあるのかについて話そうと思います
中でも特に Intents など AI アシスタント絡みで直近の注目度が高そうなもの、 Widget など iOS では比較的新し目だが Android では昔からあったものに着目して行こうと思います
Widget の更新思想一つとっても、明確に時間間隔が指定可能な Android と、バジェットで管理されるため厳密には指定不可能な iOS という違いがあり、出来る出来ないの差分がありえます
この「差分」を理解することこそが、両プラットフォームで一貫したUXを提供するための鍵となります

このトークを通じて、単なる機能比較に留まらないサービス全体の価値を最大化するための OS 横断的な設計についてお話できればと思います

▼ 概要
私たちは「あたらしい旅行を、デザインする。」をミッションに旅行アプリ「NEWT」を日々開発しています。
NEWTはリリースから3年が経ちました。今回は海外旅行に必ず必要な「航空券」に着目してみます。
国内外問わず移動手段として考えられる飛行機移動ですが、チケット忘れやデジタルチケットを当日にサイトにアクセスして焦ったりしたご経験はないでしょうか？
そんな中で航空券データをPassKitを用いてWalletに追加することでより一層トラブル回避の手段とできるのではないかと考えました。
また、航空券だけでなくPassKitをうまく利用することでさまざまな種別のカードやチケットをWalletに追加することができるので他の種別についても併せてご紹介します。

▼ 内容

• PassKitってなに？どんな種類があるの？
• 航空券を扱う場合に実装する内容
  • 証明書設定からpass.jsonの設定について
  • 実際に動かしてみた内容について
  • NFCを付加できる条件
• 実際に開発・運用する/しないを決める時の意思決定について

スマートフォンの性能向上により、AIをクラウドではなく端末上で実行するエッジAIの重要性が高まっています。iOSでは、Core MLを中心にオンデバイス機械学習のための強力なエコシステムが整備されていますが、実際に導入しようとすると、思わぬ壁や選択の難しさに直面することも少なくありません。

私自身、自作アプリにAIを導入しようとしたときにも、

• 既存のAPIや提供モデルによる目的達成の可否の見極め
• Python製モデルの変換や最適化における、サードパーティ製含むツール選定と運用の難しさ
• ライセンスや配布制限のような非技術的制約

といった多くの課題にぶつかり、Apple公式資料だけではカバーしきれない範囲の大きさを実感しました。

本セッションでは、このような試行錯誤や失敗経験を交えながら、以下のトピックについて実践的に解説します：

• AIおよびエッジAIの基本概念と進化の歴史
• iOSにおけるAI基盤技術・Core MLの役割と仕組み
• VisionやNatural LanguageなどのApple純正フレームワーク
• Create MLやcoremltoolsなど、Core MLを支える周辺ツール
• ExecuTorchやLiteRTといったサードパーティ製推論ツール
• ライセンスや配布制限など、非技術的な落とし穴

WWDC25では、Apple Intelligenceの強化や新しいFoundation Modelsフレームワークが発表され、iOS上でのエッジAI活用は新たなフェーズに突入しました。このセッションを通じて、エッジAI技術への理解を深めるとともに、「AIを使う側」から「AIを統合する側」へと進むための実践的な知識と視点をお届けします。

音声配信アプリのE2E自動テストでは、UIだけでは判断しづらい“聴く体験”をどう守るかという、他のアプリとは一味違った難しさがあります。
・音声が再生されていることを確認する方法
・今月の放送を指定する方法

音声配信アプリにおいて、リスナーに「聴く体験」を提供し続けるためには、どのようにテストを行うべきでしょうか？

本セッションでは、ノーコードでE2Eテストを実装できるMagicPodを用いて、音声再生の検証や動的なコンテンツ選択に取り組んだ事例をご紹介します。

再生ボタンの状態変化から“音が出たこと”を間接的に確認する方法や、「今月の放送」のように固定文言やIDに頼れない場面での要素特定の工夫など、音声配信アプリならではの課題とその突破法をお話しします。

このセッションを通して、以下のことを学ぶことができます。
・音声配信アプリにおけるE2E自動テストの特有の課題
・MagicPodの強みとその実践的な利用法
・MagicPodの限界とそれを補完する方法