トーク

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.）
• 開発体制および組織面におけるチャレンジ

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

SwiftUIといえばViewにModifierをたくさんつけるかと思います。
簡単なViewであれば標準のModifierでもいいのですが、UIにこだわればこだわるほどModifierを付けすぎてごちゃごちゃになります。
標準のModifierの付け方は人それぞれですが、そんなことで議論していては日も暮れてしまいます。
日が暮れる前にシンプルでわかりやすいカスタムModifierを作ってしまい、余計なストレスから解放されましょう。
生成AIに厳密で複雑な標準のModifierのルールを守らせるのではなく、カスタムModifierを使うように指示すれば結構楽に思い通りの実装ができると思います。

このトークでは、単にカスタムしたViewModifierを紹介するのではなく、とても複雑なUIを組んだ時のストレスからの解放についてご紹介させていただく予定です。
また、どの程度の単位でカスタマイズしたModifierを使用すると最適かについてもお話しします。

レイアウト系でカスタマイズすると結構嬉しいことが多いので、複雑なUIを組んでいて、可読性に苦しんでいる方に参考にしていただけると幸いです。

近年、汎用的なLLMエージェントは、自然言語による指示からブラウザ操作までを自律的に行えるようになりつつあります。中でもDevinのようなエージェントは、複雑なUIの解釈やフォーム入力、ページ遷移などを含む一連の操作を一貫して実行できるポテンシャルを持っています。また、ブラウザの操作に限らず、Androidアプリを自律的に操作できるエージェントも増えています。

一方、iOSでは、Appleのセキュリティポリシーによる制約により、iPhoneを完全に自動操作するエージェントはApp Storeの審査でリジェクト対象になります。よって、現時点では一般向けには存在しません。しかし、将来的にiOSアプリがエージェントによって操作される日が訪れるかもしれません。そんな日に備え、エージェントによる自律的なUI操作の実態を分析・解剖して未来を見据えることが重要です。

このLTでは、居酒屋でのモバイルオーダーというタスクに注目し、エージェントとしてのDevinの振る舞いをエスノグラフィー調査を通じて分析した結果を報告します。また、お店のQRコードと参加者の食の好みを入力、モバイルオーダーの注文結果を出力として定義し、幹事としてのDevinの挙動を厳正に評価します。エージェントといえど、飲み会の幹事に忖度はありません！実験は、初回実験（参加者8人）と追試実験（参加者16人）の2回にわたり実施しました。
Devinに胃袋を捧げた参加者とともに、厳正に実施した実験の結果に注目です！

ブラウザ操作ができるようになり自由の翼を得たLLMは、さらなる自由を求め、どこまで突き進むのか。
胃袋の限界が来るまで、進み続けるんだ！
唐揚げが来ても、唐揚げが来た後も。
これは、お前が始めた物語だろ！

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バランスに悩む方
• 実践的な活用法を求める方

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