はじめに
WED株式会社でONEの開発をしているiOSエンジニアの王です。
今年のiOSDC Japan 2025に参加し、会場が西早稲田キャンパスから有明セントラルタワーへと変わった新鮮な雰囲気の中で、iOS開発の最新トレンドや実践的な知見を楽しむことができました。
今年のトークセッションはSwiftUIへの移行、最新のAPIの活用、AIを使った機能開発など、実務で直面する様々な課題に対する実践的なアプローチが数多く紹介されました。今回は印象に残った内容とそこから得られた知見を紹介したいと思います。
トーク
AIを活用したレシート読み取り機能の開発から得られた実践知
三つのテーマがあり、それぞれについて話したいと思います。
1. AIレシート読み取り機能の概要
このテーマでは、クライアント側でVision Frameworkを使ってOCRを行い、その結果をサーバー側に送信して機械学習で要素を判別し、アプリに返すという一連の流れを見ることができました。
2. レシートOCR
アプリ側のOCRについて、カメラの設定、レシートの画像認識、精度向上のための様々なテクニックが紹介されていました：
- 4Kなどの高解像度設定による画質向上
-
autoFocusRangeRestriction = .nearを用いた適切なフォーカス制御 - 最小フォーカス距離の考慮
OCRの実現はAppleのVision FrameworkのAPIを組み合わせて実装されています：
-
DetectDocumentSegmentationRequest：画像から文字を含む矩形領域を検出 -
TrackRectangleRequest：検出した矩形の動きをビデオフレーム間で追跡 -
RecognizeTextRequest：画像内のテキストを認識
さらに発展的なテーマとして、WWDC 2025で発表されたRecognizeDocumentsRequestを活用した精度向上の可能性、そしてFoundation Models frameworkによるOn-device処理で完結するレシート読み取りもありました。
3. Foundation Modelsの可能性
最後に、今年のWWDC 2025で公開されたFoundation Modelsについてです。
レシート情報の構造化を試してみたという話で、実際に試したところ、店名や日付の抽出は比較的うまくいきましたが、金額の抽出やカテゴリ推定のあたりにはまだ課題があります。
Foundation Modelsは約30億パラメータ規模のLLMであり、ChatGPT-4はその何千倍ものパラメータ数を持つため、比較すると一定の制限があります。ただし、Foundation Modelsはローカルで動作するLLMであるため、今後のさらなる進化が期待されます。
弊社のONEもレシート買取サービスを提供しており、レシート撮影の体験向上も重要なテーマです。On-device処理の精度向上により、サーバーコストの削減やリアルタイムフィードバックの実現など、ユーザー体験の向上につながる可能性があり、今後の改善施策として検討したいと感じました。
「Chatwork」アプリにおけるSVVS実装戦略
単方向データフローという選択肢
「Chatwork」アプリにおけるSVVS実装戦略というセッションでは、Store-View-ViewStateパターンによる単方向データフローの実装を紹介していました。
SVVSのアーキテクチャ概要：
- Store: ビジネスロジックとAPI/DB通信を担当し、状態を管理
- ViewState: StoreからCombineで状態を受け取り、Viewが必要とする状態を提供
- View: ViewStateを監視し、ユーザーアクションをViewStateのメソッド経由でStoreに通知
データはStore → ViewState → Viewの単方向に流れ、アクションは逆方向に伝播します。
このアプローチの最大の特徴は、SwiftUIの特性を活かしながら、外部ライブラリに依存しない設計を実現できる点です。The Composable Architecture（TCA）やClean Architectureと比較すると、学習コストが低く、導入ハードルが下がります。
Observation frameworkとの組み合わせ
セッション内で触れられていたObservation frameworkによる@Publishedの置き換えは、iOS 17以降をターゲットにできるプロジェクトにとって大きな転換点です。
従来のCombineベースの実装と比較して：
- ボイラープレートコードが減少
- パフォーマンスの向上（不要な再描画の削減）
- より直感的な状態管理
SVVSのアーキテクチャはまだ使っていませんが、念頭に置きつつ、Observationの導入も参考になります。
『ホットペッパービューティー』のiOSアプリをUIKitからSwiftUIへ段階的に移行するためにやったこと
大規模アプリでの移行戦略
「ホットペッパービューティー」のiOSアプリをUIKitからSwiftUIへ段階的に移行する事例も非常に参考になりました。
- 一括ではなく、画面・コンポーネント単位で少しずつ置き換え
- その過程でSwift Package Managerを利用してモジュール化を進め、責務を分離
- SwiftUI用に共通UIコンポーネントを再整備し、デザインとの整合性を強化
スナップショットテストの重要性
移行時の品質担保として、画面単位のスナップショットテストが有効だと紹介していました。
- リファクタリング前後のUI差分を視覚的に検出
- SwiftUI Previewの設定を活用し、様々な状態のスナップショットテストを生成
- iOSSnapshotTestCaseを用いて、テストクラスを作る
- Sourceryを用いてスナップショットテストを自動生成する
弊社のプロジェクトはUIKitからSwiftUIへの移行対応中で、テスト周りについて多く議論したり、移行中にバグが出ないように工夫しています。このような話を聞くと参考になります。
iOSアプリのバックグラウンド制限を突破してバックグラウンド遷移後もアップロード処理を継続するまでの道のり
トークを見る前に、タイトルを見ただけでいろいろ想像していましたが、まさかPIPで実現するとは思っていませんでした。
iOSでは、アプリがバックグラウンドに遷移すると、他のアプリやシステム全体に影響を与えないように、ダウンロードやアップロードなどのタスクが中断されやすいという制約があります。今回のトークでは、Picture in Picture（PIP）機能を活用して、バックグラウンド遷移後もアップロード処理を継続する実装事例が紹介されていました。
PIPといえば通常は動画再生のために使われる機能という認識でしたが、今回はアップロード進捗を表示するビューを差し替える形で応用しており、Appleの審査でリジェクトされるリスクもありそうな実装ですが、最終的には問題なく通過したとのことでした。
さらに、iOS 26で導入されるBGContinuedProcessingTaskによって、今後はこうしたバックグラウンド処理の実現可能な範囲がより広がることが期待されます。
おわりに
iOS開発の環境は近年大きく変化しています。SwiftUI、Combine、Swift Concurrency、Observationといった新しい技術スタックが登場し、従来のUIKit +MVP/MVVM/VIPERといった構成から、よりモダンな設計への移行が現実的な選択肢となってきました。
今年のiOSDCは、新技術、実際のプロダクトでの導入事例や苦労話を多く聞くことができ、非常に実践的な学びが得られました。来年もまた参加できることを楽しみにしています！
Discussion