トーク

去年の私は、「@Environment(.keyPath)実践入門」というパンフレット記事を書きました。8ページにも及ぶボリュームでしたが、おかげさまで非常に好評をいただき、今年はその続編として、「@Environment(.keyPath)をフル活用したアーキテクチャ作り」のパンフレット記事を執筆する運びになりました。

しかし私の@Environment(.keyPath)への愛は、やはり文字だけでは伝えきれず、私が実際にどのように書いてきたか、この仕組みによってどんなメリットが得られるのか、そして思わぬ落とし穴！？まで、私がここ2年近く@Environment(.keyPath)と付き合ってきて得た全ての知見を、皆さんに共有したいと思います！

この発表は以下の内容を含める予定です：

• @Environment(.keyPath)とはどんなものか、一般的なDIや、@Environment(Object.self)とどう違うか
• @Environment（.keyPath)の基礎的な使い方
• カスタムな@Environment(.keyPath)の作り方
• @Environment(.keyPath)のちょっと高度な使い方
• @Environment(.keyPath)の特殊な値注入の仕方
• @Environment(.keyPath)の意外な落とし穴
• @Environment(.keyPath)をフル活用したアーキテクチャの作り方
  などなど！

この発表は、SwiftUIの初心者から上級者まで楽しんでいただける内容に仕上げる予定です。そしてこの発表を聞いて、一人でも@Environment(.keyPath)に興味を持ち、開発で今まで以上に活用してみてくれた方が増えたら、私にとってこれ以上に嬉しいことはないでしょう！

visionOS 26 で発表された「Apple Projected Media Profile（APMP）」 は、MP4／MOV ファイルに拡張メタデータを付与し、180°・360°映像を標準映像と同じ操作感で扱えるようにする新しい仕組みです。

高価な専用カメラが必要な「Apple Immersive Video」とは異なり、APMP ならGoProやInsta360など、個人でも手軽に入手できるカメラで撮影した映像を、そのまま Vision Pro の没入空間で再生できます。

本講演では、APMP の基本構造から具体的な変換手順までを次のトピックで解説します。

• APMP と Apple Immersive Video の違い
• APMP が扱える映像フォーマットの種類
• QuickTime コンテナ内「vexu」ボックスの仕組み
• Comfort Mitigation（VR 酔い対策）の仕組み
• 標準映像をAPMP対応ファイルへ変換する方法

更に、 APMP映像はSafari／WebKitベースのブラウザでも再生可能です。
Apple Vision ProのSafariではAPMP映像がどのように没入表示へ切り替わるのか、デモ動画を交えて紹介します。

最後に、個人開発している visionOS 2向け 360°動画アプリをAPMP対応へ移行した際に、どのような修正が必要だったのかを、差分ソースコードを示しながら詳しく解説します。

Swift Testing は Swift 言語でユニットテストを行うためのフレームワークです。昨年リリースの Swift 6 に組み込まれました。本トークでは、既存プロジェクトに Swift Testing を導入し、実践的に活用していく方法を説明します。

Swift Testing は従来のテストフレームワークである XCTest と共存できるため、既存プロジェクトへの導入がしやすくなっています。新しくユニットテストを追加するタイミングが、最も Swift Testing を導入しやすい機会でしょう。あるいは、既存のユニットテストを Swift Testing で書き換えるのも難しくはありません。

しかし、XCTest と Swift Testing とでは挙動が異なる場合もあるので注意が必要です。例えば、Swift Testing ではデフォルトでテスト実行が並列処理となるため、単純な移行ではテストが失敗することもあります。また、非同期処理のテストにも考慮すべき点があります。これらの課題に対し、どのような注意が必要で、どう対処すれば良いかを具体的なコード例とともに解説します。

さらに、Swift Testing の特徴的な機能であるパラメトライズテストの導入方法と、それによって得られるメリットについても実例を交えて紹介します。効果的に活用することで、既存のテストコードを整理し、より保守性の高い形に進化させることができます。

本トークを通じて、Swift 6 時代のモダンなテスト手法を身につけ、iOS アプリ開発の品質と開発効率の向上につなげましょう。

「APIの開発が遅れていてアプリの開発が進めづらい…」

「このエッジケースの動作確認、どうやって確認しよう？」

「バグが検出されたけど、再現が難しい…」

多くのモバイルアプリ開発現場が、このような課題を抱えているのではないでしょうか。

これはエンジニアの開発作業だけにとどまらず、PdM やデザイナー、QAメンバーにとっても悩みの種となっていました。
アプリの最新仕様の動作確認がスムーズに行えないことで、仕様検討に時間がかかったり、デザイン作成やテスト設計において考慮漏れが発生したりすることがあります。

こういった問題により、職種間のコミュニケーションコストに悩まされ、結果として開発全体のリードタイム増大に繋がっていました。

この根深い課題を解決すべく、iOS / Android アプリで共通の仕組みで利用できる Mock 環境「Hobart」を開発しました。

「Hobart」はエンジニアだけでなく、PdM・デザイナー・QAメンバーなど他職種の方々の業務効率の向上に寄与しています。

下記を中心に、モバイルアプリ開発全体を支える Mock 環境についてお話します。

• モバイルアプリ開発における開発効率低下の要因
• 「Hobart」の仕組みとそれを支えるデバッグモードの全貌
• 生成AIを活用した Mock データ整備の高速化
• 「Hobart」導入後の成果と今後の展望

WWDC 2025においてSwift製のContainerization Frameworkがオープンソースで公開され、主にバックエンドエンジニアの間で注目を集めました。
このセッションでは、普段Swiftを書くマジョリティであるネイティブアプリのエンジニアと、コンテナをよく知るけどSwiftはまだ勉強中の僕が交わる交差点として、Swiftで書かれたContainerization Frameworkの実装を深掘りします。
参加される皆さんがコンテナ技術やフレームワークの設計思想を理解することで、単にコンテナを立ち上げたり動かしたりするだけでなく、フレームワークを活かしたツールの制作などができるようになるかもしれません。
また、フレームワークの裏側で使われる幾つかのOSに近い部分や基礎技術要素についても触れることで、これまでのツールとの違いについても解説します。

「一つのコードベースから、複数の異なるアプリを自動生成する」
そんな仕組みが、本当に現実的に運用できるのか？

本セッションでは、ブランドや機能構成が異なる複数のアプリを、単一のSwiftコードベースから自動生成・リリースする仕組みを、設計から実装・運用まで具体的に解説します。

これは単なるテンプレート共有ではなく、iOSアプリを「構成可能なプロダクト」として再設計し、設定情報をコードの外に追い出し、非エンジニアも含めた運用を可能にする仕組みを作る取り組みです。

このセッションでは、以下の実践知を共有します：

・アプリを「構成」として捉える：コードの中に潜む「差分」をどう抽出し、再設計するか
・XcodeGenとFastlaneによる“生成”の自動化：プロジェクト構造の動的生成とビルド・署名の統合
・設定情報をコード外部に逃がす：API経由で注入するApp Metadataとそのセキュリティの考慮
・エンジニア以外でも使えるUI設計：管理画面を介したノーコードな運用ワークフロー
・プロダクトとしての“スケーラビリティ”：技術的負債を生まないための運用と設計戦略

アプリを“作る”という行為を、どうやって“仕組み化”に昇華させたのか。そのプロセスと工夫を、実践ベースでお話しします。

コードレビューは、チーム開発における品質担保と知見共有のために不可欠なプロセスです。しかし、「何を指摘すべきかわからない」「観点が人によってバラバラ」「レビューに時間がかかりすぎる」といった悩みは、多くのチームが抱える共通の課題ではないでしょうか。

本セッションでは、iOS開発の現場で実際に起きやすいコードレビューのつまずきやすいポイントを整理し、具体的なコードをもとに「どのような観点でコードを見ればよいのか」を実践的に学びます。たとえば、ViewとModelの関心の分離、命名、非同期処理での注意点、コードスタイルの一貫性、パフォーマンスやセキュリティに関する観点などの多角的な視点を紹介します。

また、「良いレビューコメントとは？」「手戻りを防ぐにはどうすればいいか？」といった、設計やコミュニケーションにも関わる問題についても触れ、レビューの“質”を高めるためのノウハウを提供します。

さらに後半では、効率的なレビューを支援する手段として、AIを活用したコードレビューの手法についても紹介します。GitHub CopilotなどのAIレビュー支援ツールを用いることで、開発者はより本質的な設計や意図の確認に集中する「人とAIの協調によるレビュー」の可能性についても紹介します。

このセッションを通じて、コードレビューの観点を整理し、チーム全体でレビューの質と効率を高めるための実践的なアプローチを学べます。このセッションが、明日からのコードレビューを飛躍させるヒントになるはずです。

セッション内容（予定）

• なぜコードレビューはうまくいかないのか
• コードレビューの7つの観点
• コードレビューでのコミュニケーション
• コードレビュー実践ワークショップ
• 技術育成のためのコードレビュー
• チームで更なる生産性を高める
• 生成AIを用いたコードレビューの最適化

本トークでは、iOS SDK を Swift Package Manager（SPM）+ XCFramework によって構成・配布する設計と、その実運用で得た知見を紹介します。

実際に筆者が提供する SDKを題材に、次の観点から掘り下げます：

• 複数モジュール構成（Core / App / Tracking など）の分離と依存関係の整理
• ライブラリの再利用性を高めるためのディレクトリ構成と Swift Package の切り方
• XCFramework による iOS / Simulator 対応
• BuildTools モジュールを使った SwiftLint / SwiftFormat の一括適用
• 内部で持つUIライブラリにおけるアセット管理のはまりどころ
• 「使う側」にとって安全・簡単に導入できる Package の設計原則

「SDK を作る」こと自体が目的ではなく、「チームで再利用できて、組織として持続可能な仕組みを作る」ことがテーマです。

ライブラリ開発初心者はもちろん、「現場で自作 SDK のメンテ地獄に陥ったことがある人」や「SPM の限界を見極めたい人」にとって、ヒント満載の内容となっています。

SwiftUIでのUI構築において、GeometryReaderとScrollViewは画面サイズや位置情報を活用した柔軟なレイアウト制御に不可欠なコンポーネントです。しかし「思ったように動かない」「SafeAreaやネスト構造でレイアウトが崩れる」といった課題に直面する開発者も多いのが現状です。

本セッションでは、これらのコンポーネントの動作原理を基礎から丁寧に解説し、実務で遭遇する典型的な問題とその解決策を具体的なコード例とともに紹介します。特に、GeometryReaderの座標系の理解、ScrollViewのオフセット制御、パフォーマンス最適化の観点から、正しい使い方と避けるべきアンチパターンを明確化します。

さらに、PreferenceKeyやAnchorPreferenceなどの代替技術との使い分け、実際のプロダクトで活用できる応用パターン（カスタムスクロールエフェクト、動的レイアウト調整など）も解説し、SwiftUIらしい宣言的UI設計のベストプラクティスをお伝えします。

初学者のつまずきポイント解消から、中級者以上の設計力向上まで、幅広いレベルの開発者にとって実践的な知見を提供し、日々の開発業務で即座に活用できる内容を目指します。

WWDC 2025で待望のSwiftUI向けWebKitが発表され、SwiftUIでWebViewを扱いやすくなりました。
WKWebViewには多くのプロパティやView操作のメソッドがあるため、宣言的UIに適合させるのは容易ではありませんでした。
例えば進む/戻るボタンの表示制御や、ナビゲーションの動作にはWKWebViewへのアクセスが必要です。

SwiftUI向けWebKitでは、WKWebViewを持つWebPageクラスをStateとして扱うことで、WebViewをStateの写像として宣言的に記述できるように設計されています。

一方、私たちはこれまでWKWebViewを宣言的に扱うためのライブラリとして、cybozu/WebUIを設計・公開してきました。
WebUIではproxy APIを通じてSwiftUIからWKWebViewにアクセスできるよう設計しています。

本トークでは、WKWebViewの宣言的UIへの適合を例として今後のSwiftUIに最適なインターフェース設計の指針を提供します。
SwiftUI向けWebKitとWebUIの設計を比較して、よりSwiftUIらしい宣言的なインターフェース設計を掘り下げます。
また、ObservationとObservableObjectの変更監視の機能差から、「なぜ今SwiftUI向けWebKitが登場したのか」についても考察し、これからのインターフェース設計に必要な技術要素にも言及します。

本トークを通じてこれからのSwiftUIインターフェース設計指針と技術的背景について学びます。

対象者

• 宣言的UIの設計原則を深く知りたい開発者
• UIKit ViewのSwiftUIラッパー提供者
• SwiftUIで複雑な状態を扱うView設計者

話さないこと

• 今後のWebUIの開発方針

LLMエージェントによるコーディングが民主化されたことで、プログラミングに新しい時代が到来しました。"Vibe Coding" という言葉が生まれ、多くの人が数行のプロンプトだけで実際に動作するアプリやWebサイトができあがってしまうのを体験しています。

その中で、こう思われた方もいるでしょう。「で、これを仕事で真面目に使うにはどうしたらいいんだ？」と。

詳細はお任せでゼロから適当に作らせればいい個人の遊びとは違い、業務としてのプロダクト開発には例えば以下のような制約やルールがあります。

• 機能要件が予め詳細に決まっている
• デザイン資料の通りにUIを実装する必要がある
• コーディングルールがある
• gitのブランチ運用など開発フローに関する決まりごとがある

本セッションでは、Anthropic社が提供するClaude Codeを実際にiOSアプリの開発業務で活用し、その中で得られた実践的なノウハウをお話します。

• Webアプリを作るのとは違う、iOSアプリ開発ならではの難しさに立ち向かう
• コンテキストが長くなることによる性能低下を防ぐために適度に記憶をリフレッシュする
• 要件定義と実装の工程を分けることで並列に進められるようにする
• AIエージェントをチームの一員として迎え入れるための準備
• プロンプトで指示しても無視することがあるのを、ToDoリスト機能で確実に実行させるようにする

このセッションで、業務にClaude Codeを組み込む際のコツを知っていただき、LLM時代のiOSアプリ開発者としての姿勢について考えるきっかけとなれば幸いです。

モーダルはiOSアプリで情報表示、注意喚起また選択肢の提案などユーザーへの表示としてよく使われます。
皆さんも一度は設定したことがあるでしょう。

他のプラットフォームのWebやAndroidに目を向けてもさまざまなサービスで多様な形で導入されており、
モーダルという言葉だけで画面の一部または全面にユーザーへの情報の提示がされることが開発者だけでなくサービスに関わる人であればわかる様な言葉になっていると思います。

しかし一口にモーダルと言っても、導入目的や背景によって様々なモーダル導入の手段があります。
例えば、Mapアプリなどでは下半分モーダルの表示がありながらも地図の操作をすることができたり、
iPadの動画アプリでは動画を流しながらも右のスペースにだけコメントや動画の情報が表示されたりと、
その使い方はモーダルのようでありながら、ユーザー操作を妨げないモーダレスなデザインも存在します

本セッションではhuman-interface-guidelinesで言及されているmodalityの内容また、
私のMapアプリや動画アプリでのモーダル導入経験から
モーダルウインドウのような表示をどのようにアプリに組み込むべきか？をサンプルコードを用いて、実際のアプリケーションでモーダルをどのように実装するかを学びます

目次

• モーダルとは？
• どのようにモーダルはサービスで使われているか？
• 様々なmodalityな表示
• モーダルデザインの課題と解決策 ~ 標準のAPIでは表現が難しいモーダル例~
  • アプリの動作を止めないモーダル
  • 特殊なUI表示のモーダル
• まとめ