トーク

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

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

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

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

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

弊社のプロダクト開発中に遭遇した、予想を超える怖いバグの実例をご紹介します。
このバグは、機器からBLE（Bluetooth Low Energy）で取得したデータをテーブルビューに反映させる際に発生しました。
正常に動作していると思っていたのに、なぜか意図しない場所のデータが変更されてしまいます。

この不具合の真相は何だったのでしょうか。私たちはどのようにしてこの問題に立ち向かったのでしょうか。
バグの発見、原因の特定、そして解決に至るまでの一連の流れを、具体的なエピソードを交えてお話しします。

このセッションでは、普段あまり遭遇しないような不具合に対する対処法や、問題解決のための新たな視点を得ることができるかもしれません。開発者やエンジニアの方々には、まさかのときに役立つ知識をお持ち帰りいただける内容となっています。ぜひご参加ください。

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

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

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

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

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

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

Git で xcodeprojが衝突して深夜に泣いたこと、ありませんか？
私は、大学サークルで2週間〜2か月スプリントのvisionOS / iOSアプリ開発を続ける中、毎回「xcodeproj のコンフリクト → 作業停止」に悩まされてきました。

そんな状況を打破するべく、0→1のチーム開発でコンフリクトを最小限に抑えるプロジェクト構成を模索しました。その結果、SPMローカルパッケージ＋xcconfigでxcodeprojの衝突を0件にできた構成にたどり着きました。

本LTでは、具体例を交えながらこの構成とノウハウを紹介します。

LTで話すこと：

・なぜxcodeprojは衝突するのか？
・衝突が起きない SwiftPM 分割パターン:
1Package ＋ multi-target戦略 と 1 Workspace ＋ 複数Package戦略
・xcconfig で実機ビルドOK＆差分を撲滅！

SkyWay SDK開発においてWebSocketライブラリを切り替えた実践について説明する。

背景:
これまで、WebSocketの実装にはサードパーティライブラリであるSocketRocketを使用していた。しかし、依存ライブラリを削減し、バイナリサイズを縮小するために、新しいライブラリへの移行を決定した。

具体的な作業:
移行にあたって、iOS 13以降で利用可能なURLSessionを使用することにした。しかし、SkyWayではiOS 12を最低保証バージョンとしていたため、まず最低保証バージョンを引き上げる必要があった。調査の結果、技術サイドではiOS 14または15への引き上げを検討し、最終的にiOS 14に引き上げることでビジネスサイドと合意した。
開発作業として:
切り替え手順:
テストコードが以前と同様のパフォーマンスを維持し、複数回の実行に耐えうることを確認しつつ、置き換え作業を進めた。次に結合テストを同様の要件で実行し、問題がないことを確認した。過去のプルリクエストを収集し、チェックリスト化することで、過去に発生した問題が再発しないことを確認した。最後にコードをリファクタリングして作業を完了した。
苦労した点:
イベントハンドラと使用しているWebSocketの機能を満たすために、独自の工夫を加える必要があった。

切り替えの効果:
SocketRocketの使用による手間が削減され、さらに1MB程度のバイナリサイズ削減を達成した。

JetbrainsのAppCodeが販売終了した年の2022年4月に私はAndroidエンジニアからiOSエンジニアになりました。
使い慣れたJetbrains製のIDEへ恋い焦がれつつも、わたしは、かの有名な IDE に慣れ親しんでいきました...。

それから3年の時が経った。
ときは2025年某日、Android StudioのKotlin Multiplatform向けプラグイン “Kotlin Multiplatform IDE plugin” がiOS開発を強力にサポート！遂にわたしが恋い焦がれた状況が結実。

待ち望んだ状況を迎え、Kotlinの存在しない、Pure SwiftのiOSアプリ開発環境をAndroid Studioで構築し、快適に開発することができるのか！？あの有名なIDEとの関係性はどうなってしまうのか。

いまAndroid StudioでiOS開発するための最短ステップを5分でお届けします。

ウワサの次期OS「iOS26」が話題の今、未来のデザインに胸を躍らせる今だからこそ、僕たちが毎日触れてきたiOSのUIデザインの歴史をタイムスリップしてみませんか？最新のデザインを深く理解するためのヒントは、そのルーツにこそ隠されているはずです！

このトークではまず、多くの開発者の記憶に刻まれているであろうiOS 6までの「スキューモーフィズム」の世界へご案内します。緑のフェルトが敷かれたGame Center、革の表紙がめくれるiBooks。なぜあの頃のUIは、現実世界の質感を忠実に再現しようとしていたのでしょうか？？

次に、世界に衝撃を与えたiOS 7の「フラットデザイン」への大転換を振り返っていきます！
アイコンから光沢が消え、UI全体がミニマルになったあの瞬間。
開発者たちが熱狂し、あるいは困惑したデザイン思想の変化を探っていきます！

そして、単なるフラットデザインに留まらず、すりガラスのような半透明のブラー表現、ウィジェットやLive Activitiesによる新たな情報提示、物理法則を感じさせるアニメーションなど、リッチでインタラクティブに進化した現在のデザインへと旅を続けます。

ベテランの方には懐かしさを、若手の方には新鮮な発見を。
スクリーンショット満載でUIの"エモさ"の変遷を辿り、未来のデザインを考えるきっかけを持ち帰っていただける、そんなLTです！

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 に基づく効率的なレンダリングパイプラインの構築方法

WWDC25でAppleは「Liquid Glass」という新しいデザインを発表しました。
Appleプラットフォームにおいて、デザインの更新はiOS 8のフラットデザイン以来なので12年振りです。

Liquid Glassは、液体（Liquid）の流動感とガラス（Glass）の光学特性を兼ね備えた新しい素材です。

ガラスのように美しいタブバー…
スクロールすると後ろのビューが透けて見え、ガラスの中に液体が入っているようなブラーがかかる…
コンテンツを邪魔しない、透明感のあるデザイン…

よ過ぎか？？

もう一度言います。

よ過ぎか？？？？？？

WWDC25をリアルタイムで視聴していたワイ、深夜テンションもあってブチ上がるの巻。

さすがにエグい。

スキューモフィズム（Aqua）やフラットデザインのよさも残していると感じ、まさに新時代のデザインです。

ガチでこれからのiOSアプリ開発モチベが爆上がりました。

こんなカッコいいデザイン、みんなで眺めてニヤニヤするしかないよなぁ？？

●もくじ
・Liquid Glassの特徴
・iOS 26における純正アプリのデザインをみんなで眺める
・Liquid Glass対応した個人アプリ紹介

「また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ロジックの単体テスト手法

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

UIKitとAppKitの中でも飛び抜けて複雑なViewであるテキストビューにはユーザーが標準で使える機能が数多く存在します。
本トークではそれらの機能を一望し、開発者がそうした標準機能を制御する方法や、また制御することでユーザーに提供できる機能についても紹介します。 例えばコピー・カット・ペースト、翻訳機能といった一般的な機能から、テキストをダブルタップ / ダブルクリックで選択したとき単語が選択されるのは何故なのかといった細かな挙動まで。 さらに、それらはUIKitやAppKitの公開クラスとして利用できたりもします。
UITextView / NSTextViewについて隅々まで知ることで、ユーザーとして日々のiOS / macOS上のテキスト入力が少し便利になったり、アプリ開発者としてちょっとしたユーザー体験の改善ができるようになります。

• テキストビューとは何か
• UITextViewで暗黙的に利用できる機能たち
• NSTextViewで暗黙的に利用できる機能たち
• コンテキストメニュー
• UIKitとAppKitのclassの対応関係（UITextChecker / NSSpellCheckerなど）
• UITextViewにおけるUIInteractionの重要性とテキスト選択
• NSTextView (macOS) と縦書き
• TextKit 2と縦書き
• UITextInput / NSTextInputClientについて
• Writing Toolsの登場、そして26へ

ますます勢いを増す日本の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を使ったリアルタイム通信を検討中の方に実践的な知見をお届けします。