SOELUでモバイル開発をしている@yutaabe200です。 今回SOELUの両モバイルネイティブアプリにKotlin MultiplatformのSharedModuleを導入しましたのでそれに関して諸々お話しできればと思います。
KMP SharedModuleの導入
SOELUではiOS/AndroidアプリをそれぞれSwiftとKotlinでネイティブで開発しています。 APIが関連する機能の追加もしくは変更があった場合に、細部ですがレスポンスの使用方法などの実装差異が少なからず発生してしまうケースが稀にありました。
また当然ですがAPI側(サーバーサイド側)の開発チームと実装進捗などコミュニケーションが必要になる場合もあり、そこを調整する人材とそれを使って実装する人材と伝言ゲーム式にコミュニケーションが都度必要になったりとしており、それぞれのプラットフォーム別チームの連携をよりシームレスにそしてさらに最小限のコストで実現することを目指して導入に踏み切りました。
初期導入に際して目指している構成は以下の通りになります。
本来であればビジネスロジックを担っているいわゆるドメイン層と言われる箇所もSharedModuleに閉じ込めてしまいたかったのですが、Android/iOSでリリース時期に差があり、機能レベルで実装差異もあったりと歴史的背景から最小構成での導入にとどめ、継続して運用できることに重点をおき環境の整備の方にまずは注力しています。
主に環境レベルでいうとSharedModule自体はどちらのMain Appからは切り離しMaven/Swift Package Manager経由で参照する形式を取るため、APIの動作環境自体を担うDebugアプリを作成しDebug アプリと同じプライベートのGitリポジトリで管理するようにしています。
これによりそれぞれの純ネイティブエンジニアでも通常通りのネイティブ開発の体験を維持することができ、Kotlinの文法を細部まで知らない場合でもAPI RequestをSharedModule(Kotlin)で作成し、使い慣れたiOSアプリですぐに動作検証ができる状態を実現しています。
KMPのSharedModuleを選定することで従来のネイティブ資産の維持が可能で、かつ最小構成での導入・設計により万が一切り離そうと思えばフルスクラッチでなくて済むなどの利点もあり、さらにView層までKMPに依存せずに済むというメリットが大きいです。
SOELUではiOS/AndroidそれぞれでとってもUXの細かな検証や変更など数多く行っており、それがフレームワークによる制約によって制限されるということはまず技術選定から外されるものでした。 またヘルスケアカテゴリという観点から見ても、今後の方針でスマートフォンのネイティブ機能や外部連携など特殊な要件も平気で出現することは想定の範囲にしておくべきでしたので、新たなネイティブ機能が発表後にすぐに専用のAPIがサポートされる保証のないクロスプラットフォームフレームワークを利用した場合に残る懸念点をKMP SharedModuleで払拭することができたと考えています。
またこれに調査から導入までご協力いただいた業務委託メンバーにもこの場を持って改めてお礼させていただきます🙇♂️🙇♂️
直近のリリースでは一部の影響範囲の少ない箇所から導入をしていますが、これから全エンドポイントに適用する準備も整ってきたので順次移行して行きます。
完全移行後やSharedModuleが抱える範囲の拡大など次の段階にきたらまたその辺りも踏まえてどこかでお話しできればと思います。
※KMMと言う略語を使用していましたが公式より以下の通り今後はKMPで統一していく方針が出されたのでKMPと統一しています。
TL;DR: To resolve the long-standing issues of naming inconsistency and abbreviation confusion that have puzzled many Kotlin developers over the past two years, we are deprecating the “Kotlin Multiplatform Mobile” (KMM) product name. From now on, “Kotlin Multiplatform” (KMP) is the preferred term when referring to the Kotlin technology for sharing code across different platforms, regardless of the combination of targets being discussed.