Kotlin Multiplatform（KMP）とは｜Flutterとの違いと案件動向
最終更新日：2026/11/08
Kotlin Multiplatform（KMP）とは、Kotlinで書いたコードをAndroid・iOS・デスクトップ・サーバーなど複数のプラットフォームで共有する技術です。UIをネイティブのまま残すか、Compose MultiplatformでUIごと共有するかを選べます。Flutterとどう違うのか、既存アプリに後から入れられるのかを、公式の安定性ステータスと、公開案件で見られる募集要件の傾向から整理します。
先に結論
KMPは「UIフレームワーク」ではなくコードを共有するための仕組み。UIはネイティブのまま残せる
FlutterはUIごと1つのコードベースに寄せる思想、KMPは共有する範囲を自分で選ぶ思想
既存のAndroid／iOSアプリに機能単位で後から足せるのがKMP最大の実務的な利点
2026年11月時点の公式ステータスでは、Android・iOS・デスクトップ・サーバーサイドがStable。UI共有のCompose MultiplatformもAndroid・iOS・デスクトップがStable（WebのみBeta）
公開案件ベースでは、「KMP専任」よりAndroid案件やモバイルアプリ案件のスキル要件としてKMPが挙がる形が目立ちます
この記事でわかること
KMPの仕組みと、Compose Multiplatformとの関係
共有範囲を4段階で選ぶという考え方（このページ独自の整理）
KMPとFlutterを、言語・UI・既存アプリへの導入しやすさで比較した結果
チーム構成別にどちらを選ぶかの判断フロー
フリーランスエンジニアがKMP案件に入る前に確認しておきたいこと
対象は、Android／iOSのアプリ開発経験がある方、またはKotlinを業務で触ったことがある方です。Kotlinという言語そのものの文法や年収についてはKotlinとは？特徴から年収、将来性について解説で扱っています。
目次
Kotlin Multiplatformとは｜「ロジックだけ共有」という考え方
KMPで「どこまで共有するか」は4段階で選べる
KMPとFlutterの違い｜UI・言語・導入の仕方で分かれる
対応プラットフォームと安定性ステータス
チーム構成別｜KMPとFlutterの選び方
導入事例｜海外と国内の採用状況
フリーランスエンジニアから見たKMP案件
導入でつまずきやすいポイント
学習の進め方
まとめ
よくある質問
Kotlin Multiplatformとは｜「ロジックだけ共有」という考え方
KMPは、Kotlinで書いた共通コードを各プラットフォーム向けにコンパイルする技術です。JetBrainsが開発し、公式サイトでは「ネイティブプログラミングの利点を保ったまま、複数プラットフォーム向けのアプリを作りコードを効率よく再利用する技術」と定義されています（Kotlin Multiplatform 公式）。
ポイントは、FlutterのようにUI描画まで独自エンジンへ寄せるのではなく、共通コードをビルドの段階で各プラットフォーム向けの成果物にコンパイルして使う点です。Androidなら Kotlin/JVM（JVM向けにバイトコードを出力する構成）、iOSなら Kotlin/Native（ネイティブバイナリを出力する構成）、ブラウザ向けなら Kotlin/JS（JavaScriptを出力）や Kotlin/Wasm（WebAssemblyを出力）というように、同じソースから別の成果物が出てきます。
共有されるのは主にロジック層
共有しやすいのは、通信処理・データモデル・バリデーション・永続化・状態管理といった、画面に依存しない部分です。逆に、画面遷移のアニメーションやOS固有のUI挙動は、無理に共有しないほうが結果的に早く仕上がります。
Googleも公式に「AndroidとiOS間でビジネスロジックを共有する方法としてKMPを正式にサポートしている」と明記しています（Kotlin Multiplatform｜Android Developers）。これはGoogleによるサポート表明であり、「安定版かどうか」の判断はKotlin公式が公開しているプラットフォーム別の安定性ステータス（後述）で別途確認してください。JetBrainsとGoogleの双方が後ろ盾になっている点は、技術選定の説明材料として使えます。
expect と actual でプラットフォーム差を吸収する
共通コードからOS固有のAPIを呼びたい場面は必ず出てきます。端末IDの取得、ファイルの保存先、日時の書式などです。
KMPではこれを expect / actual という仕組みで扱います。共通コード側で「こういう関数があるはず」と expect で宣言だけしておき、Android側とiOS側でそれぞれ actual として実装を書く。呼び出し側は差を意識せずに済みます。関数だけでなくクラス・インターフェース・プロパティにも使えます（Use platform-specific APIs｜Kotlin公式）。
もう一つ、共通コード側でインターフェースだけ定義し、実装をDI（Dependency Injection、依存性注入）で差し込むやり方もあります。テストのしやすさを重視するならこちらが扱いやすい場面もあります。
KMPとCompose Multiplatformは別物
ここを混同したまま比較記事を読むと話が噛み合わなくなります。
名称 | 役割 | 必須か |
|---|---|---|
Kotlin Multiplatform（KMP） | コードを共有するための基盤技術 | KMPを使うなら必須 |
Compose Multiplatform（CMP） | KMPの上に乗るUIフレームワーク | 任意。使わなくてもKMPは成立する |
公式サイトでも「Compose MultiplatformはKotlin Multiplatformの上に構築されたオプションのUIフレームワーク」と説明されています。つまり KMPだけ使ってUIはネイティブ、という構成が成立する。これがFlutterとの最大の分岐点です。
ミニFAQ
KMMという呼び方は今も使う？
かつてモバイル向けの呼称として Kotlin Multiplatform Mobile（KMM）が使われていましたが、現在はモバイル以外も含めて Kotlin Multiplatform（KMP）に名称が統一されています。古い記事やライブラリ名にKMMが残っていることがあります。
Kotlinが書ければすぐ始められる？
Androidの経験があるKotlinエンジニアなら共通コード側はすぐ書けます。詰まるのはiOS側のビルド設定とXcodeまわりで、ここは別のハードルと考えておいたほうが安全です。
KMPで「どこまで共有するか」は4段階で選べる
結論から言うと、KMPの導入は「全部か無か」ではありません。共有する範囲を自分で決められるのがFlutterとの思想差です。
以下は公式の分類ではなく、実務上の導入範囲を本記事で4段階に整理したものです。案件や組織によって中間的な形もあります。
段階 | 共有する範囲 | UIの書き方 | 向いているケース |
|---|---|---|---|
段階1 | 通信・データモデルのみ | Android＝Jetpack Compose／iOS＝SwiftUI（各ネイティブ） | 既存アプリに試験導入したい |
段階2 | 段階1＋永続化・状態管理・ドメインロジック | 各ネイティブ | 二重実装のバグを減らしたい |
段階3 | 段階2＋UIの大部分（Compose Multiplatform） | CMPで共通化、一部だけネイティブ | 新規開発で画面も揃えたい |
段階4 | UIを含めほぼ全体 | CMPで共通化 | 単一チームで全プラットフォームを見る |
段階1から始めて、問題が出なければ2へ広げる。この段階的な拡大ができる点が、実務でKMPが選ばれる理由として挙がります。実際、McDonald'sは最初に支払い機能だけをKMPで共有し、のちに適用範囲をアプリ内のより広い領域へ拡大したと公式サイトの事例で紹介されています。
既存アプリに後から入れられる
新規開発ではなく、すでに動いているAndroid／iOSアプリを抱えている場合、これは大きな差になります。
KMPの共有コードは、Android側ではライブラリとして、iOS側ではフレームワークとして取り込まれます。アプリを作り直す必要がありません。「次の機能追加の分だけ共通化する」という進め方ができます。
一方、Flutterにも既存のネイティブアプリへ部分的に組み込む構成（Add-to-App）が公式に用意されています。ただし組み込みの単位が画面やビュー単位になりやすく、ロジック層だけを差し替えられるKMPとは導入の粒度が異なります。
KMPとFlutterの違い｜UI・言語・導入の仕方で分かれる
まず短答です。Flutterは単一コードベースでUIまで含めて作る、KMPは共有範囲を選びながらUIはネイティブに寄せられる。どちらが優れているかではなく、何を揃えたいかで決まります。
Flutterは公式に「単一のコードベースから、美しくネイティブコンパイルされたマルチプラットフォームアプリを構築するオープンソースフレームワーク」と定義され、言語はDartです（Flutter 公式）。UIは独自のレンダリングで描画するため、全プラットフォームで同じ見た目になります。
比較表
観点 | Kotlin Multiplatform | Flutter |
|---|---|---|
言語 | Kotlin | Dart |
位置づけ | コード共有の基盤技術 | UIフレームワーク |
UIの作り方 | ネイティブUIのまま／CMPで共有も選べる | Flutterのウィジェットで共通化 |
見た目の統一 | ネイティブUIならOSごとに差が出る | 全プラットフォームで揃いやすい |
既存アプリへの追加 | ロジック単位で段階的に追加できる | 画面単位での組み込みが中心 |
OS固有APIの呼び出し | expect/actualで共通コードから直接 | プラットフォームチャネル経由 |
必要なチームスキル | Kotlin＋各ネイティブの知識 | Dart中心 |
Web・デスクトップ | KMP本体はWeb（Wasm）がBeta、デスクトップはStable | Web・デスクトップ・組込みに対応 |
この表はKMP側の選択肢の広さを示すために粒度を揃えたもので、Flutter側も要件ごとに事情が変わります。Web・デスクトップ・組込みは「対応している」ことと「その要件で十分に成熟している」ことが別のため、Flutterを選ぶ場合も公式のサポート状況を個別に確認してください。
Flutterそのものの特徴・案件動向はFlutterとは？React Native・Kotlin・Swiftとの違い・案件単価をフリーランス視点で解説に、言語側のDartについてはDartとは？特徴・用途からFlutterとの関係・年収・将来性まで解説にまとめています。
UIを共有したい場合はCompose Multiplatformとの比較になる
KMPで段階3以上を選ぶなら、比較相手はFlutterのUI層とCompose Multiplatformになります。
JetBrainsは2025年5月のCompose Multiplatform 1.8.0でiOS向けをStableとし、本番利用可能と発表しました。同リリースの公式アナウンスでは、起動時間はネイティブアプリと同等、スクロール性能は高リフレッシュレート端末でもSwiftUIと同程度、iOSアプリのサイズ増加はフルネイティブのSwiftUI構成と比べて約9MBと説明されています（Compose Multiplatform 1.8.0 Released｜JetBrains Blog）。
この約9MBはJetBrainsが特定の比較条件で示した数値であり、実際の増加量はアプリ構成・ビルド設定・利用ライブラリ・対象アーキテクチャによって変わります。容量制約が厳しいアプリでは、自分たちの構成でビルドして実測したうえで判断してください。
ミニFAQ
KMPを入れるとiOSエンジニアの仕事は減る？
段階1〜2ならUIはSwiftUI／UIKitのままなので、iOS側の実装はむしろ本来のUI設計に集中できます。SwiftUIとは｜UIKitとの違い・できること・案件動向を解説も合わせて参照してください。段階3以上でCMPを採用する場合は役割が変わるため、着手前にチーム内で合意を取る必要があります。
対応プラットフォームと安定性ステータス
技術選定で最初に聞かれるのが「本番で使って大丈夫か」です。ここは推測ではなく公式の安定性レベルを見るのが確実です。
Kotlin公式のサポートプラットフォーム一覧では、次のように整理されています（いずれも2026年11月時点で確認した内容です）。
KMP本体の安定性レベル
ターゲット | ステータス |
|---|---|
Android | Stable |
iOS | Stable |
デスクトップ（JVM） | Stable |
サーバーサイド（JVM） | Stable |
Web（Kotlin/JS） | Stable |
Web（Kotlin/Wasm） | Beta |
watchOS | Beta |
tvOS | Beta |
Compose Multiplatformの安定性レベル
ターゲット | ステータス |
|---|---|
Android | Stable |
iOS | Stable |
デスクトップ（JVM） | Stable |
Web（Kotlin/Wasm） | Beta |
公式の定義では Stable は「本番環境での使用に適しており、厳密な後方互換性ルールに従う」、Beta は「ほぼ完成しており使用可能だが、変更の可能性がある」とされています。つまりモバイル2プラットフォームに関しては、KMPもCMPも本番利用の前提が整っている状態です。
ただしWebを含める構成は話が変わります。Kotlin/WasmがBetaである以上、Web対応まで1つのコードベースで賄いたい要件では、安定版を求めるならKotlin/JS構成を検討するか、Web側を別構成にするかの判断が必要です。FlutterのWeb対応を選択肢に入れる場合も、求める機能・性能要件に対して十分かは個別に検証してください。
なおバージョン番号は更新が速いため、着手時にはCompose Multiplatform 公式で最新版と対応状況を確認してください。本記事の記載は執筆時点のものです。
チーム構成別｜KMPとFlutterの選び方
技術の優劣より、今いるメンバーの構成で決まることのほうが実務では多いです。4つのケースに整理しました。
ケース1｜既存のAndroid／iOSネイティブアプリがある
KMPが向きます。アプリを作り直さずに済むからです。
まずは新規機能のAPIクライアントとデータモデルだけを共通化し、片方のOSで出たバグがもう片方にも同じように存在する、という状態を減らすところから始めます。既存資産を捨てる判断が不要なため、社内の合意も取りやすい。
ケース2｜ゼロから新規開発・少人数チーム
Flutterが向く場面が多くなります。UIまで含めて1つのコードベースで済み、人数が少ないほど恩恵が大きいためです。
ただし、メンバーがKotlin中心でDart未経験ならKMPとCompose Multiplatformの組み合わせも候補になります。学習コストをどちらに払うかの問題です。
ケース3｜Android寄りのチームでiOSも出したい
KMPが有力です。Kotlinの資産と知識をそのまま使えます。
Android側はAndroidJavaとは？Kotlinとの違いや年収、将来性について解説で触れているとおりKotlinが主流になっており、そこからの延長で共通化に入れるのは現実的な進め方です。iOS側の知見が薄い場合は、段階1から入って徐々に広げるほうが事故が少ない。
ケース4｜Web・デスクトップまで広げたい
要件次第です。デスクトップまでならKMPもCMPもStableのため、Kotlin資産を活かす構成が取りやすくなります。Webを含めるならKotlin/WasmがBetaであることを前提に判断します。
Webまで含めて1本化する優先度が高いなら、Flutterや、React Nativeとは？特徴・Flutter/Swift/Kotlinとの違い・案件単価をフリーランスエンジニア視点で解説で扱っているReact Native系（開発体験を補うExpoとは｜React Nativeとの違いと開発を効率化する仕組みを含む）も比較対象に入ります。
導入事例｜海外と国内の採用状況
事例は技術選定の説明材料になります。公式サイトと各社の技術ブログで公開されているものを挙げます。
海外の事例
Kotlin Multiplatform 公式サイトでは、以下が事例として紹介されています。
企業 | 共有した範囲 |
|---|---|
Forbes | ロジックの80%以上を共有 |
McDonald's | 支払い機能から導入し、のちに適用範囲を拡大 |
Duolingo | アプリ全体で継続的に適用範囲を拡大 |
Sony | ヘッドフォン対応アプリ（バックグラウンド実行・センサー統合を含む） |
Booking.com | ビジネスロジックを共有する実験的ライブラリ |
Forbesの「80%以上」という数字は、ロジック層に絞った共有でもここまで届くという目安として参考になります。
国内の事例
国内でも技術ブログでの公開が見られます。CyberAgentはABEMAでのマルチプラットフォーム対応について開発者ブログで、エムスリーは共通コードからプラットフォーム固有実装を扱う2つのアプローチについてテックブログで、それぞれ実装上の判断を公開しています。asoviewもKMPとCompose Multiplatformを使った開発について技術ブログで報告しています。
これらは各社が自社の採用を説明した一次情報にあたります。業界全体の採用率を示すものではない点には注意してください。
フリーランスエンジニアから見たKMP案件
案件はどう出てくるか
2026年11月時点で複数のフリーランス向け案件サイトの公開求人を確認した範囲では、「KMPエンジニア募集」という形で単独で立つ案件は多くありませんでした。Androidアプリ開発案件やモバイルアプリ開発案件の歓迎スキル・必須スキルの一項目としてKMPが挙がる形が目立ちます。非公開案件を含む市場全体の比率を示すものではないため、傾向として受け取ってください。
そのため、案件の探し方としてはKMP単体で絞り込むより、Kotlin・Androidで絞ってから要件にKMPやマルチプラットフォーム対応が含まれるものを拾うほうが現実的です。Kotlinの案件はKotlinの案件一覧から確認できます。
求められるスキルの組み合わせ
レイヤー | 求められること |
|---|---|
共通コード | Kotlin、コルーチン、Ktorなどのマルチプラットフォーム対応ライブラリ |
Android | Jetpack Compose、Gradleのビルド設定 |
iOS | Swift／SwiftUIの読み書き、Xcodeでのビルドとデバッグ |
横断 | ライブラリ選定、既存アプリへの組み込み設計 |
実際に重宝されるのは、AndroidとiOSの両方の事情がわかり、どこまで共有するかを設計できる人です。共通コードだけ書ければ足りる案件は少なく、iOS側のビルドで詰まったときに自分で切り分けられるかどうかが効いてきます。
単価の考え方
単価はKMPかどうかではなく、Android／iOSアプリ開発者としての経験年数と担当範囲で決まる部分が大きくなります。レンジの目安は職種・言語別にまとめているため、そちらを参照してください。
自分がどのくらいの単価を狙えるか気になる方は、無料のフリーランスエンジニア単価診断で現在の市場単価の目安を確認できます。単価を体系的に上げる考え方は【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？で整理しています。
参画前チェックリスト
KMPを使っている案件は、どの段階で導入しているかによって仕事の中身がまったく変わります。面談で次の点を確認しておくと、入ってからのギャップが減ります。
共有しているのはどのレイヤーか（通信だけか、UIまで含むか）
Compose Multiplatformを使っているか、UIはネイティブのままか
新規開発か、既存アプリへの後付けか
iOS側のビルド・リリースは誰が担当しているか
自分の担当は共通コードだけか、各OSの実装も含むか
iOSエンジニアがチームにいるか（いない場合、Swift側の責任範囲はどこまでか）
CI上でiOSビルドが回っているか
4番と6番は特に効きます。共通コードだけの担当だと聞いていたのに、実際はiOS側のビルド崩れまで見ることになった、という話は起こりがちです。案件選びの優先順位の付け方は案件の選び方｜フリーランスエンジニアが単価・稼働・スキルで決める優先順位にまとめています。
導入でつまずきやすいポイント
iOS側のビルドとデバッグが重い
共通コードの変更をiOSで確認するには、Kotlin/Nativeのコンパイルを挟みます。Androidだけを触っていた感覚に比べると、確認までの待ち時間は長くなります。
対策としては、ロジックのテストを共通コード側のユニットテストで完結させ、実機確認の回数を減らすことです。iOSを開いて確かめる作業は最後に寄せる。
ライブラリをマルチプラットフォーム対応のものに揃える必要がある
共通コードからはAndroid専用のライブラリを呼べません。通信ならKtor、シリアライズならkotlinx.serialization、というようにマルチプラットフォーム対応のものを選ぶことになります。
既存のAndroidアプリから移す場合、ここで使っているライブラリの置き換えが発生します。移行の見積もりで見落とされやすい工数です。
iOSエンジニアの合意形成
技術的な問題より難しいことがあります。iOS側から見ると、自分の読めないKotlinのコードがアプリの中核に入ってくるためです。
段階1から始めて効果を見せる、共通コードのレビューにiOSエンジニアも入る、といった進め方のほうが定着しやすい。KMPの導入は技術選定であると同時に、チームの分担をどう引き直すかの話でもあります。
学習の進め方
順序
Kotlinの基本文法とコルーチン（Android経験があれば既習の範囲）
KMPプロジェクトの構成（commonMain／androidMain／iosMain のソースセット）
expect / actual によるプラットフォーム固有実装
Ktorなどマルチプラットフォーム対応ライブラリの使い方
iOSフレームワークとしての出力とXcodeからの呼び出し
必要に応じてCompose Multiplatform
3番まで理解できれば、段階1の共有は現場で書けるようになります。5番でつまずく人が多いので、ここだけは実際に手を動かして一度通しておくほうがよいでしょう。
公式リソース
まとめ
KMPは「共有する範囲を自分で選べるコード共有技術」であり、UIまで一本化するFlutterとは選定の軸がそもそも違います。 既存のネイティブアプリがあるならKMP、ゼロから少人数で作るならFlutterという分かれ方になりやすい。
KMPはコード共有の基盤、Compose Multiplatformはその上に乗る任意のUIフレームワーク
共有範囲は4段階で選べる。段階1（通信・データモデル）から始めれば既存アプリにも後付けできる
2026年11月時点の公式ステータスでは、Android・iOS・デスクトップ・サーバーサイドがStable。Web（Wasm）はBeta
Compose MultiplatformのiOS対応は2025年5月の1.8.0でStableとなり、アプリサイズ増加は特定条件下で約9MBと公表されている（構成により変動する）
公開案件ベースでは、Android／モバイルアプリ案件のスキル要件として現れる形が目立つ。Kotlin・Androidで絞って探すほうが見つけやすい
参画前には「どの段階で導入しているか」「iOS側の担当は誰か」を必ず確認する
次のステップとしては、段階1の構成でサンプルを1つ通してみることをおすすめします。共通コードからAPIを叩き、AndroidとiOSの両方で表示するところまで。ここまで動かせれば、案件の要件を読んだときに自分の守備範囲が判断できるようになります。
参照した一次情報は以下のとおりです。
よくある質問
KMPとFlutterはどちらを学ぶべきですか
今の立ち位置で決まります。Android開発の経験があり、Kotlinを業務で使っているならKMPのほうが学習コストは小さく、既存の経験が活きます。モバイル開発自体がこれからで、小規模に個人開発もしたいならFlutterのほうが完成までの距離は短くなります。
KMPを使うとiOSアプリの動作は遅くなりますか
共通コードはKotlin/Nativeでネイティブバイナリにコンパイルされるため、ロジック層の共有による性能上の不利は大きくありません。UIにCompose Multiplatformを使う場合も、JetBrainsは1.8.0の発表でスクロール性能はSwiftUIと同程度と説明しています。要件が厳しいアプリでは、実機で計測して判断してください。
既存のAndroidアプリにKMPを後から入れられますか
入れられます。共通コードをモジュールとして切り出し、Android側はライブラリとして参照します。全面的な書き換えは不要です。むしろ新規機能から少しずつ移すほうが一般的な進め方です。
KMPとCompose Multiplatformはどちらか片方だけ使えますか
KMPだけを使い、UIはJetpack ComposeとSwiftUIで別々に書く構成は成立します。逆にCompose MultiplatformはKMPの上に構築されているため、CMPだけを単独で使うことはできません。
KMPの案件はどこで探せばよいですか
KMP単独で募集が立つことは多くないため、KotlinやAndroidの案件を見たうえで、要件にマルチプラットフォーム対応が含まれるものを確認する探し方が現実的です。Kotlinの案件一覧やフリコンの案件一覧から条件を絞って確認できます。
iOSの知識がなくてもKMP案件に入れますか
共通コード専任の役割であれば可能性はありますが、実務ではiOS側のビルドで止まったときに切り分けが必要になります。最低限、Xcodeでプロジェクトを開いてビルドし、エラーメッセージを読める程度は求められると考えておいたほうが安全です。参画前チェックリストの4番・6番で担当範囲を確認してください。
Kotlin/WasmがBetaなら、Web対応には使わないほうがよいですか
公式のStable定義は「本番環境での使用に適する」ですが、Betaは「変更の可能性がある」とされています。社内ツールや検証段階のプロダクトなら選択肢になります。長期運用する顧客向けのWebが要件の中心なら、別の手段と比較したほうがリスクは小さくなります。
KMMとKMPは別の技術ですか
同じものです。モバイル向けの呼称だったKotlin Multiplatform Mobile（KMM）が、対象の広がりに合わせてKotlin Multiplatformに統一されました。古い資料ではKMMの表記が残っています。
Compose MultiplatformとJetpack Composeの関係は何ですか
Jetpack ComposeはAndroid向けの宣言的UIツールキットで、Compose MultiplatformはそのAPIをiOS・デスクトップ・Webにも広げたものです。Jetpack Composeを書いた経験があれば、記述のしかたはほぼそのまま通用します。
アプリのサイズはどのくらい増えますか
JetBrainsは1.8.0の発表で、Compose Multiplatformを使ったiOSアプリは、フルネイティブのSwiftUI構成と比べて約9MB増えると説明しています。これは特定の比較条件での数値で、実際の増加量はアプリ構成・ビルド設定・利用ライブラリ・対象アーキテクチャによって変わります。ロジック層のみの共有であれば増加はこれより小さくなる傾向ですが、配信サイズの制約がある場合は自分たちの構成でビルドして実測してください。
1人で全プラットフォームを担当する案件はありますか
あります。ただしその場合、KMPの知識だけでなくAndroid・iOSそれぞれのリリース作業まで含まれることが多くなります。報酬が見合うかは担当範囲とセットで判断してください。
