リリースから3か月たったアプリのダッシュボードを眺めながら、「そろそろ Max に上げるべきだろうか」と迷う時間が、私には定期的にやってきます。月25ドルと月200ドル。差額は年にすると2,100ドルで、個人開発の固定費としては軽くありません。それでも Rork Max のネイティブ Swift 生成や Apple 全機種対応には、はっきりした魅力があります。
迷いが長引く理由は単純で、判断材料を「気持ち」に置いているからです。憧れは毎週変動しますが、ダッシュボードの数字は嘘をつきません。この迷いを終わらせるために、私は移行判断を3つのトリガーに固定しました。同じ場所で迷っている方に向けて、その基準と、移行を決めたあとの段取りまでを書いておきます。
乗り換えない判断にも、根拠が要る
最初に決めたのは、「現状維持にも理由を言えるようにする」ことでした。Max に上げない理由が「高いから」だけだと、収益が伸びた瞬間に根拠が消えて、また迷いが始まります。逆に「上げる理由が3つのうち2つ揃っていないから」であれば、毎月同じ物差しで点検できます。
この物差しを作ってから、判断にかかる時間はほぼゼロになりました。迷うのは物差しがないときで、物差しの当て方で悩むことはほとんどありません。
段階移行という考え方 — 検証と本格化を同じ環境でやらない
前提として、私は Rork（Expo / React Native 基盤）と Rork Max を「同じものの上位互換」とは見ていません。役割が違います。
Rork の強みは、iOS と Android の両方へ同時に出せて、作り直しのコストが低いことです。つまりアイデアの検証に向いています。一方の Max はネイティブ Swift を生成し、ウィジェットや Live Activities、Core ML といった Apple の深い機能に届きます。これは検証が終わったアプリを本格化させる道具です。
検証が済んでいないアイデアを最初から Max で作り込むのは、私には順序が逆に見えます。当たるかどうか分からない段階で必要なのは深さではなく、出し直しの速さだからです。
Max へ上がる3つのトリガー
物差しは次の3つです。2つ以上が揃ったら移行を検討し、1つ以下なら据え置きます。
トリガー1: ネイティブ機能の壁に「実際に」ぶつかった
ウィジェットが欲しい、Apple Watch 対応が欲しい、という要望がレビューや問い合わせに実際に届いているかどうかです。数えるのは事実だけで、「あれば嬉しいはず」という想像上の要望は数えません。私の経験では、想像上の要望の大半は、実装しても使われません。
トリガー2: 収益が月額差を吸収している
差額は月175ドルです。私はこれに3倍の安全係数を掛けて、「そのアプリ単体の月間純収益が 差額の3倍を安定して超えているか」を見ます。広告でも課金でも構いませんが、リリース直後のスパイクは除いて、3か月の中央値で判定します。
トリガー3: iOS への偏りがデータで証明されている
DL と収益の7割以上が iOS なら、Apple 特化の価値があります。両 OS が五分に近いなら、Android を実質的に手放してまで Swift ネイティブへ寄せる理由は弱くなります。App Store と Google Play の比率は、想像ではなくストアのアナリティクスで確認します。
上がらない勇気 — Expo に留まる合理性
書いておきたいのは、多くの個人開発アプリはトリガーが2つ揃う日まで到達しない、ということです。それは失敗ではありません。
Expo 基盤には、OTA 更新で軽微な修正を即日届けられること、1つのコードベースで両 OS を保守できること、という地味で強い利点があります。ネイティブ機能の壁に最後までぶつからないアプリにとって、月200ドルは機能ではなく憧れへの支払いになります。固定費は一度上げると下げにくいので、「据え置きが既定、移行は例外」くらいの重心が、個人開発の資金繰りには合っていると私は考えています。
2026年6月の追い風 — 出口が増えて、いま決め切らなくてよくなった
この判断を今月あらためて整理したのは、状況が2つ動いたからです。
1つ目は、Android Studio に React Native プロジェクトをネイティブ Kotlin へ自動移行するエージェントが入ったことです。これまで「Expo を選ぶと Android ネイティブへの道は実質作り直し」でしたが、自動移行という逃げ道が見えたことで、Expo で始めるリスクがまた一段下がりました。
2つ目は、WWDC で Apple が Foundation Models を小規模開発者へ無償開放したことです（初回ダウンロード200万未満が対象）。AI 機能のためだけに Max へ急ぐ必要は薄れ、サーバー側から段階的に足す選択肢が現実的になりました。
どちらも方向は同じで、「最初の選択が将来を縛る度合い」が下がっています。検証は Expo で軽く、本格化の形は実績が教えてくれてから決める。段階移行の戦略は、今月さらに取りやすくなったと感じています。
移行を決めたときの実務 — 作り直しを資産に変える
トリガーが揃って移行を決めた場合、Max は Swift を生成するため、実態は移植ではなく再構築になります。ここで効くのが、検証期に貯めた実績の言語化です。
私が用意するのは3点です。まず、既存アプリの全画面スクリーンショットと画面遷移の一覧。次に、データ構造と保存項目の一覧（移行ツールではなく、エクスポートとインポートの手順として）。最後に、レビューで好評だった点と不満点の要約です。この3点があると、Max への指示は「前のアプリの再現」ではなく「実績を踏まえた改善版の要求仕様」になります。
ストア上の継続性も先に確認しておきます。同じバンドル ID で既存アプリの更新として出すのか、新アプリとして出し直すのか。レビュー資産と DL 実績を引き継ぎたいなら前者ですが、その場合は App Store Connect 側の設定と証明書まわりの引き継ぎを、移行作業の最初に検証しておくと後半で慌てません。
来月のダッシュボードで見る3つの数字
判断を運用に落とすなら、毎月見る数字は3つで足ります。iOS と Android の DL・収益比率。レビューと問い合わせに届いたネイティブ機能要望の件数。そのアプリ単体の月間純収益と175ドルの倍率。スプレッドシートの1行で済む記録ですが、半年分たまると、移行判断は迷いではなく作業になります。
同じ判断で立ち止まっている方の、物差し作りの参考になれば幸いです。