こんにちは。スマートバンクで iOS / Android エンジニアをしている nakamuuu です。
2023年以降、Jetpack のライブラリ群をはじめとするAndroidエコシステムでの Kotlin Multiplatform のサポートが加速する中で、マルチプラットフォームツールに関する議論が活発になっています。 Flutter / React Native なども含め、iOS / Androidアプリのコード共有技術はモバイルアプリ開発における主要トピックとして継続的に注目を浴びてきました。
android-developers.googleblog.com
一方でそのようなソリューションを採用しないプロダクトでは、iOS / Android の両プラットフォームの実装を同じ開発メンバーが担うこともあるでしょう。また、両実装を担当しないまでも、iOS / Android の実装者間で相互にコードレビューしたり、設計や仕様の差異を防ぐためのコミュニケーションを取る場面は多々あるでしょう。
スマートバンクでは、2025年3月時点ではどのマルチプラットフォームツールも採用していません。その中で、私も多くの施策において iOS / Android の両プラットフォームの実装を担ってきました。 inSmartBank では、SwiftUI (iOS) と Jetpack Compose (Android) の差分を俯瞰する形で実装例を紹介するエントリーも過去に公開しています。
今回のエントリーではそんな “人力Multiplatform芸人” である私自身が、どのようにアウトプットの最大化に努めているかの一例を紹介します。さらに、到来しつつあるAI時代において、複数プラットフォームでの開発がどのように変容していくのかについても展望を記します。
📝 このエントリーで触れないこと
- マルチプラットフォームツールの導入是非
- 両プラットフォームの開発を加速する具体的なAIツールの活用手法
両プラットフォームの差分を捉える
両プラットフォームの実装を担う中で iOS と Android それぞれにおける実装難度が同等になるとは限りません。フレームワークやAPIインターフェースからもたらされる制約によって、同じ機能を実装しようとしてもその難度に大きな差が生まれることも多々あります。
極端な例ではありますが、冒頭で軽くエントリーを紹介した “画像のプレビュー画面” ではジェスチャー操作関連のAPI群の差異により、大きく実装コストの差が生じました。
iOS / Android の両プラットフォームの差分を着実に捉えることは、設計や開発初期での見積もりの精度にも直結します。実装フェーズにおける不確実な要素の排除にもつながるため、まずはここから話を進めていくこととしましょう。
UIレイヤー
SwiftUI と Jetpack Compose はどちらも宣言的UIのパラダイムを共有しているため、画面実装における設計指針は一定共通化しやすいことと思います。Stateless / Stateful な View を分離する State Hoisting の考え方や State Holder としての ViewModel の活用などは共有しやすい部分でしょう。
一方で画面構成やインタラクションによっては、片方のプラットフォームでのみ重めのカスタマイズが要求される…といったこともありえます。先述のジェスチャー操作のような細かなインタラクションの実装ではAPIインターフェースの差異の影響を受けやすいことでしょう。
ライフサイクルと画面遷移
画面スコープでの状態管理により目を向けると、 Android では Activity や Fragment のライフサイクルに起因してより強い制約が生じます。ViewModel などで保持するデータが短期間で揮発しうる可能性を考慮する必要があります。
また、画面遷移を考えた場合も、Android では Bundle を用いたデータの受け渡しが必要になり、そのサイズ制限を考慮しなければなりません。大きなデータを画面間で取り回す場合は、ViewModel の共用やデータレイヤレベルでの保持が必要となります。この点に関しては iOS では比較的自由度の高いデータの受け渡しが可能ですが、自由度が高いことからこそ開発者自身が制約をもたらす必要があるとも言えるでしょう。
データレイヤー
iOS / Androidアプリのアーキテクチャに広く目を向けると、UseCase や Repository など、プラットフォーム固有の API に依存しないロジック実装は設計を共通化しやすいコンポーネントでしょう。Kotlin Multiplatform の活用においても、プラットフォーム固有の都合が入りづらいデータ処理やビジネスロジックは部分的なコード共有の主なターゲットとなっています。
細かな例外として、プラットフォーム固有のデータストアやリアクティブフレームワークの振る舞いに過度に依存した実装が存在する場合は、設計を共用しづらい部分が生じえます。データストアに関しては、Kotlin Multiplatform では Jetpack の DateStore / Room によるサポートによって解決しています。
その他
カメラや生体認証といったハードウェアの機能群を用いる場合にもその仕様差に留意する必要性が高いでしょう。ワンバンクでは画像からのオブジェクトやテキスト検知において Vision framework (iOS) / ML Kit (Android) の出力結果の差に大きく悩まされたこともありました。
細かい例ではサードパーティ製の外部SDKの成熟度によっても、両プラットフォームでの設計の差異が生じます。ViewController / Activity や他ライブラリへの依存具合によって、実装上の障壁が生まれることも多いです。
両プラットフォームを担う上でのアプローチ
プラットフォームごとの差分を横断的に捉えつつ、実際の施策で両実装を担う際にはどんなアプローチが取れるでしょうか？私が直近 iOS / Android の両プラットフォームの実装を担当した『マイナンバーカードの読み取りでの本人確認』の機能において意識していたところを簡単に記します。
① レイヤー単位で懸念点を見積もる
先述の通り、実装レイヤーに応じて iOS / Android の両プラットフォームで異なる制約が生じることがあります。実装粒度に応じて、画面単位からさらにブレイクダウンする形で両プラットフォームでの差分を踏まえた見積もりや懸念点の洗い出しを行いました。
今回の施策ではそれぞれ細かいものではありますが、以下のポイントに着目しています。
- 画面遷移におけるデータの共有 : パスワードの入力や読み取り、必要事項の入力など手続き的に進行するフローであることから、画面間のインスタンスの取り回しにおいて難度の差を見込んだ。
- 読み取り処理のハンドリング処理 : AndroidではNFCの読み取り検知のイベントをルート寄りの実装（
Activity#onNewIntent）で拾う形になる。読み取り画面へイベントを伝播していく必要があるのでそのコストを大きく捉えた。 - 外部SDKの仕様差 : 使用する外部SDKの仕様として ViewController / Activity への依存方法や異常系のエラー表現においてプラットフォーム間の差分が存在した。
② プロジェクトの性質も踏まえて実装順を決定する
両プラットフォームを担当する際にはその実装順を流動的にできることも一つの強みになります。今回のプロジェクトにおいては一連の本人確認フローの体験が破綻していないか、早期にプロトタイプレベルの実装を用いて検証したいニーズが発生していました。
- 開発初期 : iOS / Android で実装差の出にくい導線部分のUIなどを構成
- 開発中期 : SDKとの連携部分や画面間のデータの取り回しはiOSの実装を先行させる
- 開発後期 : iOSのビルドを用いた検証を先行させ、確保した時間でAndroidの残実装を進める
のような形でプラットフォーム間の見積もりの差分も踏まえつつタイムラインを組み替えていました。プロジェクトのリスク軽減と実装時間の確保において、実装順を流動的にするアプローチが有効に作用したように思います。
共有資産の積み上げ
中長期的な視点では設計思想や技術資産の両プラットフォームでの共有をチームとして進めてきました。この “両プラットフォームの共有資産の積み上げ” はスマートバンクのモバイルアプリチームの一つの強みであり、双方の実装を流動的に担いやすくすることにつながっています。
設計思想の部分的な共有
ワンバンクでは ViewModel を State Holder として用いる設計を iOS / Android ともに採用しています。iOS では ObservableObject 、Android では ViewModel (Jetpack) をUIの状態の保持に活用し、状態そのものは主に単一の enum や sealed interface によって表現しています。
Repository パターンによるデータソースの抽象化や、 UseCase による手続き的な処理の隠蔽など、データレイヤーにおける基礎的な設計指針もある程度足並みを揃えています。両プラットフォームの実装を担いやすくなることはもちろんですが、iOS / Android の実装者間で相互にコードレビューする際に互いの知見を共有しやすくなっています。
デザインシステムの整備
ワンバンクではデザインシステムがトークンレベルからシステマチックに整備され、デザインと実装に活用しています。このデザインシステムはエンジニアとデザイナーだけが用いるに留まらず、PM / リサーチャーも交えたプロトタイピングでも積極的に活用されています。スマートバンクにおけるプロダクトの設計プロセスに深く根差したものになっています。
デザインシステムに含まれるデザイントークンやコンポーネント群の iOS / Android アプリに組み込まれ、同等の機能やインターフェースを持ったUIコンポーネントをそれぞれ利用できる環境になっています。
ZStack / VStack / HStack ( Box / Column / Row) など子Viewのスタックを担うものを除けば、画面実装においてプラットフォーム固有のView群を直接用いる場面は限られます。強固なデザインシステムを通じて、UI実装における両プラットフォームの思考のスイッチングコストは最小限に抑えられている実感があります。
人力Multiplatform芸人がAI時代を生き抜く
ここまで iOS / Android の双方の実装を担当する上での思考プロセスやバックグランドを記してきました。ここからは少し話を転換して、AIツールの利活用へ向けたここ最近の思索を述べていきます。
両プラットフォームでの共有資産の積み上げは、もともと開発者体験の向上を目的として進めてきたものでした。しかし、これは結果としてAIツールの活用にもつながるものでないかと捉えています。
例えば、トークンレベルで整備されたデザインシステムは画面実装をUIコンポーネントから自動生成する際の力強い土台になり得ます。両プラットフォームの画面実装で用いるコンポーネントがある程度共通化されているのであれば、一方のプラットフォームからの変換も容易になります。また、設計指針の部分的な共有は、コード生成において提案の品質を一定保つのにも役立ちます。
私自身が「両プラットフォームを流動的に担いやすい」と感じる環境は、AIツールにとってもその効果を発揮しやすい環境であるはずです。
AIツールを一方のプラットフォームの開発者として捉える
DevinのようなAIツールを一方のプラットフォームの開発を補佐するバディとして捉えるのも面白いかもしれません。実装内容によっては一方のプラットフォームへの変換を指示することで、マルチプラットフォームツールを部分的に代替できる可能性も十分にあるでしょう。その際には明文化されたドキュメント資産をコンテキストとしてインプットする形で活用できます。
私たちのチームではプラットフォーム間の実装の変換を Devin に行わせることを試しています。知見が積み上がった際には改めて事例を紹介できればと思っています。
“一方のプラットフォーム” で完結しない組織構造を維持する
スマートバンクのモバイルアプリチームはまだまだ小規模なため、アプリ文脈でのすべての会議体は iOS / Android エンジニアの双方が参加しています。そのため議論の成果物としてのドキュメントやルールは自ずと iOS / Android の双方にもたらされることが多いです。
議論の場を一方のプラットフォームで完結させない構造を維持できていることは “共有資産の積み上げ” において大きな強みであったと感じています。AIツールの活用も見据え、チームが拡大していってもこうした共有の構造を意識的に維持できるかチャレンジしていきたいところです。
まとめ
このエントリーでは iOS / Android の両プラットフォームの実装を担当する上での考え方やアプローチ、そしてAIツールの利活用へ向けたここ最近の思索について述べてきました。
"人力Multiplatform芸人" としての矜持…がどれほど必要かはわからないですが、iOS / Android を俯瞰して捉えられる立場だからこそ持てる観点や思考があることは間違いないでしょう。AI時代において開発アウトプットを最大化する観点でも、両プラットフォームを越境した試行錯誤や積み上げた共有資産は重要なものとなっていくかもしれません。
スマートバンクでは一緒に B/43 …改め『ワンバンク』を創り上げていくメンバーを募集しています！カジュアル面談も受け付けていますので、お気軽にご応募ください 🙌
