本稿はJCB Advent Calendar 2025の12月16日の記事です。

初めまして。JCBデジタルソリューション開発部の若林です。MyJCBアプリのiOS側のエンジニアをしています。去年から社会人になり、今年の11月でSwift歴1年になりました。
昨年書いた記事を読み返すととても懐かしい気持ちになります。
WebアプリとiOSアプリを比較した記事
 ローカルLLMを使ってみた記事

今回の記事では、現在取り組んでいる「MyJCBアプリのマルチモジュール化」について、どのような構成がベストなのかを検討したプロセスと、現在直面している課題について共有したいと思います。

なぜマルチモジュール化するのか

そもそも、なぜ安定して稼働しているアプリをわざわざマルチモジュール化するのか。理由は大きく2つあります。

コンフリクト解消にかかる時間を減らしたい
開発が進むにつれて1つの巨大なプロジェクトファイル（.pbxproj）やファイルを触ることによるコンフリクトが頻発するようになり、またそのコンフリクトの内容も複雑化していき、コンフリクト解消に開発の時間を取られてしまっています。
SwiftUIのプレビュー機能を快適に使いたい
SwiftUIのプレビュー機能ではViewに関連するモジュールをビルドして表示するようになっています。
現在のMyJCBは整合性を重視したモノリス構成を採用しているため、プレビュー時にもシステム全体への影響確認（ビルド）が走る仕様となっています。

どう進めていくか

新機能のみを別モジュールへ切り出す方式を検討しましたが、この手法では既存コードとの境界が曖昧になり、フォルダ構成の複雑化や依存関係の統制不能といった構造的な問題を引き起こすことになります。そのため、安易な切り出しは行わず、「まずはしっかりと基盤（Coreモジュール）を作り、その上で移行を進める」という方針を採用しました。

どう設計したか

MyJCBのiOSアプリはMVVM+クリーンアーキテクチャで設計されています。
詳細は下記記事を参考にしてください。
MyJCBアプリのアーキテクチャ記事
この設計を崩さずに、先ほど挙げた「コンフリクト解消にかかる時間を減らす」「SwiftUIのプレビュー機能を快適に使いたい」という二つの目的を達成しながらマルチモジュール化するために以下のような依存関係を設計しました。

モジュール構成のイメージ

Feature Modules（機能ごとのモジュール）
- HomeFeature, PointFeature など
- 各Featureモジュール内に Presentation / Domain / Data のレイヤーを持たせ、機能単位で完結させることでチーム開発時のコンフリクトを極小化します。
Core Modules（共通基盤モジュール）
- CoreDomain, CoreData, CoreUI

「依存関係図」

各Featureの中をPresentation /Domain / Dataに分割し、各チームが「自分の担当Featureモジュールのみ」を変更できるようにすることで、ブランチ取り込み時のコンフリクトを低減します。　　

しかし、ここで「SwiftUIプレビューの表示時間が遅い」という課題が出てきました。

私たちのプロジェクトには、様々なSDKの初期化処理などをまとめた CoreCommon（仮称）のようなモジュールが存在します。依存関係のグラフは以下のようになっていました。

Feature → CoreDomain → CoreCommon（重たいSDKを含む）

AppleのWWDCでもSwiftUIのプレビュー機能は、モジュールの依存関係が複雑になるほど、表示にかかる時間がかかる仕様になると言われています。

Feature(画面)の依存関係が複雑になり、プレビュー表示までの時間がかなり遅くなってしまっているのではないかと仮説を立てています。
それを解決するためにCoreDomainのMock化を検討しています。プレビュー時は重たいCoreCommonをFeatureから切り離し、軽量なモックだけでViewを描画できるようにすることで「SwiftUIプレビューの表示時間が遅い」を解決できるのではないかと考えています。