iOSDC 2025に参加してきました！

9/19〜9/21のiOSDC Japan 2025に現地で参加させていただきました！

本記事では特に印象に残ったセッションについて、聴講メモを元にダイジェストでご紹介します。

iOSDC Japan 2025について
Day0：注目の技術と新たなアプローチ
- AccessorySetupKitで実現するシームレスなペアリング体験
- 空間再現力の鍵、APMPを読み解く
Day1：パフォーマンス、設計
Day2：未来への実装と新たな体験
- Apple Vision Proでの立体動画アプリの実装と40の工夫
おまけ：戦利品（ノベルティ）紹介！
まとめ

iOSDC Japan 2025について

iOSDC Japanは、iOS関連技術をコアのテーマとした技術者のためのカンファレンスです。

フェンリルはダイアモンドスポンサーとして協賛し、スポンサーブースを出展しました。

www.fenrir-inc.com

Day0：注目の技術と新たなアプローチ

初日から、E2Eテスト、アクセサリ連携、空間再現、手話認識など、幅広いテーマのセッションが行われました。

AccessorySetupKitで実現するシームレスなペアリング体験

fortee.jp

Bluetoothアクセサリのペアリング体験は、アプリ開発者にとって悩みのタネの一つです。このセッションでは AccessorySetupKit を活用し、OS標準のUIでシームレスなセットアップを実現する方法が紹介されました。

AccessorySetupKit を使うことで、アプリごとにペアリングUIを実装する必要がなくなります。
ただし、既に CoreBluetooth など既存の機能で接続済みのアクセサリは、そのままでは AccessorySetupKit で接続できないため、アクセサリ側への移行処理が必要になる点に注意が必要です。

空間再現力の鍵、APMPを読み解く

fortee.jp

空間コンピューティングに関するセッションも注目を集めていました。このセッションでは、空間再現の核となる「APMP」の解説が行われました。

特に興味深かったのは、発表者の方が複雑な実装部分について、仕様書を「ClaudeCode」に渡して生成してもらったというエピソードです。AIがコーディングを補助するスタイルが、より一般的になってきていることを感じさせられました。

Day1：パフォーマンス、設計

2日目も、パフォーマンスチューニング、設計パターン、バックグラウンド処理などの実務に直結する内容やVision Proなど気になる話題が満載でした。

ハイパフォーマンスなGIFアニメ再生を実現する工夫

fortee.jp

Mastodonクライアントアプリ開発における、大量のカスタム絵文字（GIF）表示のパフォーマンス改善事例です。

課題: GIFが大量発生するとメモリ使用量が増え、スクロールが重くなる。
チューニングの考え方:
- 技術的な指標（例: フレームレート）だけでなく、「ユーザーが何に困っているか」（例: 絵文字を選ぶスクロール時間が長い）を指標にする。
- アプリのコアバリュー（豊富な絵文字）を明確にし、重要でない品質（例: GIFの滑らかさ）を下げ、重要な品質（スクロール性能）を上げるトレードオフを意識する。
具体的な解決策:
- Instruments の AnimationHitches で測定。
- AnimatedImage を使用。
- フレーム画像のサイズを小さくし、フレームを均等に間引く（後半だけ間引くと止まって見える）ことで、アニメーションの連続性を保ちつつデータ量を削減。
- iOS 17以降は UIUpdateLink を使い、描画タイミングで表示処理を行う。

「Chatwork」アプリにおけるSVVS実装戦略

fortee.jp

大規模アプリにおける状態管理の課題（データ不整合、煩雑なアンラップ）に対し、「SVVS (Single View ViewState)」という設計パターンでアプローチした事例です。

課題: ログイン状態などをシングルトンで管理すると、ログイン前提の処理のたびにアンラップが必要になり、データ不整合のリスクも生じる。
LoginContextによる解決:
- ログイン時に LoginContext を生成し、ログアウト時に破棄。
- static に保持せず、バケツリレーのようにDIコンテナ経由で受け渡す。
- これにより、未ログイン時にはそもそもアクセスできない状態（アンラップ不要）を作り出し、データ不整合を防ぐ。
DIとテスト:
- プロトコルのデフォルト実装で fatalError を仕込むテクニックが面白かったです。DIで必要な依存関係だけを実装し、もし実装漏れがあれば fatalError でクラッシュするため、実装漏れを防げるという仕組みです。
CombineからObservationへ:
- Observation フレームワークへの移行についても言及。
- 監視しているプロパティ単位での更新通知になるため、Combineのようにプロパティが一つ更新されただけで全体が再描画される、といった無駄を省ける点が強力とのことでした。

サンプルリポジトリ: https://github.com/chatwork/iosdc2025_svvs-sample

iOSアプリのバックグラウンド制限を突破してアップロードを継続する道のり

fortee.jp

「みてね」アプリでの、長い動画のバックグラウンドアップロードを実現するための壮絶な道のりについてのセッションです。

BGProcessingTask は端末のアイドル状態が必要など、要件に合わず。Live Activity もアプリ側の処理継続はできませんでした。
驚きの解決策: ピクチャインピクチャ（PiP）の活用
- UIView をビデオフレームに変換し、PiPで表示し続けることで、バックグラウンド遷移後も処理を継続させることに成功。
- ただし、これは特許出願中の技術とのこと。
実装の難所:
- バックグラウンド遷移時の自動PiP開始（エラーが返ってこないことがある）。
- PiPの再生ボタンなどを無効化。
- 端末ロック解除時に画面が真っ黒になる（1分ごとに更新して対応）。
- 他アプリ（YouTubeなど）がPiPを開始すると上書きされて停止する。
Appleレビュー対策: レビュー時に正直に機能説明と動画を添付したところ、問題なく通ったそうです。
未来の解決策: BGContinuedProcessingTask (iOS 26 SDK)
- 端末ロック中もダウンロード可能！
- OS標準のUI（Live Activity）に進捗が表示される。
- BGContinuedProcessingTask は1アプリ1つまで（1端末1つかも？）。
- ただし、セッション時点では「iOS 26正式版にアップデートしたら開始できなくなった」とのことで、Appleに問い合わせ中というホットな情報も。
結論: iOS 26未満はPiP、iOS 26以上は BGContinuedProcessingTask という使い分けが良さそう、とのことでした。

参考リポジトリ:

PiP: https://github.com/HikaruSato/AutoPictureInPictureUIViewExample

BGContinuedProcessingTask: https://github.com/HikaruSato/ExampleBackgroundProcess

ABEMAモバイルアプリがKotlin Multiplatformと歩んだ5年

fortee.jp

KMP（Kotlin Multiplatform）を5年間にわたり導入・運用してきたABEMAさんの知見共有です。

UIはあくまでネイティブで実装し、ロジック共通化にKMPを採用。
導入・運用の課題:
- 導入コスト（環境構築、Swiftとの相互運用性改善、バグ調査）は相当なもの。
- KMP固有の知識が必要。
- 当初はリポジトリを分けていたため、PRマージのたびにリリース・取り込みが必要でオーバーヘッドが大きく、現在モノレポ化を進めている最中。

KMP導入を検討する方には非常に参考になりそうなリアルなお話でした。

アプリの「もっさり」を解決！MetricKitを活用したアプリのパフォーマンス改善

fortee.jp

アプリのパフォーマンス（もっさり感）を、MetricKit というフレームワークを使って分析・改善した事例です。

MetricKit とは: Appleが提供するパフォーマンス測定フレームワーク。リリース後の全ユーザーの集計値を取得できるのが特徴です（特定のユーザーシナリオの検証には不向き）。
データ活用: データをGoogle Analyticsに送信し、BigQueryで集計・分析。
分析:
- ヒストグラムは判断しにくいため、中央値を代表値として使用。
- 結果、「楽曲登録件数が多いユーザーほどハング時間が長い」という弱い正の相関と、「かなりのユーザーが2.5秒以上のハングを経験している」という事実を発見。
原因特定:
- TimeProfiler や Firebase Performance Monitoring を使い、APIの実行時間とアプリ側のハング時間を比較。
- 結果、API側ではなくアプリ側に問題があると特定できました。
根本的な問題:
- 同期処理をメインスレッドで行っていた。
- 毎回CoreDataの取得・更新を行っていた。
解決策:
- メインスレッドの処理をバックグラウンド処理に変更。
- CoreDataへのアクセス回数を減らす。
- forEach で行っていた処理の計算量を削減する。

このセッションでは、開発中（XCTest, TimeProfiler）とリリース後（MetricKit, Firebase Performance Monitoring）で、それぞれ適したパフォーマンス測定ツールを使い分けることの重要性も強調されていました。

Day2：未来への実装と新たな体験

カンファレンス最終日も、Swift 6への移行という現実的な課題から、Vision Proという新たなプラットフォームでの挑戦まで、興味深いセッションが続きました。

fortee.jp

オンライン診療アプリ「CLINICS」を、Swift 6（とConcurrency）へ移行した際の戦略と知見です。

移行方針:
- UIを扱うクラスは @MainActor
- Usecase, Repository, Entityは Sendable
移行プロセス:
- まず全モジュールに swiftLanguageMode(.v5) を付与し、対応するモジュールから順に外してエラーを潰していく。
- SwiftTestingへの移行には、ドキュメントを元にAI（ClaudeCode）に変換してもらう手法を活用。
Swift 6環境特有のクラッシュ:
- async let のクラッシュ（TaskGroup で回避）
- CallKit のクラッシュ
移行期間: 開発環境ではSwift 6を使い、QA・本番ではSwift 5を使う移行期間を設けて対応。
Approachable Concurrency (Xcode 26でデフォルトON) により、データ競合は起こりにくくなるものの、重い処理がMainActorで実行されてしまう可能性もあるため、@concurrent の利用を検討する必要がある、という知見も共有されました。

Apple Vision Proでの立体動画アプリの実装と40の工夫

fortee.jp

Apple Vision Pro向けの立体動画アプリ開発における、実践的なノウハウが詰まったセッションです。空間コンピューティングならではのUX/UIの工夫が非常に興味深かったです。

UIの視線追従: ユーザーの視線にUIが追従するように実装。これにより、ユーザーがDigital Crownを押してUIを正面に戻す、といった余計な操作説明を不要にしています。
滑らかな追従: 視線にUIが即時追従すると違和感があるため、あえて少し遅れて追従させることで、滑らかな体験を実現。
オペレータ用ジェスチャー: 他のユーザーにデバイスを貸す際（初期化）の操作として、「左手で頭の上でピース」といった特殊なジェスチャーを割り当て。一般ユーザーの操作（ピース）と差別化し、オペレータ専用の操作を検知できるように工夫。
BGMとSE: 操作が正しく認識されているか、処理中なのかを音でフィードバック。これにより、ユーザーの不安を取り除き、開発時のテスト効率も向上。
状態管理: アタッチメントを使い、アプリを常にアクティブな状態に保つことで、状態管理をシンプルに。
大容量リソース: 100GBを超える動画リソースは、初回読み込み時にファイルパスをアプリ内に記録し、次回以降はそこを参照する方式を採用。
カスタムUI: 標準ボタンは押しにくかったため、奥行きがあり押し込みアニメーションを備えたカスタムボタンを作成。ジェスチャー操作時にはUIを表示し、状態を明確にする工夫も。

おまけ：戦利品（ノベルティ）紹介！

セッションだけでなく、ブース巡りやイベントもiOSDC現地参加の醍醐味です。

今回は、ブースを回って全員がもらえるものではなく、特定の条件をクリアしてゲットした「限定ノベルティ」を少しだけ自慢させてください！

技術書（抽選）
- PLAIDさんブースでアンケートに回答したところ、なんと抽選に当たり、こちらの技術書をいただきました！Day2の15時頃でしたが、その日2人目の当選で、結構レアだったみたいです！
ミニカー（じゃんけん）
- こちらは、KINTOさんのブースでAI広報「るぴあ」ちゃんとのじゃんけんに勝ってゲットしたミニカーです！