WWDC 2026 が閉幕した今週、Rork について私のところへ届いた質問で一番多かったのは、新機能の話ではありませんでした。もっと手前にある、こんな不安です。「Rork で作り始めて、あとから本格的にネイティブ開発へ移りたくなったら、詰んでしまいませんか」。
この質問には、いつも答えに時間をかけてきました。軽く「大丈夫です」と言ってしまうには論点が多く、かといって「場合によります」で済ませるには大事すぎる問いだからです。ちょうど同じ週に Android 側の状況が動いたこともあり、2026年6月時点での自分なりの整理を書き残しておきます。
「詰みませんか」という不安の正体
ノーコードツールへの警戒心には、歴史的な理由があります。従来型のツールの多くは、アプリがプラットフォームの内側に住む構造でした。契約をやめればアプリそのものが動かなくなり、コードという形で手元に残るものもありません。この構造を一度でも経験した方が「乗り換え」を心配するのは、当然のことだと思います。
Rork はこの点で構造が異なります。生成されるのは Expo（React Native）の通常のコードベースで、GitHub へエクスポートすれば自分の資産として手元に置けます。アプリが Rork の中に住んでいるのではなく、Rork が書いたコードとして外に存在する、という関係です。
そうなると、問いの形が変わります。「逃げられるか」ではなく、「逃げる先はどこで、何が持ち越せて、どれくらいの工数がかかるのか」。今回確かめたいのはここです。私の見立てでは、出口は3つあります。
出口① 移行しない — Expo のまま育てるという最有力の選択
最初に挙げる出口は、意外に思われるかもしれませんが「移行しないこと」です。
Expo は現在、EAS によるビルド・配信や、コンフィグプラグイン経由でのネイティブ機能の取り込みによって、想像よりずっと遠くまで行けます。プッシュ通知、アプリ内課金、位置情報、カメラ。個人開発で App Store と Google Play に出すアプリの要件は、その大半が Expo の射程に収まるというのが、実際に運用してきた私の実感です。
判断基準としてお勧めしたいのは、たった一つの問いです。「ネイティブでしか実現できない機能を、具体的に1行で言えるか」。これが言えないうちは、移行は課題ではなく、漠然とした不安にすぎません。不安を理由に技術を乗り換えると、得るものより失うもの（出荷の速さ、メンテナンスの軽さ）の方が多くなりがちです。
もちろん境界はあります。ホーム画面ウィジェットや Watch 連携のように、Expo の標準的な枠から一歩外へ出る要件も存在します。ただ、その多くはコンフィグプラグインや開発ビルドで先に対応の道を探れますし、「枠を出た瞬間にアプリ全体を作り直す」という話には直結しません。境界に触れたときこそ、機能単位で冷静に切り分ける価値があります。
ネイティブ移行は目的ではなく、特定の機能要件が生まれたときの手段です。この順番を守るだけで、悩みの大半は消えてくれます。
出口② Android 側 — Kotlin 自動移行エージェントという新しい現実
今回この考察を書こうと思った直接のきっかけがこれです。WWDC の話題と同じ週に、Android Studio が React Native・iOS・Web のコードを解析してネイティブ Kotlin アプリへ移し替える「移行エージェント」をプレビューしている、という情報が目に入ってきました。Google I/O 2026 で示されていた方向性が、実際に触れる形になりつつあります。
冷静に書いておくと、現段階はプレビューです。生成された Kotlin コードをそのまま本番に出せるとは私は考えていませんし、UI の細部やサードパーティライブラリの依存関係が等価に移るとも思っていません。検証とレビューの工数は確実に残ります。
それでも、これは大きな変化だと受け止めています。これまで Android 側で「Expo から離れる」と言えば、見積もりの立たないフルリライトの一択でした。見積もりが立たないものは、そもそも選択肢として検討すらされません。移行エージェントの価値は「全自動で移れること」ではなく、「移行の総工数が試算できるようになること」にあります。乗り換えの判断が感覚の話から数字の話に変わる。ツールの完成度がまだ途上でも、意思決定の質はすでに変わり始めています。
出口③ Apple 側 — 「変換」ではなく「作り直し」と捉えます
一方で Apple 側には、React Native から Swift への自動変換と呼べるものは実質存在しません。ここは誤魔化さずに書いておきます。Apple 側の出口は、変換ではなく作り直しです。
ただし、作り直しの意味が以前とは変わりました。Rork Max が Swift を直接生成するようになり、仕様さえ明確なら、再構築は「数ヶ月がかりの大工事」ではなく現実的な工数に収まり始めています。このとき持ち越せる資産はコードではありません。画面構成、データの設計、そして「何をなぜ作ったか」という仕様の言語化です。最初に出した Expo 版は、その仕様を市場で検証するための実機テストだったのだと捉え直せます。
では、どのタイミングで Max への再構築を検討すべきか。私はストアの実績データで判断する流儀で、その基準は Rork で出したアプリを Max へ移すのはいつか — 実績データで決める段階移行の基準 に詳しくまとめました。
しかも Apple 側は、移る理由そのものが増えています。WWDC 2026 では、初回ダウンロード200万未満の小規模開発者に Apple Foundation Models の無償利用が開かれました。ネイティブへ行けば使える道具が増えていく構図で、この影響は Apple Foundation Models の無償開放で、Rork アプリの AI コスト設計を三層に組み直す で考えています。
「最初の選択」が軽くなったことを、前向きに使います
3つの出口を並べて見えてくるのは、入口の選択が以前ほど重くなくなったという事実です。
Expo のまま育てる道は太く、Android には工数を試算できる移行手段が生まれ、Apple には Swift で作り直すための現実的な道具が揃いました。「最初に正しい技術を選ばなければ」という緊張は、2026年6月の時点でかなり緩んでいます。最初の1本は技術の最終決定ではなく、仕様を固めるための一手として出せばよい、と私は考えています。
その代わりに、私自身が習慣にしていることが一つだけあります。コードではなく、仕様を書き残すことです。画面ごとの目的、データの持ち方、削った機能とその理由。どの出口を選ぶことになっても、長生きするのはコードではなく、この言語化された仕様の方だからです。
ロックインの不安で最初の一歩が止まっている方は、まず、作りたいアプリについて「ネイティブでしか実現できない機能」を1行書き出すところから始めてみてください。空欄のままなら、その不安は今日のところは手放して構いません。書けたなら、それが出口を検討し始める合図です。私もこの整理を片手に、まず出すことを続けていきます。