こんにちは！sugitaniと申します。ブラックキャット・カーニバル（略称ブラキャニ）というCompose Multiplatformで作られたSNSアプリを開発しています。
2024年12月に書いた
ではiOS/Android両対応のアプリを作る場合、Compose Multiplatformがベストだと思う理由を以下のように書きました
- マルチプラットフォームフレームワークは地殻変動と付き合っていく必要がある
- 地殻変動に対応するコストが払えないと問題が発生するし、実際Flutterですらコストが払いきれない問題が発生している
- Compose MultiplatformはAndroid方面だけは盤石で、万が一放棄されてもAndroid資産として残る
- iOS対応も問題ない品質が出せる今であれば、Compose Multiplatformの採用は検討に値するはずだ
- 理想はiOSもAndroidもフル開発だがコスト高い
- 半分は堅牢であるCompose Multiplatformはいい位置では？
本稿では、現状のCompose Multiplatformの状況と現時点の感想を述べます。
まずは2024年5月に公開したCompose Multiplatformを日本一レベルで使い込んだかもしれないので知見共有からの進化をまとめます
iOS対応がStable / Production-Readyになった！
2024/5の段階でも十分に戦える、2024/12の段階ならもう完全に戦える！…という完成度でしたが、半年間でもっと進化しました。
GCが進化して良い感じになった
Kotlin Multiplatformが進化して新しい方式のGCが使えるようになっています。
kotlin.native.binary.gc=cms
ブラキャニも正式リリース前に有効化しましたが、引っかかりがほぼ無くなりました。
該当の公式ドキュメント
ビルドがかなり早くなった
正確にはビルドキャッシュがかなり進化し、2回目以降のビルドがかなり快適になりました。
# https://kotlinlang.org/docs/native-improving-compilation-time.html#use-gradle-build-caching
org.gradle.caching=true
cacheは結構昔からあったもののiOSビルドで問題を起こしやすく kotlin.native.cacheKind=none を指定しないとビルドが通らないことが多かったのですが、ようやくKotlin 2.1.21 / CMP 1.8.1で安定した印象です。
Navigation / ViewModel が公式対応した
公式NavigationがiOSにも正式対応し、 PreComposeなどを使わなくてもよくなりました。スワイプバックなども自力で実装していましたが、いまは不用です。
Navigation自体も型安全なナビゲーションに対応したりと、使い勝手が大きく向上しています。
Android Studio/IntelliJ Ultimateでのプレビュー体験が向上
Common部分でもAndroid開発時と同様にプレビューが小細工無しで行えるようになりました。
KMM対応ライブラリの爆増
SQLiteラッパーのRoomや、 SharedPreferences強化版であるDataStoreがKMM対応し、データ永続化が簡単になりました
画像ライブラリのCoilや、DIフレームワークのKoinなどもKMM対応が正式リリースとなっています。
…
他にも
- iOSでの外部キーボード対応やアクセシビリティ対応が進みました
- 振動制御が細かく増えています
など沢山の改善があります
[参考] iOS26 / Liquid Glass対応はどうなるのか
Compose MultiplatformはUIKitと相互乗り入れが可能なので対応できます
先ほど書いたこの記事をご参照ください
Compose Multiplatformを採用してよかったのか
正式リリースしてから約半年となりますが、Compose Multiplatformを採用して本当によかったです。
- もともとJetpack Composeの書き味が良い
- ほとんどの場合でマルチプラットフォームの差異を気にしなくて良い
- プレビューが快適
- Android Studio(あるいはIDEA Ultimate)が快適
- 言い換えるとXcodeではないので最高
- Claude Codeとの連携も公式サポート！！
本業としてUIKit（一部SwiftUI) / ViewXML(一部Compose)のプロジェクトも並列で作業していますが、作業効率が桁違いすぎるので、Compose Multiplatformに統一してしまう計画になっています。
ネイティブや他のフレームワークと比較するとどうなのか
冒頭、あるいは前回の記事で述べたとおり、マルチプラットフォームは地殻変動との付き合いから逃れられず、今回はiOS26でのUI刷新という地殻変動が発生しました。Android側でもMaterial 3 Expressiveがやってきます。
全てをSkia/Impellerで描画する方針のFlutterではLiquid Glassに対応するのが難しく、即座の対応はしないようです。同様にMaterial 3 Expressiveにもしばらく対応しないようです（該当issue - 即座の対応作業は行っていない、アーキテクチャをどうするか検討している。という内容)
仮にFlutter一本槍で行く場合、ネイティブUIの要素を入れていきたい場合にNGというハンデを負うことになるので個人的にはFlutterは脱落したと考えています。
iOS/Android両対応のアプリを作る場合にどうすればよいか、は現時点では継続して以下の通りに考えています
- スキル維持の観点も含めて、採算が合うならばiOS/Android両方ネイティブで開発する
- 次点で地殻変動耐性とプロジェクト継続可能性を鑑み、Compose Multiplatformで開発する
以上です
この記事が、どなたかのお役に立てれば幸いです。
お読みいただきありがとうございました
以下宣伝
- コメントのしやすさともらいやすさに全力を注いだショートSNS ブラキャニ をお試しください
- ブラックキャット・カーニバル株式会社のPublicationではCompose Multiplatformに関する記事を沢山投稿しています
- Compose Multiplatformでアプリのバックグラウンド切り替えを検知するには
- Compose MultiplatformでコンポーネントをImageBitmapにするには
- Compose MultiplatformでKoinを使って環境別のDIを行う方法
- Compose Multiplatformでexpect/actialでContextをうまく扱う方法
- Compose Multiplatformで後から重ねられる&一部をくり抜いたコンポーネントを作るには
- Compose MultiplatformでImageBitmapとBitmap/UIImageを相互変換するには
- Compose MultiplatformでLiquid glass対応のタブ表示を行うには
Discussion