Rork で iOS アプリを作ろうとして、最初の壁になりやすいのが「ネイティブとは言うけれど、結局裏で何が起きているの?」という不透明さです。React Native のように JavaScript が動いているのか、本当に Swift コードが生成されているのか、ビルドはどこで走っているのか — 公式ドキュメントを読んでも全体像が掴みにくいんですよね。
私はこの半年で Rork を使って 3 本の iOS アプリを TestFlight に出しました。失敗もそれなりにしました。ここでは「Rork のプロンプトを書いて、それが SwiftUI コードになり、ビルドされて、実機で動くまで」のワークフロー全体を、私が普段やっている手順で書いていきます。これから始める方が「いまどの段階にいるか」を地図上で把握できることを目指します。
まず、Rork の出力は本当のネイティブアプリ
最初に押さえてほしいのは、Rork が生成するのは本物の SwiftUI コードだということです。React Native や Flutter のような中間レイヤを介さず、Xcode で開ける Swift プロジェクトがそのまま出てきます。
これは何が嬉しいかというと、生成されたあとに「自分で Xcode を開いて、Swift コードを直接いじる」道が常に開かれていることです。Rork で 80% を作って、最後の 20% を自分で仕上げる、という運用が現実的にできます。私が TestFlight に出したアプリも、最終的には Xcode で細かい調整を入れています。
逆にこの構造を理解していないと「Rork で完結させなきゃ」と思い込んで、Rork のプロンプトだけで何度もやり直す羽目になります。私自身、最初の 1 本目はそうでした。途中から Xcode に降りて手で書いた方が早かった、という結論に至るのに 1 ヶ月かかりました。
ワークフローの全体像 5 ステップ
私が現在使っているワークフローは次の 5 ステップです。
ステップ 1 は「アプリの骨格をプロンプトで作る」段階です。画面構成、データモデル、画面遷移を Rork に説明し、最初のプロジェクトを生成させます。ここでの目標は「動くものを最速で立ち上げる」ことで、細かいデザインは気にしません。
ステップ 2 は「画面ごとに UI を整える」段階です。各画面を 1 つずつ取り上げ、Rork に「この画面の余白、フォント、配色を整えてください」と指示していきます。スクリーンショットを添付すると効果が高いです。
ステップ 3 は「Swift プロジェクトをエクスポートして Xcode で開く」段階です。Rork の生成結果を .zip または Git リポジトリとして取り出し、Xcode で開きます。
ステップ 4 は「実機で動かす」段階です。Xcode から自分の iPhone に直接インストールして、実際の挙動を確認します。Rork のシミュレータ表示と実機では微妙に違うので、ここで実機チェックは必須です。
ステップ 5 は「TestFlight に上げて配信する」段階です。Apple Developer Program の手続き、App Store Connect での設定、TestFlight でのテスター招待を行います。
このうち、ステップ 1 と 2 が Rork の主戦場、ステップ 3 と 4 が Xcode の領域、ステップ 5 が App Store Connect の領域です。3 つの場所を行き来する作業だと最初から認識しておくと迷いません。
ステップ 1: 骨格を作るプロンプトの書き方
Rork に最初のプロジェクトを作らせるときのプロンプトは、できるだけ「画面と画面の関係性」が伝わるように書きます。私が使っているテンプレートを共有します。
iOS のネイティブアプリを SwiftUI で作りたいです。
アプリの目的:
日々の読書記録を残すアプリ。読み終わった本のタイトル、著者、感想、評価（5 段階）を記録できる。
画面構成:
1. ホーム画面: 記録した本がリスト表示される。新規追加ボタンが右上にある
2. 詳細画面: リストの 1 件をタップすると開く。本の情報を表示し、編集ボタンと削除ボタンを置く
3. 編集画面: タイトル、著者、感想、評価を編集できるフォーム
4. 新規追加画面: 編集画面と同じレイアウトで、空の状態から書き始める
データの永続化:
SwiftData を使う。本のモデルは Book 型で、id（UUID）、title（String）、author（String）、note（String）、rating（Int）、createdAt（Date）を持つ。
最初は最小構成で OK です。デザインは後で詰めます。
ポイントは 3 つです。第一に、画面の数と関係性を最初に明示します。これがないと Rork は気を利かせて余計な画面を足してきます。
第二に、データモデルを具体的に指定します。型まで書くのが効きます。「うろ覚え」で生成させると、後で修正コストが高くつきます。
第三に、「最初は最小構成で」を明記します。これがないと Rork は親切心からアニメーションや細かいエフェクトを盛り込んできて、生成時間が伸びます。骨格作りの段階では速度優先です。
ステップ 2: スクリーンショットを使った UI 修正
骨格ができたら、画面ごとに UI を整えます。ここで威力を発揮するのが「スクリーンショットを添付する」テクニックです。
たとえば「ホーム画面のリストが詰まりすぎている」と感じたら、Rork のプレビュー画面のスクリーンショットを撮って、こう指示します。
添付したスクリーンショットの問題点:
- リストの行間が詰まっていて読みづらい
- 右側の評価星が小さくて見えない
- 新規追加ボタンが目立たない
修正してほしいこと:
- 各行に上下 12pt の padding を追加
- 評価星を SF Symbols の star.fill で 18pt にする
- 新規追加ボタンを Floating Action Button 風に右下に配置
「現状の問題点」と「修正してほしいこと」を箇条書きで分けるのがコツです。テキストだけで指示するより、スクリーンショット + 構造化されたフィードバックの方が、Rork は格段に正確に修正してくれます。
ここでよくある失敗は、「もっとモダンなデザインに」のような曖昧指示です。Rork は気を利かせて何かしら変えてきますが、こちらの意図とずれることが多いです。具体的なパラメータ（pt、色、配置）を指定しましょう。
ステップ 3: Xcode に降りるタイミング
Rork で粘るか、Xcode に降りるかの境目はどこか、というのが私が最も悩んだポイントです。半年やってみて、私なりの基準は次のようになりました。
Rork で続けるべきは、「指示が言語化しやすい変更」です。色を変える、レイアウトを変える、画面を追加する、データモデルを修正する、といった作業は Rork が得意です。
Xcode に降りるべきは、「言語化しにくい微調整」と「既存コードの一部だけを変えたい場合」です。たとえば「このボタンが押された時のアニメーションを 0.3 秒の easeOut にする」のような細かい調整は、Rork に伝えるより自分で書いた方が早いです。
もうひとつ Xcode が必要になるのは、「Apple のフレームワークを直接呼ぶ」場面です。Notification、HealthKit、CoreLocation などを使い始めると、Rork のプロンプトでは追いつかない複雑さになります。ここは素直に Swift のドキュメントを開いて自分で書く方が確実です。
ステップ 4: 実機テストでよくつまずくポイント
Xcode で開いて、自分の iPhone に繋いでビルドする — この段階で初心者がよくつまずくポイントを 3 つ挙げます。
ひとつは「Signing & Capabilities」の設定です。Xcode のプロジェクト設定で、Apple ID を Team として選び、Bundle Identifier を一意な文字列（例: com.yourname.bookapp）に設定する必要があります。これをやっていないと「No matching profile found」のようなエラーで止まります。
ふたつめは「Untrusted Developer」の警告です。実機にビルドしたあと、iPhone の設定 → 一般 → VPN とデバイス管理 から、自分の Apple ID を信頼する操作が必要です。これを忘れるとアプリは入っても起動しません。
3 つめは「ネットワーク権限」です。アプリが API を叩く場合、Info.plist に NSAppTransportSecurity の設定を入れたり、ローカル開発サーバーに繋ぐなら NSAllowsLocalNetworking を許可したりが必要です。Rork は本番想定で生成するので、ローカル開発のための設定はあとで自分で入れる、と覚えておくと迷いません。
ステップ 5: TestFlight への配信
TestFlight に上げる流れは、初めてだと迷いどころが多いので、要点だけ書きます。
事前準備として、Apple Developer Program に登録します（年間 99 ドル）。次に App Store Connect で新規アプリを作り、Bundle Identifier を Xcode 側と一致させます。
Xcode から Archive ビルドを作ります（メニューの Product → Archive）。Archive が成功すると Organizer ウィンドウが開くので、そこから「Distribute App」→「App Store Connect」→「Upload」と進みます。アップロードには 5〜10 分かかります。
App Store Connect に戻ると、新しいビルドが表示されます。輸出コンプライアンス（暗号化を使っているか）の質問に答え、TestFlight タブで内部テスター（自分や知り合い）を追加します。テスターには TestFlight 経由でアプリへのリンクが届くので、各自インストールします。
ここまで来れば、ひとまず「アプリを公開する」ところまで来ました。あとはユーザーフィードバックを集めて、Rork に戻って改善する、というサイクルを回せます。
私が Rork でよくやる失敗パターン
最後に、私が繰り返した失敗を共有しておきます。
ひとつは「いきなり完璧な仕様を渡そうとする」ことです。10 画面のアプリを 1 つのプロンプトで作らせようとすると、Rork は途中で破綻します。3〜4 画面ずつ、段階的に育てるのが鉄則です。
ふたつめは「生成結果を Xcode で開かずに Rork 内だけで完結させようとする」ことです。Rork のプレビュー画面と実機の挙動はけっこう違うので、早めに実機テストする習慣をつけた方が良いです。
3 つめは「データモデルを後で変えようとする」ことです。SwiftData のモデルを途中で変更するとマイグレーションが必要になり、これが想像以上に面倒です。最初に時間をかけてモデルを設計しておくと、あとが楽になります。
最初の 1 本に取り組む方への提案
これから Rork で初めて iOS アプリを作る方には、「自分が日常で本当に使いたい、小さなツール」を題材にすることを強くおすすめします。
私の最初の 1 本は、自分が読みたい本を記録するためだけの、機能を絞ったメモアプリでした。他人に売るわけではないので「最小限で十分」と割り切れて、Rork の練習にちょうどよかったのです。完成したら自分が毎日使うので、不満点も自然に見えてきて、改善のサイクルも回しやすくなります。
App Store で売れる傑作を最初から狙わず、「自分の小さな課題を解く」ところから始めると、Rork の良さも限界も両方見えてきて、次の本気のプロジェクトに活きてきます。半年前の自分にも、まずはそう言ってあげたいと思います。