ZonePane の CMP による iOS 版開発について

2025年6月〜8月にかけて実施した「ZonePane の iOS 版開発」における技術的な知見をまとめたものです。
レガシーな技術を比較的多く含むAndroidアプリの Kotlin Multiplatform / Compose Multiplatform (CMP) 構成への移行を行い、iOSへの移植を行った記録です。

備忘録的な側面もありますが、特にレガシーなAndroidアプリのKMP/CMP移行を検討されている方には、具体的な課題と解決策のヒントを提供できるかと思います。

AI（Cursor, Claude Code）も活用しましたが、特に大規模なリファクタリングや移行作業において、その効果を実感しました。

2010年に開発を開始したTwitter用アプリTwitPaneをベースとし、Mastodonに対応したアプリとしてZonePaneの開発が始まりました。2023年2月頃です。

その後、Misskey、Blueskyにも順次対応していきました。

アプリの構成

技術的なポイントとして、TwitPaneと同じソースコードを共有しながら複数のアプリを開発していることがあげられます。
具体的には1つのプロジェクト内に下記のアプリが存在します。

ビルドは下記のコマンドでAndroid版を生成できるようにしてあります。

Android版のZonePaneは Mastodon, Misskey, Bluesky に対応していますが、iOS版は2025年8月末時点では Bluesky にのみ対応しています。
(今後 MastodonとMisskey にも対応していく予定です)

なぜ Bluesky から対応したのか

iOS版を作るための技術として Compose Multiplatform (CMP) を前提としていますが、Android版は Mastodon と Misskey が Android View (RecyclerView) で、Bluesky が Compose (LazyColumn) で実装されており、CMP に一番近い構成で実装されている Bluesky が iOS に最短距離で対応ができる可能性が高いことから、まずは Bluesky から対応することとしました。

▼Android版の現状
   Mastodon : AndroidView+RecyclerView
   Misskey : AndroidView+RecyclerView
   Bluesky : Jetpack Compose+LazyColumn

▼iOS に対応するためには、、、
   AndroidView(RecyclerView) -> Jetpack Compose(LazyColumn) -> Compose Multiplatform(LazyColumn)
   という移行作業が必要

とはいえ Bluesky 部分も Compose 実装なのは「タイムラインの描画のみ」で、その周辺の「タップしたときのメニュー」や「いいねやリポスト等の確認画面」、アプリ自体のメイン画面や設定画面、投稿画面なども Android View で作られていることから、大幅に作り込む必要があります(ありました)。

いわば、フルCompose版のAndroidアプリを作り、それをSwiftからライブラリとして呼び出してiOS版を作るようなイメージです。ほとんど作り直しですね。

レイヤー構成

Android View (RecyclerView) + Compose (LazyColumn)
ViewPager + Fragment
ViewModel
Presenter
UseCase
Repository
domain
common

モジュール構成

common, domain が基本にあって、その上に shared/core, shared/ui_core, shared/core_compose などが載り、各種機能モジュール、ライブラリ、アプリが載る構成ですが、15年も維持しているアプリなのでまあカオスですね。。

CMP/iOS対応で core -> core+android_core や domain -> domain+android_domain のように Android 専用のモジュールが増えたりしていて、改めて整理する必要性を感じます。

ViewPager に載せる Fragment をアプリ内で「PagerFragment」と呼んでおり、これをまとめたモジュールを pf_bsky のように pf_* と称しています。

下記にモジュール構成の詳細を アプリ内のREADME.md より抜粋すて記載しましたが、長いので折りたたんでおきます。

各アプリの機能と移行・開発作業

Bluesky を対象に、何を移行し、何を作ったのかを整理してみます。

技術スタック

開発期間

iOS版の開発ということはXcodeでのビルドにMacが必要なわけですが、実は私自身Macの初心者でした。というわけで5月末にクロスポスト機能が完成間近のタイミングでMac mini(M4)を発注するところからのスタートでした。

※2010年代にMacBook Airを購入したこともありましたが数日触れただけでほとんど使わずに売り払いました。。

あ、基本的に土日も作業しています。途中のジョインアライブ、RSRの期間(計4日間)以外はほぼ休みなしです。

expect/actual一覧

expect/actual で iOS と Android の実装を分離するのが定番です。

expect/actual で実装した部分を一覧化することで 2025年夏時点における iOS/Android の実装分離ポイントが見えてくるかも。

※下記以外に、DIで実装を分離しているパターンなどもあります。

しんどかったこと

改めて振り返ってみて CMP / iOS 対応でしんどかったことをざっくりと書いてみます。

Mac導入

そもそもCmdキー主体の操作に慣れるまでしんどかった。
AndroidStudioはWindowsに合わせてCtrlキー主体のキー設定にカスタマイズして使い始めた。
Karabiner-Elementsも導入したり。

この3ヶ月のiOS版開発で、私自身のメインPC/開発環境も Windows11 から Mac に変化し、1995年から約30年間使い続けてきたWindowsとおわかれするという大変革となりました。まあWindowsマシン自体は経理とかでどうしても必要なので残してありますが(Macの)WindowsApp経由でリモートアクセスする使い方になっています。

build-logic / KMP 導入環境

まず最初にこれがしんどかった。
applicationやライブラリモジュール用の共通部分を buildSrc 配下に書いていて、groovyファイルのapplyで共通化してたんだけど、これがあることで KMP のプラグインが導入できなかった。
そこで(泣きながら)全部 Convention Plugin 化して対応した。

アイコン (フォントベースのアイコン -> Material Icon ベースに変更)

メニュー等に使用するアイコンがフォントファイルベースの https://github.com/takke/IconicDroid を使っていたんだけど、当然これはCMPで使えないので Material Icon のファイルを取り込んで使えるようにした。

地味にこの環境を整備するだけで半日くらいかかった。

文字列リソース

TwitPane時代から複数言語対応を前提にしていたので、KMP/CMP対応部分は Compose Resources を利用した文字列リソース参照に書き換え。

Android用の大量のコードがあるのでこれと2重管理になるのを避けるために、Compose Resources 用の文字列リソースを Android 用にコピーするタスクを作って管理するようにしたり。

文字列、正規表現

MatchGroup.range が ios, android にはあるけど他のプラットフォームにはなくてIDE上エラーになるのであえて expect/actual で回避した。

日付時刻の扱い

iOS 版だけなぜか 2055 年になったりした。instant.toNSDate() 等で回避。

と、その前に java.util.Date が使えないのでまず Instant が必要で、かつ開発期間中に Instant の移行(kotlinx.datetime.Instant -> kotlin.time.Instant)もあったりした。

AnnotatedString.fromHtml がない

気合いで実装。

(利用するタグの種類が a と br 程度だったので簡単なパーサを書いて AnnotatedString を構築した)

LinkedList -> ArrayList (mutableListOf())

ポストの表現にLinkedListを使っていたけどKMPにはないのでArrayListで。性能的にはまあ十分かな。

動画再生

https://github.com/Chaintech-Network/ComposeMultiplatformMediaPlayer を使わせてもらいました。

画像ビューア

https://github.com/usuiat/Zoomable を使わせてもらいました。

設定画面が全部View

気合いで作り直し。

ざっくり1つの設定だけ Claude Code に移行させて、自前で細かく修正してリファレンス実装を1つ作り、それと同様に Claude Code に実装してもらう、という流れで PLAN の md ファイルを作って・・・、まあ 2025年8月時点で Claude Code にお願いするときの定番の流れで。

DB層の作り直し

気合いで SQLDelight 化。

こちらも設定画面と同様に Claude Code とペアプロ。

ViewModel

Effect で個別の実装を Fragment/CMP で分離したり、Listener を最初は Fragment/CMP 用で大きく2つ用意してそれぞれが動作する状態を維持しながら徐々に統合していったり、、、

両対応にするための実装箇所をどこにすべきかはけっこう混乱するのでクラス図を用意したりして、
(ViewPagerに載せる)Fragmentを前提としたComposeのScreen+ViewModelを ViewPager/HorizontalPager 両対応に作り直すということを繰り返しました。

アプリ内の独自テーマ対応

iOSのダークテーマの扱いが全然分からなくて苦労した。

アプリ内の独自テーマシステムは結果的にはKMPに移行するだけ(ほぼディレクトリ移動のみ)だったんだけど、これが書き換わったりライト系・ダーク系テーマの切り替えをアプリ全体に反映するためにはどうするのか、、結局アプリの Compose 全体を key {} で囲むようなダサい実装になったんだけど、試行錯誤がしんどかった。

App Store 審査

審査に出したらいきなり4件も指摘されてびっくりして泣いちゃいましたが、いずれも真っ当な指摘だったので淡々と修正し、結果的には1往復で審査完了しました。

指摘されたのは、
・ストアの掲載内容
・アプリ内の機能について（2件）
・広告関連（IDFA関連）
でした。

15年ほどかけて作ったAndroidアプリ(の一部)をiOS対応したわけですが、こう振り返ってみてもやっぱり1人で3ヶ月でやる量じゃないと思います。

AI時代のスピード感は人間が疲弊するので用法用量を守って正しく使いたいものです。
(・・・あ、APIの上限のことじゃないよ。。)

AndroidアプリのCMP対応を考えている方の参考になれば幸いです。

さて、Mastodon対応はどうやろうかな・・・。