Rork Companion の無料実機テストをどこまで引っ張れるか — 有料 Apple Developer に切り替える判断点

$99 を払うべき具体的なトリガー

「いつ払うか」を感覚で決めると早すぎたり遅すぎたりします。私は次のいずれかに最初に当たった時点を支払いのトリガーにしています。早すぎる課金は年間費用を遊ばせ、遅すぎる課金は完成直後に審査待ちを挟んで失速させるからです。

1. 収益の中核がプッシュ・課金・サブスクのいずれかである — テスト広告では検証しきれない。設計の初期からアカウントが要ります。
2. 自分以外のテスターに配りたい — Companion の共有リンクでは限界があり、TestFlight の外部テストには Program が必須です。
3. App Store 固有の機能を本番同等で確認したい — App Clips、ウィジェット、Live Activities、特定の Capability は署名ビルドでしか正しく出ません。
4. 公開予定日が 1〜2 週間以内に見えてきた — 審査の往復に予備日が要るので、ここまで来たら先に払って通しておきます。

逆に、まだ「アイデアが本当に形になるか」を試している段階や、UI と素の操作感を詰めている段階では、$99 を払う理由はありません。無料経路で試作の回数を稼ぐほうが、結果的に良いアプリに近づきます。Rork 本体は無料開始・有料 $25/月〜、Rork Max は別系統で月 $200 という料金体系ですが、Apple Developer Program の年 $99 はそれらとは独立した「Apple 側の通行料」だと捉えると整理しやすいです。

払う前に仕込んでおく準備チェックリスト

最初の署名ビルドで慌てないために、無料経路にいる間に済ませておくと効く準備があります。これを後回しにすると、$99 を払った直後の貴重な審査サイクルを、設定の不備潰しで消費することになります。

1. 容量とアセットの整理

ライブシミュレータでは気づきにくいのが、実機での初回起動の重さです。画像中心のアプリでは特に、無署名のうちにアセットの密度バケットと遅延読み込みを整えておきます。私自身、壁紙系のアプリで density 分割の取りこぼしに後から気づき、低密度端末でリソースが欠ける事故を経験しました。署名ビルドに入る前に潰しておくべき類の問題です。

2. 権限プロンプトの順序

ATT（App Tracking Transparency）・通知・写真ライブラリなどの権限ダイアログは、出す順序とタイミングで体感が大きく変わります。最低限の方針として、初回起動でいきなり全部出すのではなく、機能を使う直前に文脈を添えて出す設計を、無料経路にいる間にコードへ落としておきます。SDK 初期化と権限要求の順序設計は起動時の SDK オーケストレーションで詳しく扱っています。

3. 計測の土台

署名ビルドで初めてクラッシュに出会うと、原因の切り分けに時間がかかります。無署名のうちに、最低限のクラッシュレポートとイベント計測の土台だけは入れておくと、課金後の検証が速くなります。下記は app.json（Expo 系）に、課金前に確定させておきたい識別子と権限文言の雛形をまとめた例です。

{
  "expo": {
    "name": "MyApp",
    "slug": "my-app",
    "ios": {
      "bundleIdentifier": "design.dolice.myapp",
      "buildNumber": "1",
      "infoPlist": {
        "NSUserTrackingUsageDescription": "広告をあなたの興味に合わせて最適化するために使用します。",
        "NSPhotoLibraryAddUsageDescription": "壁紙を写真ライブラリへ保存するために使用します。",
        "ITSAppUsesNonExemptEncryption": false
      }
    },
    "android": {
      "package": "design.dolice.myapp",
      "versionCode": 1
    }
  }
}

bundleIdentifier と package は、後から変えると配布のやり直しになるため、無料の段階で本番用に確定させておきます。ITSAppUsesNonExemptEncryption を先に明示しておくと、申請時の輸出コンプライアンス入力で止まらずに済みます。

4. 署名前セルフ監査

審査で弾かれる定番は、Info.plist の権限文言欠落とバージョンの食い違いです。署名ビルドに入る前に、簡単な静的チェックを一度かけておくと、最初の提出での差し戻しを減らせます。次は Node で書ける最小の監査例です。

// presubmit-audit.js — 署名ビルド前に走らせる最小チェック
const fs = require("fs");
const cfg = JSON.parse(fs.readFileSync("app.json", "utf8")).expo;
 
const required = [
  "NSUserTrackingUsageDescription",
  "NSPhotoLibraryAddUsageDescription",
];
const info = cfg.ios?.infoPlist ?? {};
const missing = required.filter((k) => !info[k]);
 
if (missing.length > 0) {
  console.error("欠落している権限文言:", missing.join(", "));
  process.exit(1);
}
if (!cfg.ios?.bundleIdentifier?.includes(".")) {
  console.error("bundleIdentifier が本番用に確定していません");
  process.exit(1);
}
console.log("セルフ監査を通過しました");

このチェックは数十行ですが、最初の審査サイクルを設定不備で1往復ぶん無駄にしないための保険になります。私は 6 本を並行運用していて、提出のたびに同じ箇所でつまずくのに気づき、この種の小さな監査をビルド前に固定化しました。

ライブシミュレータが構造的に再現できないもの

無料経路を引っ張る判断をするうえで、ライブシミュレータが「速くて便利だが本物ではない」点を具体的に押さえておくと安心です。次のものは、クラウドのシミュレータでは原理的に再現しきれません。

• 実機の発熱によるフレーム低下（長時間スクロールや動画再生での息切れ）
• メモリ逼迫時の OS による強制終了（jetsam）の挙動
• 本物のセンサー・触覚フィードバックの体感
• 電波の弱い環境やオフライン遷移での実際のばらつき

これらは、たとえ無料経路で UI を完璧に詰めても、実機（Companion 転送）でしか確かめられません。私の場合、画像中心のアプリでメモリ逼迫による強制終了に気づいたのは、いつも実機に転送した後でした。だからこそ、無料経路で素の動きを潰し切ったうえで、この層だけを実機確認に回す、という責務分担が効きます。

無料経路と課金後をつなぐ運用の型

ここまでを一つの流れにすると、次のような順序になります。アイデア検証と UI 詰めはすべて無料経路で行い、上記4つの準備を無署名のうちに済ませ、収益機能・外部配布・公開日のいずれかが見えた瞬間に $99 を払う、という型です。

この型の利点は、課金後の時間を「検証」だけに集中できる点にあります。Companion で素の動きを確認し、署名ビルドで本番権限と課金を確認し、TestFlight で他人の端末に配る、という三段の責務分担がきれいに分かれます。公開フロー側の短縮については2クリック公開の手順も併せて参照すると、提出作業の摩擦をさらに減らせます。

無料経路はあくまで「作り始める前の摩擦」を消すための仕組みであって、収益や配布の本番経路を肩代わりするものではありません。この線引きを最初に持っておくと、$99 を払う日を自分で選べるようになります。まずは手元の一台を Companion につなぎ、上記のセルフ監査スクリプトを app.json に向けて一度走らせてみてください。最後までお読みいただき、ありがとうございました。