Kotlin Multiplatform の概要と、プロダクトに導入した感想

こんにちは、さとしです。

 

現在、参画している案件で、Kotlin Multiplatform を利用しました。

 

今回は、そこで得た知見を少し解説できればと思います。

 

 

• ・Kotlin Multiplatform の概要
• ・Kotlin Multiplatform を利用して大変だったこと
• ・まとめ
• ・さいごに

 

 

Kotlin Multiplatform の概要

Kotlin Multiplatformは、Kotlin 言語を用いてAndroid, iOS, デスクトップ, Webなどのマルチプラットフォームに対応するコードを実装できるツールのことです。

 

以前は Kotlin Multiplatform Mobile という名前で Android, iOS のマルチプラットフォームフレームワークとして存在していて、KMM と略されていました。

 

これがデスクトップ、Web対応され正式にリリースされた際に Kotlin Multiplatform に名称変更され、現在では KMP と略されています。

 

これまで iOS, Android の両OS でアプリを実装したいとなった時の選択肢として、iOS は Swift や Objective-C, Android は Kotlin や Android java を利用してそれぞれアプリを実装するやり方、もしくは Flutter や React Native などのクロスプラットフォームフレームワークを利用する方法がありましたが、Kotlin Multiplatform を利用することで、Kotlin オンリーで iOS 対応することが出来るようになります。

 

とはいえ、Kotlin Multiplatform ではあくまでロジックの部分までしか共通化できず、画面実装については引き続き Android, iOS でそれぞれの実装が必要になります。

 

こちらについても、現在 Compose Multiplatform というフレームワークが開発されており、2月7日現在、iOS がベータ版、Web 版がアルファ版となっています。

 

将来的には Compose Multiplatform と合わせて利用することで、画面実装も Kotlin オンリーで実装が可能になる見込みです。

 

 

Kotlin Multiplatform を利用して大変だったこと

Kotlin Multiplatform を利用していて大変だったことは、共通化できなそうな実装に対する対応でした。

 

具体的には、このままでは共通化出来ないとなった時に、なんとか共通化しようとするか、あきらめて OS ごとにコードを実装するかの選択に迷うことが多かったです。

 

この話をするにあたっての前提として、Kotlin Multiplatform では、ロジックを格納するモジュールが3つ存在します。

 

・Android, iOS で共通のロジックを格納する Shared モジュール

・Android 側で利用するロジックを格納する AndroidMain モジュール

・iOS 側で利用するロジックを格納する iOSMain モジュール

 

その他に、AppleMain や LinuxMain といったモジュールもありますが、ここでは割愛します。

 

共通化できるコードは Shared モジュールに実装し、共通化できないコードは Shared モジュールに expect 修飾子を付けて定義を実装し、 AndroidMain, iOSMainモジュールにactual 修飾子を付け、共通化できない具体的な実装を行うことになります。

 

expect, actual については、公式ドキュメントにも説明がありますのでそちらを参考にしてください

 

Expected and actual declarations（Kotlin 公式ページ）

 

 

例として、実際に困ったことを3つ紹介します。

 

1. Java 系のライブラリが使えなかった

 

共通化するコードを実装する先の Shared モジュールには、 Java に依存するコード、ライブラリを利用できない制約があります。

 

理由はビルドにあり、ビルド時にAndroid側は、JVM 上で動作する Java バイトコードへコンパイルされるため、Java ライブラリを利用することができます。

 

一方でiOSなどの他OSでは、Kotlin/ Native というツールによってJVMなどの仮想マシンなしで実行できる形にコンパイルされるためです。

 

これにより、特に java.util 系のライブラリが利用できなかったことで、代替となる Kotlin のライブラリを調査することが多く、実装後も微妙な実装差異による不具合が発生しました。

 

代替となるライブラリがある場合は、それを使う選択肢もありますが、ない場合は expect, actual を利用して OS ごとの実装を選択することになります。

 

 2. いつも利用しているライブラリが Kotlin Multiplatform をサポートしていないことがあった

 

Android 開発を行う上で、いつも使っているライブラリが Kotlin Multiplatform をサポートしていないことが多かったということが、２つ目の大変なことでした。

 

例えば、Android ではAPI通信で使われることが多い Retrofit, DI で使われる Dagger, DaggerHilt はサポートされておらず、それぞれ Ktor, Koin といったライブラリで代用しました。

 

一方で、使い慣れているライブラリから離れて新しいライブラリの知見に触れることができたことは、Kotlin Multiplatform の実装を経て得た知見の一部となっています。

 

 3. OS に依存した機能が利用できない

 

例えば、Lifecycle や Context は Android に依存した機能でありiOSなど他のOSでは利用できないため、Sharedモジュールで実装することができません。

 

そういった機能を利用する場合は、Sharedモジュールでは expect 関数として抽象的に定義し、それぞれの AndroidMain, iOSMain モジュールで actual 関数を定義し、具体的な実装を行うことになります。

 

一方で、OS に依存するコードを除外して共通化するという実装方法もあります。

 

今回は、基本的にはロジックのリファクタリングした上で、共通化する方針で実装しました。

 

OS 毎に外部SDK を実装しており、ロジックから SDK のコードを除外出来ないということがあったため、そちらはKMP化を断念しました。

 

 

まとめ

Kotlin Multiplatform は、Kotlin だけで Android, iOS, Web, デスクトップアプリのコードを実装することができるツールのことです。

 

現状はロジックの共通化のみ安定版としてリリースされており、画面実装を共通化できる Compose Multiplatform はまだ安定版はリリースされていない状態です。

 

KMPをサポートしているライブラリがまだそれほど多くなく、代替となるライブラリを利用するか、ライブラリを自作する必要があります。

 

近い将来、Compose Multiplatform というツールが安定版となることで、画面実装までワンストップでKotlin のみで実装できるようになるため、よりKMP を利用することによる省コード化が期待できます。

 

さいごに

 

EMoshU アプリチームでは、一緒にアプリチームを盛り上げてくれるアプリエンジニアを募集しております。

 

・今の会社・環境では、現場が変わると人間関係がリセットされてしまい、新しく人間関係を築き続けるのに疲れる。寂しい

・一緒にワイワイ開発出来る仲間が欲しい！

・チームを強くする経験を積みたい！

 

という方、ぜひ募集要項をご覧ください。カジュアル面談なども実施しております。

アプリ開発で世の中に貢献したい方、ぜひご応募ください！！

 

募集要項

• iOSエンジニア
• Androidエンジニア
• サーバーサイドエンジニア
• ディレクター
• エンジニアインターン