ブラウザの中でアプリを組み立てて、ライブシミュレータでは思いどおりに動いている。そのまま手元の iPhone に入れてみたら、通知が飛んでこない、課金ボタンを押しても何も起きない——。こうした「シミュレータでは気づけなかった」つまずきは、ツールの不具合ではなく、確認できる範囲の境界を踏み越えたところで起きています。
2026 年の Rork は、クラウド上の Mac でコンパイルした結果を 60fps のライブシミュレータとしてブラウザにストリーミングし、タッチ入力まで返してくれます。環境構築なしで試作の回数を増やせるのは、個人開発を始めたばかりの方ほど効いてくる変化です。ただ、その手軽さに乗ったまま提出まで進むと、最後の最後で実機固有の落とし穴にはまります。ここでは、シミュレータで十分に判断できる項目と、Companion で実機に移すべき項目を、はっきり線引きして整理します。
ライブシミュレータが速いのは「往復」を消しているから
まず仕組みを押さえておくと、判断の精度が上がります。Rork のライブシミュレータは、あなたの手元のマシンでビルドしているのではなく、クラウドのホスト Mac でコンパイルした iOS シミュレータの画面を、映像としてブラウザへ流しています。タッチやスクロールの入力はそのままクラウド側へ送られ、結果がほぼ遅延なく返ってきます。
この方式の利点は、ローカルに重い開発環境を用意しなくても、変更を加えるたびに即座に挙動を確かめられることです。私自身、個人開発で長くアプリを作ってきましたが、いちばん時間を奪われるのは中身ではなく、ビルドや実機転送といった準備の部分でした。そこが軽くなるほど、アイデアを試す回数そのものが増えます。仕組みの詳細はRork Max のクラウドコンパイルの仕組みで扱っています。
ただ、シミュレータはあくまで「iOS シミュレータ」です。実機ではなく Mac 上で iOS を再現したものなので、端末固有のハードウェアやセンサー、OS の権限ダイアログ、課金のサンドボックスといった領域は、そもそも再現されないか、挙動が異なります。ここを知っておくことが、無駄なやり直しを防ぐ近道になります。
シミュレータで十分に確認できること
次の項目は、ライブシミュレータの段階でしっかり詰めて構いません。実機に移しても結果が変わりにくい領域です。
- 画面レイアウトと余白：要素の配置、セーフエリアの避け方、文字の折り返し。複数の画面サイズを切り替えて崩れを潰せます。
- 画面遷移とナビゲーション：タブの切り替え、戻る操作、モーダルの開閉。導線が破綻していないかはここで十分に追えます。
- 状態の持ち回り：入力した値が次の画面に渡るか、リストの更新が反映されるか。アプリ内で完結するロジックは信頼できます。
- ライト/ダークの見え方：配色やコントラスト。テーマ切り替え時の文字の読みやすさを確認できます。
- テキスト入力の基本挙動：フォーカス移動やバリデーション。ただし日本語 IME の細かな変換挙動は実機で再確認したほうが安全です。
要するに、アプリの内側だけで完結する見た目とロジックは、シミュレータで詰め切ってしまうのが効率的です。
シミュレータでは判断できず、実機に移すべき項目
ここが本題です。次の項目は、ライブシミュレータでどれだけ快調に見えても、それだけで「動いた」と判断してはいけません。実機に移して初めて本当の挙動がわかります。
- プッシュ通知：リモート通知の受信は実機が前提です。シミュレータでは届かない、または挙動が異なるため、許可ダイアログから受信・タップ後の遷移まで実機で通します。
- ATT（トラッキング許可）ダイアログ：表示タイミングと、許可/拒否それぞれの分岐。広告 ID の取得可否は実機でしか正しく確かめられません。
- アプリ内課金（サブスク・単発）：購入フロー、復元、サンドボックスでの領収書検証。シミュレータでは購入そのものが成立しないため、課金は必ず実機で検証します。
- カメラ・写真ライブラリ・マイク：実際のハードウェアと権限が絡む機能。シミュレータでは取得できる画像が限られ、権限ダイアログの体験も再現されません。
- 触覚フィードバック（ハプティクス）：振動は実機でしか体感できません。強さやタイミングの調整は手に持って確かめます。
- スクロールの「指ざわり」と体感性能：慣性スクロールの自然さ、画像の多い画面でのカクつき、発熱による速度低下。ストリーミング越しでは正確に測れません。
- 生体認証(Face ID / Touch ID)：認証の成功・失敗・フォールバックの分岐は実機で。
- 他アプリからのディープリンク：共有シートや URL スキームでの起動は、実機で別アプリと組み合わせて確認します。
共通しているのは、いずれも「端末固有のハードウェア」「OS の権限」「課金や通知といった外部サービスとの連携」に触れている点です。この三つのどれかに該当したら、シミュレータでの確認は下書きと捉え、判断は実機に持ち越すのが安全です。
Companion で実機に移すタイミングの目安
では、いつブラウザから実機へ移すか。私が個人開発で使っている目安はとてもシンプルです。**実装した機能が、上で挙げた「ハード・権限・課金/通知」のどれかに触れた瞬間に、その機能だけでも実機で通す。**全部を作り終えてからまとめて実機確認に回すのではなく、危ない機能を足したその場で確かめるほうが、原因の切り分けがずっと楽になります。
Rork の場合、有料の Apple Developer アカウントが無くても Companion アプリ経由で手元の iPhone に転送して試せます。最初の「実機で動かす」までの摩擦が低いので、こまめに実機へ移す運用と相性が良いのです。具体的な転送手順はRork Companion で iPhone 実機テストを始める手順にまとめてあります。提出直前の最終確認は、さらに一段進めてRork アプリを TestFlight でベータ配布する流れで、実際の配信経路に近い形で通しておくと安心です。
私が提出前に必ず実機で通す最低ライン
私はこの線引きを習慣にしてから、やり直しが目に見えて減りました。最後に、私が個人開発で提出前に必ず実機で確認している項目を、最低ラインとして残しておきます。シミュレータで OK に見えても、ここだけは手元の端末で一度ずつ通します。
通知の許可から受信・タップ遷移まで一往復。課金の購入と復元をサンドボックスで一往復。カメラや写真へのアクセス許可を初回から拒否・再許可まで。そして、画像が多い画面を実際に数十秒スクロールして、発熱と速度の落ち方を体で確かめる。この四つを通しておくだけで、公開後に「実機だけで起きる不具合」を踏む確率がはっきり下がります。
ブラウザのライブシミュレータは、試作の回数を増やすための強力な土台です。その速さを活かしつつ、ハード・権限・課金に触れた機能だけは実機へ——この線引きを一つ持っておくだけで、最後のつまずきはかなり減らせます。まずは次にあなたが触る機能が、シミュレータで足りるのか実機が要るのか、この記事の三つの基準で一度仕分けてみてください。