Rork で iOS アプリを作ろうとして最初にぶつかる壁は、機能ではなく用語のほうでした。「ネイティブ」と書かれているのに、エクスポートしたプロジェクトを開くと App.tsx が並んでいる。Swift のファイルが出てくるものだと思っていたので、しばらく自分の操作を疑いました。
混乱には理由があります。Rork には出口が2つあるからです。
この記事は当初、「Rork はネイティブの SwiftUI を生成する」という前提で書いていました。これは正確ではありません。通常の Rork が出力するのは React Native（Expo）のプロジェクトで、SwiftUI のネイティブコードを生成するのは 2026年2月に登場した Rork Max のほうです。私が触っていた時期と製品の分岐が重なっていたため、頭の中で2つが混ざったまま公開していました。訂正いたします。
この違いは呼び名の問題ではありません。手を動かす順番そのものが変わります。以下、2つの出口の見分け方から、Rork Max でネイティブ iOS アプリを TestFlight まで届けるところまでを、私が実際に踏んでいる順に書いていきます。
出口が2つある — Rork と Rork Max で生成物が違う
まず全体像を1枚に置きます。
| 観点 | Rork（本体） | Rork Max |
|---|---|---|
| 生成されるコード | React Native / Expo（TypeScript） | ネイティブ Swift・SwiftUI |
| 届くプラットフォーム | iOS・Android・web を1つのコードベースで | iPhone・iPad・Apple Watch・Apple TV・Vision Pro・iMessage |
| Apple のフレームワーク | ブリッジや config plugin を挟む場面がある | SwiftUI・ARKit・HealthKit・HomeKit・Core ML などに直接届く |
| ビルドが走る場所 | EAS などのクラウドビルド、またはローカル | クラウド上の Mac 群（手元に Xcode を置かなくてよい） |
| Android を同時に得られるか | 得られる | 得られない（Apple プラットフォーム専用） |
要点は最後の行です。Rork Max は Apple の内側に深く入る代わりに、Android を手放します。逆に本体は横に広く届く代わりに、ネイティブ API に触れるたび手数が増えます。速く広く出したいのか、Apple の機能を深く使いたいのか。この一問に先に答えておくと、あとの選択がほとんど自動的に決まります。
自分がどちらの道にいるかを30秒で見分ける
進めているうちに分からなくなったら、エクスポートしたプロジェクトのルートを見ます。
package.json と app.json が並んでいれば React Native（Expo）です。Rork 本体の出力なので、この記事のステップ3以降はそのままは当てはまりません。
.xcodeproj あるいは .xcworkspace と .swift ファイルが並んでいれば SwiftUI です。Rork Max の出力で、以下の手順がそのまま使えます。
判断がつかないときは、「Xcode で開けるか」ではなく「手元に Xcode が無い状態でビルドが完了するか」を見るのが確実です。Rork Max はクラウド上の Mac 群でコンパイルするため、Mac を持っていなくてもビルドとシミュレータでのプレビューまで進みます。ここで止まるなら、そもそも別の道にいます。
費用は月額だけで見ない
個人開発では、月々の固定費がそのまま試行回数の上限になります。判断材料として、私が実際に払っている費目を並べます。
Rork 本体は無料から始められ、有料プランは月 $25 からです。Rork Max は Max プランで月 $200。加えて、App Store に出すなら Apple Developer Program が年 $99 かかります。無料枠はおおむね週5プロンプト程度なので、作り込む段階に入ると有料前提になります。
見落としやすいのは3つ目の費目です。作り直しに溶けたプロンプト回数が、そのまま金額になります。私の場合、最初の週は仕様を固めきらないまま指示を出し続けて、無料枠を検証らしい検証をしないまま使い切りました。試すコストと作り切るコストは、最初から別の袋に分けて見積もったほうが健全です。
料金の内訳とプランごとの損得はRorkの料金プランを正直に比較する：無料・Pro・Maxの違いと個人開発者が損しない選び方に整理しています。価格と枠は変動しますので、契約前に必ず公式の料金ページでご確認ください。
ワークフローの全体像 5 ステップ
Rork Max で私が現在使っている流れです。
ステップ 1 は「アプリの骨格をプロンプトで作る」段階です。画面構成、データモデル、画面遷移を説明し、最初のプロジェクトを生成させます。ここでの目標は動くものを最速で立ち上げることで、細かいデザインは気にしません。
ステップ 2 は「画面ごとに UI を整える」段階です。各画面を1つずつ取り上げ、余白・フォント・配色を指示していきます。スクリーンショットを添付すると効果が高いです。
ステップ 3 は「実機で動かす」段階です。Rork Max は QR コードで実機にインストールできるので、ここは Xcode を経由せずに進められます。
ステップ 4 は「Xcode に降りて仕上げる」段階です。必須ではありません。降りるかどうかの基準は後述します。
ステップ 5 は「TestFlight あるいは App Store に配信する」段階です。Rork 内から2クリックで提出する道と、Xcode で Archive して上げる道があります。
本体を使う場合と最も違うのはステップ3です。署名とプロビジョニングでつまずく段が丸ごと後ろにずれるため、「動くものを人に見せる」までの距離が目に見えて縮みます。
ステップ 1: 骨格を作るプロンプトの書き方
最初のプロジェクトを作らせるときは、画面と画面の関係性が伝わるように書きます。私が使っているテンプレートです。
iOS のネイティブアプリを SwiftUI で作りたいです。
アプリの目的:
日々の読書記録を残すアプリ。読み終わった本のタイトル、著者、感想、評価（5 段階）を記録できる。
画面構成:
1. ホーム画面: 記録した本がリスト表示される。新規追加ボタンが右上にある
2. 詳細画面: リストの 1 件をタップすると開く。本の情報を表示し、編集ボタンと削除ボタンを置く
3. 編集画面: タイトル、著者、感想、評価を編集できるフォーム
4. 新規追加画面: 編集画面と同じレイアウトで、空の状態から書き始める
データの永続化:
SwiftData を使う。本のモデルは Book 型で、id（UUID）、title（String）、author（String）、note（String）、rating（Int）、createdAt（Date）を持つ。
最初は最小構成で OK です。デザインは後で詰めます。
ポイントは3つです。第一に、画面の数と関係性を最初に明示します。これがないと気を利かせて余計な画面が足されます。
第二に、データモデルを型まで書きます。うろ覚えで生成させると、後の修正コストが高くつきます。SwiftData のモデルは途中変更にマイグレーションが伴うため、ここの数分が後の数時間になります。
第三に、「最初は最小構成で」を明記します。これがないとアニメーションや細かいエフェクトが盛り込まれ、生成時間が伸びます。骨格作りの段階は速度優先です。
無料枠が週5プロンプト程度であることを踏まえると、この1回目をどれだけ具体的に書けるかが、そのまま検証できる回数になります。プロンプトは書き捨てにせず、手元のメモに残して改稿していくのをおすすめします。
ステップ 2: スクリーンショットを使った UI 修正
骨格ができたら画面ごとに整えます。ここで効くのが、プレビューのスクリーンショットを添付するやり方です。
添付したスクリーンショットの問題点:
- リストの行間が詰まっていて読みづらい
- 右側の評価星が小さくて見えない
- 新規追加ボタンが目立たない
修正してほしいこと:
- 各行に上下 12pt の padding を追加
- 評価星を SF Symbols の star.fill で 18pt にする
- 新規追加ボタンを Floating Action Button 風に右下に配置
現状の問題点と修正してほしいことを箇条書きで分けるのがコツです。テキストだけで伝えるより、スクリーンショットと構造化されたフィードバックを組み合わせたほうが、返ってくる修正の精度が上がります。
よくある失敗は「もっとモダンなデザインに」のような曖昧な指示です。何かしら変わってはきますが、こちらの意図とはずれます。pt・色・配置といった具体的なパラメータで指定してください。
ステップ 3: 実機で確かめる
Rork Max では QR コードを読み取って手元の iPhone にインストールできます。シミュレータのストリーミング表示と実機では、スクロールの手触りやセーフエリアの扱いが微妙に違うので、この段は早めに通しておいたほうが良いです。
私が実機で初めて気づいたのは、リストのスクロール終端で跳ね返る挙動でした。プレビューでは滑らかに見えていたものが、指で触ると引っかかる。数値では出ない差なので、触るまで分かりません。
ステップ 4: Xcode に降りるかどうかの判断
Rork Max はクラウドでビルドが完結するので、Xcode に降りるのは必須ではなく選択です。半年やってみて、私なりの基準はこうなりました。
Rork Max で続けるべきは、指示が言語化しやすい変更です。 色を変える、レイアウトを変える、画面を追加する、データモデルを修正する。この種の作業は生成に任せたほうが速いです。
Xcode に降りるべきは、言語化しにくい微調整と、既存コードの一部だけを変えたい場合です。 「このボタンのタップ時アニメーションを 0.3 秒の easeOut にする」のような調整は、伝えるより自分で書いたほうが早い。既存の実装を保ったまま一箇所だけ触りたいときも同様で、プロンプトで頼むと周辺まで書き換わることがあります。
降りると決めたら、Apple ID を Team として選び、Bundle Identifier を一意な文字列（例: com.yourname.bookapp）に設定します。これをやっていないと「No matching profile found」で止まります。実機にビルドしたあとは、iPhone の設定 → 一般 → VPN とデバイス管理 から自分の Apple ID を信頼する操作も要ります。アプリは入るのに起動しない、という症状はたいていこれです。
ローカルの開発サーバーに繋ぐ場合は Info.plist の NSAppTransportSecurity に NSAllowsLocalNetworking を足します。生成は本番想定で出てくるので、ローカル開発向けの設定は自分で足すもの、と覚えておくと迷いません。
ステップ 5: 配信 — 2クリック提出と Xcode 経由の使い分け
Rork Max は Rork 内から2クリックで App Store へ提出できます。署名とプロビジョニングの段を飛ばせるので、初めて出す人にとってはここが実質的な価値です。
ただし、提出導線が短くなっても審査の要件は変わりません。プライバシー説明、スクリーンショット、年齢区分、輸出コンプライアンスの回答。生成は速くなりましたが、この準備は速くなりませんでした。私が最初に出したときは、アプリ本体より提出書類のほうに時間を使いました。
Xcode 経由を選ぶなら、Product → Archive でアーカイブを作り、Organizer から Distribute App → App Store Connect → Upload と進みます。アップロード自体は数分から10分程度です。ビルドが App Store Connect に現れないまま「処理中」で止まった場合の切り分けは、Rorkで書き出したアプリがApp Store Connectで「処理中」のまま止まる — 原因の切り分けと対処にまとめています。
審査でリジェクトされた場合の Guideline 番号別の対処は、Rork で作ったアプリが App Store でリジェクトされた時の対処辞典を参照してください。
React Native 側に残るという選択
ここまで Rork Max の道を書いてきましたが、本体に残るほうが合っている場面もあります。
Android も同時に出したい場合。web 版も配りたい場合。既に Expo のプロジェクトを持っていて、そこに機能を足していきたい場合。このいずれかに当てはまるなら、月 $200 を払う前に本体で足りるかを確かめる価値があります。
本体側で気をつける点は、ネイティブの手入れが prebuild --clean で消えることです。何が消えるかを事前に数える手順はprebuild --clean で消える手入れを、上げる前に数える — Expo SDK 57 移行の棚卸しに書きました。
なお、Rork Max がどの機能まで迷わず任せられるかについては、Rork Max の SwiftUI ネイティブ生成能力を30機能で検証する — どこで迷わず任せられて、どこで人間が介入すべきかで機能ごとに切り分けています。
私が繰り返した失敗
いちばん大きかったのは、この記事の冒頭で訂正した取り違えそのものです。Rork と Rork Max を同じものとして扱っていた期間、私は React Native のプロジェクトに SwiftUI の手順を当てようとしていました。 うまくいかないのは当然で、原因を自分の技量に求めていたのが一番の時間の無駄でした。まずどちらの出口にいるかを確かめる。それだけで解けた問題でした。
次に多かったのが、いきなり完璧な仕様を渡そうとすることです。10画面のアプリを1つのプロンプトで作らせようとすると、途中で辻褄が合わなくなります。3〜4画面ずつ育てるのが確実です。
3つ目はデータモデルを後から変えようとすることです。SwiftData のモデルを途中で変更するとマイグレーションが必要になり、想像以上に手が止まります。最初にモデルの設計へ時間を使っておくと、あとが楽になります。
最初の 1 本に取り組む方へ
これから初めて iOS アプリを作る方には、自分が日常で本当に使いたい小さなツールを題材にすることをおすすめします。
私の最初の1本は、読みたい本を記録するためだけの、機能を絞ったメモアプリでした。他人に売るわけではないので最小限で十分と割り切れて、練習にちょうどよかったのです。完成したら自分が毎日使うので、不満点も自然に見えてきて、改善のサイクルが回りはじめます。
売れる傑作を最初から狙わず、自分の小さな課題を解くところから始める。そうすると、任せられる範囲と任せられない範囲の両方が見えてきて、次の本気のプロジェクトに活きてきます。
誤った前提を含んだまま公開していた期間があったことを、あらためてお詫びいたします。お読みいただきありがとうございました。