トーク

Apple Vision Pro 向けのコンテンツ開発は、大きく分けて2つのアプローチがあります。1つは Apple 標準の Xcode を使って Swift で開発する方法、もう1つはゲームエンジンを使用する方法です。特にゲームエンジンには Unity、Unreal Engine、Godot Engine などの選択肢があります。

iOSDC Japan の参加者の多くは Xcode で Swift を用いた開発に精通していると思われますが、Apple Vision Pro の登場以前から、XR 領域でのコンテンツ開発にはゲームエンジン、特に Unity が多く用いられてきました。Apple はこの Unity と連携し、「PolySpatial」という Unity 用のソリューションを提供しています。これは、Apple Vision Pro 向けのコンテンツ開発を支援するものです。

このトークでは、Unity の PolySpatial を用いて Apple Vision Pro アプリを実際に開発している数名の開発者と一緒に、Unity を使用した Apple Vision Pro 向けアプリ開発の現実と課題について、Xcode で Swift を用いる方法と比較しながら、一問一答形式でお届けします。具体的には、PolySpatial の基本的な概要から、その利点と欠点について詳しく掘り下げます。

Swift で日時・数値・名前などの情報を String との間で変換（フォーマット）してくれる仕組みのひとつである「FormatStyle」は、2021年の Swift 5.5（iOS 15.0 等）から使えるようになりました。

これまでのフォーマットでは Objective-C ベースの DateFormatter・NumberFormatter といったものを使ってきました。これを Swift のプログラムから使おうとするとき、高度なカスタマイズについて学習する必要があったり、型安全性などのコンパイラの支援が足りなかったり、また Formatter 自身のキャッシュについて考慮する必要もあったりと問題も抱えていました。

新しい「FormatStyle」は Swift ベースで構築されており、それらの問題へアプローチされパフォーマンスが良いとされています。また、フォーマットしたい形式を SwiftUI の View の Modifier のようにチェーン式で記述してカスタマイズするインターフェイスを備えています。

一方で、従来の Formatter とは使い方が異なるため、これまでと同じフォーマットを FormatStyle を使うように移行する際に、混乱しているようすも見受けられます。

登場から4年経った今、FormatStyle へ移行するのにぴったりな時期が訪れました。このトークでは、Swift でのフォーマットについてこれから勉強される方や、従来の Formatter からの移行を検討している方、移行に困っている方などを対象に、FormatStyle の使い方、カスタマイズの仕方、作り方について述べます。さらに、従来の Formatter との比較や、移行の際の考え方・勘所のノウハウ、そして FormatStyle の内部実装についても解説します。

「ふつうのアプリ」とは何でしょうか。
ソーシャルネットワークMastodonのアプリを作る過程で、この問いと深く向き合うことになりました。

Mastodonは少し特殊なSNSです。サーバーの概念や公開範囲の複雑さ、サーバーごとの固有機能など、それらの仕様は直感的なものではありません。
実際にアプリをリリースしてみると、ユーザーが求めていたのはMastodonの機能を完璧に扱えるアプリなのではなく、直感的に使える「ふつう」のSNSアプリなのでした。
TwitterやInstagramのような既存のSNSで慣れ親しんだUIパターンを期待していたのです。

ここから学んだのは「ふつう」を実現することの難しさです。開発者にとって当たり前の操作でも、一般ユーザーにとっては全く理解できない可能性があります。
開発者やデザイナーは独創的なUIを作りたがりますが、ユーザーは慣れ親しんだパターンを求めています。重要なのは、新しい概念を既存のメンタルモデルに合わせることです。
これらは、もちろんMastodonのアプリに限った話ではありません。

このトークでは、アプリのUIデザインを考察した上で発見した「ふつう」の見つけ方、既存UIパターンの評価方法、そしてそれらを妥協せずに実装するための実践的なテクニックを紹介します。

Apple Vision Proが登場し、私達はついに空間コンピューティングへのチケットを手にしました。
3次元の形状を、ディスプレイに投影された平面的なものではなく空間的に体感できるようになったのです。

RealityKitのMeshResourceでは、直方体(Box)、平面(Plane)、球(Sphere)、円錐(Cone)、円柱(Cylinder)、そして文字(Text)といった基本的な形状を簡単に作成できます。
また、Reality Composer Proではカプセル(Capsule)も配置できます。

しかし、これら以外の3次元形状を作成したい場合、どのようにすれば良いのでしょう？
もちろんメッシュの頂点を指定すれば好きな形状が作成できますが、大量の頂点をコード上で逐一指定するのはあまり現実的な方法ではありません。

そこで、パラメトリック曲面と呼ばれる概念を取り入れます。
この手法はすべての頂点を指定する変わりに、2次元のパラメータを指定することで曲面上の座標を表現し、メッシュの頂点を計算させる方法です。

例えば代表的なものとして、多くのベクターイメージ編集ソフトなどでお馴染みの「ベジエ曲線」を拡張した「ベジエ曲面」があります。
これはベジエ曲線と同様に、制御点を動かすことで曲面の形状を直感的に定義することが可能です。

本セッションでは一般的なパラメトリック曲面の解説とベジエ曲面の解説を行い、曲面を直感的に変更できるところをお見せします。
また、ベジエ曲面の性質や限界、実装上の注意点などについてお話します。

学習管理アプリStudyplusでは、「スマホを隔離して集中して勉強したいけど、勉強の記録もしたい」というユーザーの声が多数寄せられていました。これらの声に対してStudyplusでは、FlutterアプリとApple Watchを連携して、Apple Watchでも記録がつけられるようにすることでユーザーの要望に応えることができました。
この対応にはFlutter、iOS、Apple Watchの3つの環境をまたいだ実装が必要となり、それぞれの連携方法を理解することが重要になります。
本セッションでは、Studyplusでの実際の対応事例をもとに、設計から実装、そして得られた価値まで包括的に解説します。

具体的な内容

• ユーザーの要望の分析や提供したい価値の決定
• どの機能をApple Watchに切り出すかの仕様決定
• Flutter・iOS・watchOS間の実装設計と技術選択
  • WCSessionを使ったiOS・watchOS間のデータ通信・監視
  • Method Channel、Pigeonパッケージを使ったクロスプラットフォーム連携
  • Apple Watchの制約を考慮したUI/UX設計
• 対応によってユーザーに提供できた価値

Apple Watch対応を通じて実際のサービス開発で得られた知見を余すことなく共有し、すぐに活用できる実践的な内容をお届けします。

対象者

• Apple Watch対応を検討中のアプリ開発者
• iOS・watchOSアプリ開発者
• クロスプラットフォーム開発でのネイティブ実装を学びたい開発者

紙のマップは古くから多くの人々に利用されてきました。そして、スマートフォンの登場によりいつでもどこでもマップを確認できるようになっています。

マップに関する機能は、MapKitなど開発者向けのフレームワークとして公開されています。このフレームワークを用いて、マップを活用したアプリケーションが数多く登場しています。特にモビリティ関連のアプリケーションでは、マップによる位置情報の表示が中心的な機能となっており、今や欠かせない存在となっています。

マップを活用したアプリケーションを実装するには、マップの表示技術や緯度経度といった座標に関する知識が不可欠です。このようなマップに関する基礎知識が不足している状態でアプリを実装すると、誤った位置に場所を表示したり、地図上に情報を表示するまでに時間がかかったりするなど、ユーザー体験を損なう原因となります。しかし、これらの知識は開発者用のドキュメントにはあまり記載されておらず、基礎知識がない状態で実装してしまう場合が多いです。

このセッションでは、マップを扱う上で必要な知識を共有しながら、MapKitを使ってマップを活用したスマホアプリの実装例を紹介します。

このセッションで話すこと:

• マップを扱う上で必要な基礎知識
  • どのようにアプリは地図を表示しているのか
  • 座標・緯度経度とはなにか
  • マップで場所を表現するのに必要な要素
  • マップの表示領域と位置情報を表示する量について
• MapKitでアノテーションなどの独自の位置情報を表現して表示する
• MapKitを使った場所検索やルート検索機能の実装

現代のiOS開発において、パフォーマンス向上のために並行処理は不可欠です。
Swift Concurrencyは、async/awaitによる非同期処理の記述を簡潔にするだけでなく、Actorや構造化された並行処理によって、これまで開発者を悩ませてきたデータ競合という危険なバグから、コンパイル時という開発の早い段階で私たちを解放してくれます。
これは、これまでの並行処理技術にはなかった画期的な「コンパイラによる安全保証」という大きな特徴を持っています。

では、Swift Concurrency以前はどうでしょう？
例えばGCDやOperationQueue、さらにはNSThreadといった技術はどれほど簡潔ではなく安全ではなかったのでしょうか？
これらの技術は、スレッド管理を抽象化したり、排他制御の基礎機能を提供したりはしましたが、その安全性は常に開発者自身の厳密な規律に依存していました。
一つでも排他制御を忘れると、予期せぬクラッシュやデータの破壊を引き起こすリスクに常に晒されていたのです。

このトークでは、この並行処理の歴史を、現代のSwift ConcurrencyからNSThreadへと遡りながら、その安全性の進化を比較・解説します。
シンプルなカウンタからファイルダウンローダーを例にSwift Concurrency、OperationQueue、GCD、NSThreadの実装例をお見せします。

Swift Concurrencyが目指している安全性を歴史から学び、自信を持ってコードが書ける一助になれば幸いです。

去年の私は、「@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)に興味を持ち、開発で今まで以上に活用してみてくれた方が増えたら、私にとってこれ以上に嬉しいことはないでしょう！

Swift 6と共にComplete Concurrency Checkingが導入され、1年が経ちました。これまで曖昧にしておくことができたSwift Concurrencyも、きちんと理解して正しく適用する必要性が高まっています。

Swift Concurrencyの関連仕様は多岐にわたり、Swift EvolutionのProposalも膨大です。それらのすべてを正確に把握するのは非常に困難です。しかし、Swift Concurrencyのコアとなる考え方はシンプルです。それさえ押さえてしまえばSwift ConcurrencyとComplete Concurrency Checkingについての見通しがよくなり、その挙動を体系的に理解しやすくなります。

本トークでは、Swift Concurrencyの根幹を成すものとして、Isolation Domain・Isolation Boundary・Sendableとは何か、それらを利用してコンパイラがどのようにデータ競合を防ぐのか（Complete Concurrency Checking）を解説します。

その上で、Actorがどのような仕組みで動作するのか、ActorとIsolation Domainの関係、Global Actor（特にMainActor）およびTaskについて解説し、Swift Concurrencyについての理解を深めます。

さらに、その説明の延長線上として、WWDC25の様々なセッションでも取り上げられたSwift Concurrency関連の新機能SE-0461・SE-0466について解説し、Swift 6.2のSwift Concurrencyにおけるそれらの役割を示します。

最後に、iOSアプリでそれらをどのように組み合わせて活用するのか、一例を示します。

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対応へ移行した際に、どのような修正が必要だったのかを、差分ソースコードを示しながら詳しく解説します。

長年にわたり、みてねiOSアプリにおいて、写真/動画のアップロード中にアプリを開き続けていないとアップロードが中断されてしまう課題に直面してきました。
具体的にはiOSのバックグラウンド実行の30秒制限により、アプリが中断されるとアップロードが停止してしまう問題です。このトークでは、アプリをバックグラウンドに遷移させてもアップロードを完了まで継続できるようにするために実施した解決策、経緯、そして今後の展望について紹介します。

解決策としては、アップロード中にバックグラウンドに遷移した際、ピクチャインピクチャ機能を活用してアップロード進捗を表示することで、バックグラウンド制限を突破しました。このトークでは、そこに焦点を当ててつつそこまでの経緯/苦戦したところ/制限についてお話しします。

• 正攻法であるBGProcessingTaskをなぜ採用しなかったのか
• ピクチャインピクチャによるアップロードの制限
• ピクチャインピクチャのUIカスタマイズの限界
• バックグラウンド遷移時に自動的にピクチャインピクチャを表示するための方法 / 苦戦したところ
• Appleのレビューを通過するための検証
• 特許の出願
• iOS26のBGContinuedProcessingTaskへの移行の可能性とその準備

このトークを通じて、同様の課題に直面している開発者の皆様に有益な情報を提供できれば幸いです。

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設計：管理画面を介したノーコードな運用ワークフロー
・プロダクトとしての“スケーラビリティ”：技術的負債を生まないための運用と設計戦略

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

身分証をApple Walletをはじめとしたデジタルウォレットに搭載する動きが、近年世界的に広がっています。アメリカでは一部の州において、州発行の運転免許証の搭載が進んでいます。各国での実証実験が進行しており、これらはISO/IEC 18013-5や-7、23220といった国際標準で定められ、セキュリティやユーザープライバシーに配慮しながら世界中で互換性を持たせる動きが進んでいます。
こうした流れの中で、2025年6月24日から、日本でもiPhoneへのマイナンバーカードの搭載が始まりました。Apple WalletにNational IDを搭載するのは、日本が世界で初めての事例であり、デジタル庁とAppleとの協業によって実現されました。
マイナンバーカードを持っていれば、誰でもApple Walletにmdoc（Mobile Document）として搭載することができ、iPhoneだけでさまざまな行政サービスを利用できるようになります。
これに限らず、開発者もAppleが提供するID Verifier APIを使えば、自分のアプリに年齢確認や本人確認といった機能を国際標準に準拠した形で実装することが可能です。たとえば、酒類購入時の年齢確認や、オンライン口座開設時の本人確認など、民間サービスへの応用が期待されています。
このトークでは、「iPhoneのマイナンバーカード」を活用し、アプリ内、対面、ブラウザの3種類のVerifier APIの使い方とユースケースを紹介します。
また、mdocとはそもそも何であるか、そのデータ構造と検証手法など実装詳細にも触れていきます。
さらに、電子証明書をiPhoneから取り出して利用できる日本のために作られたAPIについても紹介しながらBehind the Sceneにも少し触れてみたいと思います。

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

本セッションでは、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の開発方針