Rork Max で SwiftUI のネイティブアプリを作れる、という事実は機能ページに書いてあります。ただ、実際に「仕様書からはじめて App Store 申請まで持っていく」となると、Rork Max 単体ではカバーしきれない場面が必ず出てきます。私が個人開発の現場で確立した、仕様書から提出までを 1 本のラインで動かすワークフローを共有します。
ここで書くのは「Rork Max を使えばこれができます」という機能紹介ではありません。「実際にアプリを完成させて売るために、Rork Max をどの位置に置き、何を周辺で補うか」という運用論です。
全体像 — Rork Max は「コア生成エンジン」、周辺は人と他ツールが補う
私のワークフローでは、Rork Max を「実装ボリュームの 60〜70% を担うコアエンジン」として位置付けています。残りの 30〜40% は、仕様書整理、UI ポリッシュ、StoreKit / In-App Purchase まわり、TestFlight 提出時のメタデータ作りなど、人間または他のツール（Xcode、Sketch、Notion）に任せます。
この分担を最初から明確にしておくと、Rork Max に「全部やらせようとして失敗する」という典型的な落とし穴を避けられます。生成系ツールの強みは「最初の 70% を素早く形にする」ことであって、「最後の 30% の細かい調整」ではないからです。
ステップ 1: 仕様書を Rork Max に渡す前に Notion で固める
Rork Max は仕様書を入力にして SwiftUI コードを生成しますが、いきなり Rork Max に長文を投げるのは効率が悪いです。私はまず Notion 上で「画面ごとに何があり、何ができるか」を 1 ページにまとめます。
具体的な構成例は次の通りです。
[Notion 仕様書テンプレート]
画面 1: ホーム
- 表示要素: タイトル、検索バー、最近の項目リスト
- ユーザー操作: 検索、アイテム選択、設定遷移
- データソース: 永続化されたお気に入りリスト（UserDefaults）
画面 2: 詳細
- 表示要素: タイトル、本文、関連リスト
- ユーザー操作: お気に入り追加、シェア
- データソース: APIからの取得（キャッシュあり）
この粒度で書いておくと、Rork Max が画面間の遷移と状態管理を正しく組み立ててくれます。ふわっとした仕様だと、画面ごとの実装は良くても遷移ロジックがぐちゃぐちゃになりがちです。
ステップ 2: Rork Max への初回プロンプトはアーキテクチャから
仕様書を渡すときに、私は最初のプロンプトで「アーキテクチャの選択肢を 2〜3 個提示して」と頼みます。MVVM か TCA か、永続化に SwiftData を使うか CoreData を使うか、といった設計判断を先に固めるためです。
Rork Max は「いきなり画面を作って」という依頼にも応えてくれますが、その場合あとから設計の変更が高くつきます。先に骨格を決めてから細部を生成する順序が、結果として最も早いです。
[プロンプト例]
このアプリの仕様書を踏まえ、SwiftUI で実装するアーキテクチャの選択肢を 3 つ提示してください。
それぞれについて、メリット・デメリット・想定される変更コストを述べた上で、
個人開発で App Store 提出までを 2 週間で進める前提でお勧めを 1 つ選んでください。
ステップ 3: 画面単位で生成 → Xcode で確認 → 修正依頼の高速ループ
骨格が固まったら、画面単位で SwiftUI コードを生成させます。1 画面ずつ依頼し、Xcode のプレビューで動作確認してから次の画面に進みます。複数画面を一度に生成させると、修正依頼のスコープが膨らんで非効率になります。
私の体感では、1 画面あたりの「生成 → プレビュー確認 → 修正依頼 → 再プレビュー」を 1 サイクル 15〜25 分で回せると、ペースが乗ります。これが 30 分を超え始めたら、仕様の粒度を上げるか、Rork Max への指示を細分化するサインです。
ステップ 4: StoreKit や AdMob は手書きで補う
課金まわり（StoreKit2）と AdMob 連携は、Rork Max の生成だけだと細かい挙動が安定しないことがあります。私は意図的にこの部分は自分で書きます。
具体的には、StoreKit2 の Product.products(for:) 周辺、Transaction.currentEntitlements の購読復元処理、AdMob の GADRequest 設定とテスト広告 ID の切り替えなどです。これらは仕様変更も多く、最新の Apple / Google の挙動を踏まえた手書きのほうが事故が少ないです。
// Rork Max ではなく自分で書いている部分の例
import StoreKit
@MainActor
class StoreManager: ObservableObject {
@Published private(set) var products: [Product] = []
@Published private(set) var purchasedIDs: Set<String> = []
func loadProducts(_ ids: [String]) async throws {
products = try await Product.products(for: ids)
}
func updateEntitlements() async {
var ids = Set<String>()
for await result in Transaction.currentEntitlements {
if case .verified(let tx) = result {
ids.insert(tx.productID)
}
}
purchasedIDs = ids
}
}ステップ 5: TestFlight 提出時のメタデータは Notion から流す
TestFlight 提出のときに必要なメタデータ（テスト内容、ベータ版の概要、テスター向けノート）は、Rork Max が直接生成してくれるわけではありません。私はステップ 1 で書いた Notion の仕様書を流用して、テスター向けの説明を 1 ページ作っています。
ベータテスターが「何を試せばよいか」を 5 行以内で書くのが理想です。私の経験では、テスト範囲が 1 画面に絞られたベータほどフィードバックが具体的で、開発のループが回りやすくなります。
ステップ 6: App Store 申請の最終確認は Rork Max と人間の両方で
申請直前のレビューでは、Rork Max に「このアプリで App Store の Review Guidelines に引っかかりそうな箇所があれば指摘して」と依頼するのを習慣にしています。これだけで毎回 1〜2 個は見落としを発見できます。
ただし、最終判断は必ず自分で行います。Rork Max が問題ないと判断しても、Apple のレビュアーが見ると別の判断になるケースは普通にあります。Rork Max は「頭のいい初稿レビュアー」として使い、最後の決断は人間が握るのが安全です。
1 サイクル全体の所要時間
私の場合、ここまでのワークフローを 1 アプリ分回すのに、企画開始から TestFlight 配布まで 7〜10 日かかっています。Rork Max なしで全部書いていた頃は 3〜4 週間かかっていたので、純粋な実装速度としては 3 倍ほど速くなりました。
ただし、ここで節約できた時間は「ストアの説明文、スクリーンショット、ASO 対策」に再投資するのが正解です。アプリ自体ができるのが速くなった分、流通側に手をかけられる余裕ができたと考えると、開発全体の質も底上げされます。
次のアクション
明日からできることは、自分が次に作りたいアプリの仕様書を Notion で 1 ページ書いてみることです。画面ごとに「表示要素・操作・データソース」の 3 つを箇条書きで埋めるだけでも、Rork Max への初回プロンプトが劇的に改善されます。仕様書の質が、生成されるアプリの質を決めます。