ノーコードで作ったアプリの「出口」を先に決めておく

データを最初から外に出せる形にしておく

機能を作り込む前に、データの持ち出し口を用意しておくことを強くお勧めします。アプリ内のデータをプラットフォーム任せにせず、自分が管理できるバックエンド（Supabase などのマネージド Postgres）に置いておくと、ツールを乗り換えてもユーザーのデータは手元に残ります。

// データ層はツールに依存しない薄いクライアントに隔離する
// アプリのどこからも、この関数経由でしか保存・取得しない
import { createClient } from "@supabase/supabase-js";
 
const db = createClient(
  process.env.EXPO_PUBLIC_SUPABASE_URL!,
  process.env.EXPO_PUBLIC_SUPABASE_ANON_KEY!
);
 
export async function saveEntry(userId: string, entry: Record<string, unknown>) {
  // 保存先を1か所に集約しておくと、後でバックエンドを差し替えても
  // 画面側のコードを一切触らずに済む
  const { error } = await db.from("entries").insert({ user_id: userId, ...entry });
  if (error) throw error;
}
 
export async function exportAll(userId: string) {
  // 「いつでも全部出せる」を関数として用意しておく — これが出口の実体
  const { data } = await db.from("entries").select("*").eq("user_id", userId);
  return data ?? [];
}

ポイントは exportAll のような関数を、機能要件になくても最初に書いておくことです。ユーザーから「データを返してほしい」と言われたときに対応できるだけでなく、自分がツールを移行するときの避難はしごにもなります。月に数万円の収益が出てから「データが取り出せない」と気づくのが、いちばん避けたい事態です。

コードの脱出経路を2本用意しておく

Expo ベースで作っておくと、出口が2方向に開きます。

ひとつは Expo の prebuild（いわゆる eject）です。Rork が生成した Expo プロジェクトを手元に取り出し、ネイティブのプロジェクトとして展開できれば、以降は Rork なしでもビルドを続けられます。

# 生成された Expo プロジェクトをネイティブプロジェクトへ展開する
# これが通れば、以降はツールに依存せず自分でビルドを回せる
npx expo prebuild --clean
 
# 生成された ios / android ディレクトリで通常のネイティブビルドが可能
npx expo run:ios

もうひとつは、2026年に Android Studio がプレビューした移行エージェントです。React Native のコードを解析してネイティブ Kotlin アプリへ自動移行する機能で、これは Rork（Expo）で出したアプリの「将来の引っ越し先」として現実味があります。Swift 生成からは、こうした標準ツールによる自動移行の恩恵を受けにくいことも、土台選びの判断材料になります。

実務上の注意点として、prebuild は一度実行するとネイティブディレクトリが生まれ、それ以降の Rork 側の自動更新と衝突しやすくなります。ですので「いつでも eject できる準備はしておくが、収益が安定して移行を決断するまでは実行しない」という運用にしています。準備と実行を分けて考えるのが、ロックイン対策の現実的なバランスです。

課金とユーザー基盤を「持ち出せる資産」にする

意外と見落とされがちですが、いちばん移行が難しいのは課金とユーザーです。サブスクリプションを RevenueCat のような中間層で管理しておくと、ストアの仕組みやアプリの実装が変わっても、課金状態の真実は手元に残ります。AdMob による広告収益も、メディエーション設定を自分のアカウントで管理しておけば、アプリの作り直しに伴って失われることはありません。

私が運用しているアプリでは、課金まわりは必ず「アプリの実装」と「収益の記録」を分離するようにしています。アプリは作り直すかもしれませんが、誰がいつ課金してくれたかという履歴は、事業の背骨だからです。LTV やリテンションの数字も、自分が管理するデータとして持っておくと、ツールを変えても判断の連続性が保てます。

結論として、最初の設計に少しだけ時間を割く

ノーコードの魅力は速さですが、その速さに任せて出口のないアプリを量産すると、収益が育ったときに身動きが取れなくなります。逆に、データ・コード・課金の3点を最初から「持ち出せる形」にしておけば、Rork で素早く出して、必要なら Rork Max のネイティブ機能へ広げ、いざとなれば eject や Kotlin 移行で外へ出る、という多段の自由が手に入ります。

次の一歩として、いま作っているアプリに exportAll に相当する持ち出し関数がひとつでもあるか、確認してみてください。そこが出口設計のいちばん小さな第一歩になります。お読みいただきありがとうございました。