Rork でネイティブ iOS アプリを作る — SwiftUI 生成から TestFlight 配信までの実践ワークフロー

Rork で iOS アプリを作ろうとして最初にぶつかった壁は、機能ではなく用語のほうでした。「ネイティブ」と書かれているのに、エクスポートしたプロジェクトを開くと App.tsx が並んでおりました。Swift のファイルが出てくるものだと思い込んでいたので、しばらく自分の操作を疑ったのです。

二度目の戸惑いは、この九月に公式ドキュメントを読み返した朝に訪れました。プロンプト欄の下にあるプラットフォーム選択が「For iPhone」「For Android」「Web」の三択になっていて、以前そこにあった Expo の選択肢が消えていたのです。

混乱には理由があります。Rork の出口が、この半年で二度変わったからです。

訂正を二度重ねます

この記事は当初、「Rork はネイティブの SwiftUI を生成する」という前提で書いておりました。公開後に「通常の Rork は React Native（Expo）を出力し、SwiftUI を生成するのは 2026 年 2 月に登場した Rork Max だけ」と訂正いたしました。

そしていま、その訂正がもう一度古くなっております。公式ドキュメントによれば、Rork では Expo（React Native）プロジェクトの新規作成ができなくなり、新しい iPhone アプリは Swift、Android アプリは Kotlin、web アプリは React で生成されます。理由は「社内ベンチマークでエージェントが書く Swift アプリのほうが React Native アプリより良かった」からだと明記されています。

しかも、iPhone 向けの SwiftUI 生成は月 $20 の Rork Pro に含まれるようになりました。Rork Max が担うのは iPad・Apple Watch・Vision Pro・iOS ウィジェット・ネイティブゲームという「iPhone の外側」です。

既存の Expo プロジェクトはそのまま動き、ビルドも公開も GitHub への書き出しも従来どおりできます——ここだけは変わっていません。

言葉の問題ではなく、手を動かす順番そのものが変わります。以下、いまの地図を一枚に置いたうえで、私が実際に踏んでいる順に TestFlight まで書いていきます。

いまの地図を一枚に — 生成物とプランの対応

要点は「iPhone だけなら Pro で足りる」という一行に尽きます。以前の私のように「SwiftUI が欲しいから Max」と考える必要はなくなりました。Max へ進む判断は、言語ではなく端末の広さで決まります。

もう一つの要点は、iPhone と Android が 別々のネイティブアプリ として同じプロジェクトに同居することです。React Native のように一つのコードベースを両 OS で共有する形ではなく、Swift と Kotlin の二つのコードベースを、同じチャットと同じバックエンドで束ねる形になっています。

自分のプロジェクトがどちらの世代かを 30 秒で見分ける

作りかけのプロジェクトがあるなら、書き出したフォルダのルートを見るのがいちばん早いです。

package.json と app.json が並んでいれば、旧世代の Expo プロジェクトです。動き続けますが、以下のステップ 3 以降はそのままでは当てはまりません。

.xcodeproj と .swift が並んでいれば、新世代の Swift プロジェクトです。以下の手順がそのまま使えます。

フォルダを見なくても、Rork の画面で分かる目印があります。旧世代のプロジェクトを開くと、プレビューの横に「Make this app native iOS」というカードが出ます。このカードが出ているあいだは、そのプロジェクトはまだ Expo なのだと判断して差し支えありません。

費用は月額ではなくクレジットで見る

個人開発では、月々の固定費がそのまま試行回数の上限になります。判断材料として、いま公式に明記されている費目を並べます。

無料プランは Design mode だけです。画面案は出ますが、動くコードは生成されません。1 日 5 クレジット、日本を含む主要市場では月 35 クレジットまでです。Build mode——実際に Swift を書かせ、シミュレータで動かし、提出する段——は有料プランが前提になります。

Rork Pro は月 $20 で 100 クレジット、Rork Max は月 $200 で 1,000 クレジットからです。加えて App Store に出すなら Apple Developer Program が年 $99 かかります。

見落としやすいのが、クラウドシミュレータの料金です。動かしているあいだ 1 分あたり 0.2 クレジット が、メッセージとは別に消費されます。10 分放置すれば 2 クレジット、つまり Pro の月枠の 2% です。テストが一巡したら「Stop simulator」を押す癖を、私は最初の月に覚えました。

そして最大の費目は、作り直しに溶けたクレジットです。私の場合、最初の週は仕様を固めきらないまま指示を出し続けて、月枠の半分を検証らしい検証をしないまま使い切っておりました。試すためのクレジットと、作り切るためのクレジットは、最初から別の袋に分けて見積もります。 これがいまの私の線引きです。

料金の内訳とプランごとの損得はRorkの料金プランを正直に比較する：無料・Pro・Maxの違いと個人開発者が損しない選び方に整理しています。価格と枠は変動しますので、契約前に必ず公式の料金ページでご確認ください。

ワークフローの全体像 5 ステップ

私が現在使っている流れです。

ステップ 1 は「アプリの骨格をプロンプトで作る」段階です。画面構成、データモデル、画面遷移を説明し、Design mode の画面案を確認してから Build に進みます。

ステップ 2 は「画面ごとに UI を整える」段階です。プレビュー上で要素を選んで指示する Element Selection と、スクリーンショットを添えた構造化フィードバックを使い分けます。

ステップ 3 は「実機で動かす」段階です。Rork Companion か Rork Max アプリ、あるいは TestFlight で手元の iPhone に入れます。Xcode は経由しません。

ステップ 4 は「Xcode に降りて仕上げる」段階です。必須ではありません。降りるかどうかの基準は後述します。

ステップ 5 は「TestFlight あるいは App Store に配信する」段階です。Rork の Publish から提出する道と、Xcode で Archive して上げる道があります。

旧世代の Expo と最も違うのはステップ 3 です。署名とプロビジョニングでつまずく段が丸ごと後ろにずれるため、「動くものを人に見せる」までの距離が目に見えて縮みます。

ステップ 1: 骨格を作るプロンプトの書き方

プラットフォーム選択で「For iPhone」を選んでから、最初のメッセージを送ります。私が使っているテンプレートです。

iOS のネイティブアプリを SwiftUI で作りたいです。

アプリの目的:
日々の読書記録を残すアプリ。読み終わった本のタイトル、著者、感想、評価（5 段階）を記録できる。

画面構成:
1. ホーム画面: 記録した本がリスト表示される。新規追加ボタンが右上にある
2. 詳細画面: リストの 1 件をタップすると開く。本の情報を表示し、編集ボタンと削除ボタンを置く
3. 編集画面: タイトル、著者、感想、評価を編集できるフォーム
4. 新規追加画面: 編集画面と同じレイアウトで、空の状態から書き始める

データの永続化:
SwiftData を使う。本のモデルは Book 型で、id（UUID）、title（String）、author（String）、note（String）、rating（Int）、createdAt（Date）を持つ。

最初は最小構成で OK です。デザインは後で詰めます。

送信すると、Rork はすぐには Swift を書きません。見た目についての短い質問がいくつか出て、答えは言葉ではなく画像で選ぶ形です。そのあと Design mode で画面案が描かれ、「Build」を押した時点で初めてコードになります。画面案の段階で気が変わるのは安上がりで、Build のあとで気が変わるのは高くつきます。 見た目の希望が最初から決まっているなら、質問を待たずに最初のプロンプトへ書いてしまうほうが速いです。

プロンプトのポイントは三つです。第一に、画面の数と関係性を最初に明示します。これがないと気を利かせて余計な画面が足されます。

第二に、データモデルを型まで書きます。SwiftData のモデルは途中変更にマイグレーションが伴うため、ここの数分が後の数時間になります。

第三に、「最初は最小構成で」を明記します。これがないとアニメーションや細かいエフェクトが盛り込まれ、クレジットが余分に消えます。骨格作りの段階は速度優先です。

Pro の月枠が 100 クレジットであることを踏まえると、この 1 回目をどれだけ具体的に書けるかが、そのまま検証できる回数になります。プロンプトは書き捨てにせず、手元のメモに残して改稿していくのをおすすめします。

ステップ 2: 要素を選んで直す、スクリーンショットで直す

骨格ができたら画面ごとに整えます。いまの Rork には二つの直し方があります。

一つ目は Element Selection です。シミュレータの上にある「Select an element」でプレビュー上の要素を指し、その要素に対して「余白を広げて」「この星を大きく」と書きます。Rork は選ばれた要素を読んで、その部分だけを編集します。一箇所だけ触りたいときは、こちらのほうが周辺まで書き換わる事故が少ないです。

二つ目は、スクリーンショットを添えた構造化フィードバックです。画面全体のバランスを直したいときはこちらが向いています。

添付したスクリーンショットの問題点:
- リストの行間が詰まっていて読みづらい
- 右側の評価星が小さくて見えない
- 新規追加ボタンが目立たない

修正してほしいこと:
- 各行に上下 12pt の padding を追加
- 評価星を SF Symbols の star.fill で 18pt にする
- 新規追加ボタンを Floating Action Button 風に右下に配置

現状の問題点と修正してほしいことを箇条書きで分けるのがコツです。よくある失敗は「もっとモダンなデザインに」のような曖昧な指示で、何かしら変わってはきますが、こちらの意図とはずれます。pt・色・配置といった具体的なパラメータで指定していただければと思います。

ステップ 3: 実機で確かめる

クラウドシミュレータは実物の iOS が動いているので、たいていの確認はここで済みます。ただし物理カメラがなく、Apple のプッシュ通知も受け取れません。カメラと通知だけは、実機に入れて確かめる必要があります。

実機へ入れる道は三つです。シミュレータ上の「Run on your device」から Windows／Mac 用の Rork Companion で USB 経由で入れる道、iPhone 側の Rork Max アプリの「Install on Device」で入れる道、そして TestFlight に提出して入れる道です。Rork Max アプリは選ばれたアカウントへ順次展開されている段階なので、手元に出ていなければ Companion を使います。

私が実機で初めて気づいたのは、リストのスクロール終端で跳ね返る挙動でした。プレビューでは滑らかに見えていたものが、指で触ると引っかかるのです。数値には出ない差なので、触るまで分かりませんでした。この段を早めに通しておくと、あとの修正がまとめて減ります。

ステップ 4: Xcode に降りるかどうかの判断

Rork はクラウドでビルドが完結するので、Xcode に降りるのは必須ではなく選択です。半年やってみて、私なりの基準はこうなりました。

Rork で続けるべきは、指示が言語化しやすい変更です。 色を変える、レイアウトを変える、画面を追加する、データモデルを修正する——この種の作業は生成に任せたほうが速いです。

Xcode に降りるべきは、言語化しにくい微調整と、コードをステップ実行で追いたいときです。 「このボタンのタップ時アニメーションを 0.3 秒の easeOut にする」のような調整は、伝えるより自分で書いたほうが早いのです。ログを見ながら原因を追いたいときも同様です。

降りると決めたら、プロジェクトを GitHub と同期し、Mac にクローンして、プロジェクトフォルダで xed . を実行します。Rork の iPhone アプリは素の Swift プロジェクトなので、生成し直す工程はありません。初回は Swift パッケージの解決が走るので、それが終わるまでビルドを待ちます。

署名まわりでは、ターゲットの Signing & Capabilities で自分の Apple Developer チームを選びます。ここを飛ばすと「No matching profile found」で止まります。実機で動かすには iPhone 側で「設定 → プライバシーとセキュリティ → デベロッパモード」を有効にする操作も要ります。アプリは入るのに起動しない、という症状はたいていこれです。

ビルドが意味不明に落ちるときは、File → Packages → Reset Package Caches のあとに Product → Clean Build Folder を試してからビルドし直すと、私の経験ではたいてい通ります。

ステップ 5: 配信 — Publish からの提出と Xcode 経由の使い分け

Rork の Publish を開くと、App Store の欄に「Submit to App Store」があります。押すと三段のダイアログが出て、App Info（アイコン・30 文字以内のアプリ名・バージョン・Bundle Identifier）、Apple Developer のサインイン、Start Submission と進みます。ビルドは Rork 側のマシンで走り、完了すると App Store Connect にビルドが載り、チャットに「Available on TestFlight」と出ます。「Beta Invite Link」でテスターを招待できます。

提出の前に AI App Store Reviewer を走らせておくのをおすすめします。審査ガイドラインに照らして、リジェクトされそうな箇所をガイドライン番号つきで指摘してくれます。Apple に指摘される前に自分で直せるのは、審査の待ち時間を考えると大きいです。

ただし、提出導線が短くなっても審査の要件は変わりません。プライバシー説明、スクリーンショット、年齢区分、輸出コンプライアンスの回答。生成は速くなりましたが、この準備は速くなりませんでした。私が最初に出したときは、アプリ本体より提出書類のほうに時間を使っております。

Xcode 経由を選ぶなら、Product → Archive でアーカイブを作り、Organizer から Distribute App → App Store Connect と進めば TestFlight に載ります。ビルドが App Store Connect に現れないまま「処理中」で止まった場合の切り分けは、Rorkで書き出したアプリがApp Store Connectで「処理中」のまま止まる — 原因の切り分けと対処にまとめています。

審査でリジェクトされた場合の Guideline 番号別の対処は、Rork で作ったアプリが App Store でリジェクトされた時の対処辞典をご覧ください。

旧世代の Expo プロジェクトを持っている方へ

既存の Expo プロジェクトは動き続けます。ビルドも公開も GitHub 同期も従来どおりです。急いで移す必要はありません。

移すと決めたときの道は用意されています。プレビュー横の「Make this app native iOS」カードで「Add iOS app」を押すと、エージェントが画面・ナビゲーション・データの流れ・デザインを SwiftUI で作り直します。Expo 側のアプリは同じプロジェクトに残るので、両方を並べて比べてから決められます。

私は、Android も同時に出したいプロジェクトほど、移す前に立ち止まるようにしています。Expo なら一つのコードベースで両 OS に届きますが、新世代では Swift と Kotlin が別々のコードベースになり、揃え続ける役はエージェントが担うからです。一方で、iPhone だけに集中しているプロジェクトは、移したあとのほうが実機の手触りが良くなりました。両方を残したまま、プロジェクトごとに使い分けています。

Expo 側に残る場合の注意点は、ネイティブの手入れが prebuild --clean で消えることです。何が消えるかを事前に数える手順はprebuild --clean で消える手入れを、上げる前に数える — Expo SDK 57 移行の棚卸しに書きました。

なお、SwiftUI 生成がどの機能まで迷わず任せられるかについては、Rork Max の SwiftUI ネイティブ生成能力を30機能で検証する — どこで迷わず任せられて、どこで人間が介入すべきかで機能ごとに切り分けています。

私が繰り返した失敗

いちばん大きかったのは、製品の分岐に自分の理解が二度とも追いつかなかったことです。旧世代の React Native プロジェクトに SwiftUI の手順を当て、次は Pro で足りる iPhone のために Max の月額を払おうとしておりました。 うまくいかない原因を自分の技量に求めていた時間が、いちばんの無駄でした。まず自分のプロジェクトがどちらの世代にいるかを確かめ、次に必要な端末の広さでプランを決める——それだけで解けた問題だったのです。

次に多かったのが、いきなり完璧な仕様を渡そうとすることです。10 画面のアプリを 1 つのプロンプトで作らせようとすると、途中で辻褄が合わなくなります。3〜4 画面ずつ育てるのが確実でした。

3 つ目はデータモデルを後から変えようとすることです。SwiftData のモデルを途中で変更するとマイグレーションが必要になり、想像以上に手が止まります。最初にモデルの設計へ時間を使っておくと、あとが楽になるのだと思います。

最初の 1 本に取り組む方へ

これから初めて iOS アプリを作る方には、自分が日常で本当に使いたい小さなツールを題材にすることをおすすめします。

私の最初の 1 本は、読みたい本を記録するためだけの、機能を絞ったメモアプリでした。他人に売るわけではないので最小限で十分と割り切れて、練習にちょうどよかったのです。完成したら自分が毎日使うので、不満点も自然に見えてきて、改善のサイクルが回りはじめます。

売れる傑作を最初から狙わず、自分の小さな課題を解くところから始めていただければと思います。そうすると、任せられる範囲と任せられない範囲の両方が見えてきて、次の本気のプロジェクトに活きてきます。まずは無料の Design mode で画面案を 1 つ出し、Build に進む価値があるかをその画面案で決める——そこから始めるのが、いまの Rork ではいちばん安上がりです。

誤った前提を含んだまま公開していた期間があったことを、あらためてお詫びいたします。読み直してくださった方に、心より感謝申し上げます。