Rork Max の SwiftUI ネイティブ生成で、動くアプリが出てくるところまでは、驚くほど短時間で到達できるようになりました。ところが「App Store に出して、継続的にアップデートし続ける」段階に入ると、まったく違うゲームが始まります。生成の精度が高い時は高いですが、ある日を境に大きな仕様変更で全体が崩れることや、審査で落ちた時にどこから直せばいいか分からなくなることが、必ず起きます。
ここではRork Max で自作アプリを App Store に出し、実運用でアップデートを重ねている私の経験から、個人開発者が1人で回せる範囲での本番運用設計をまとめました。機能紹介ではなく、落ちない運用にするための判断を中心に書いています。
土台となる3つの考え方
1. スペック先行でしか戦えない
Rork Max を「動くかな？」と試しながら触るフェーズを越えたら、仕様を自分で書いてから Rork に依頼するスタイルに完全移行します。思いつきベースの会話で作ると、あとでの軌道修正コストが指数的に膨らみます。
仕様書は大げさに考えず、画面一覧・データモデル・非機能要件の3つが最低限あれば十分です。これをMarkdownで用意して、Rorkとのチャットの先頭に貼り付ける運用が、私にとっての標準になっています。
2. 差分修正は「章単位」で契約する
一度動き始めたアプリに手を入れる時、「ログイン画面をリファクタして、プロフィールも少しきれいにして、あとバグも直して」のような複合依頼は、必ず事故ります。Rorkが複数箇所を同時に書き換えてしまい、どこが元の状態か分からなくなります。
私が決めているルールはシンプルで、1つのチャットメッセージで触るのは1画面もしくは1機能まで。これを破ると、90%の確率で半日溶かします。
3. アセットと法務は最初から準備する
アプリアイコン、スクリーンショット、プライバシーポリシー、利用規約、App Storeの審査資料——これらは「動くアプリができてから」作ろうとすると、リリース直前に詰まります。仕様書を書くタイミングで、これらの雛形も用意してしまうのが、結局いちばん早いです。
Phase 1: スペック設計フェーズ
最初にやることは、Rork に触らないことです。紙とペン、または Markdown エディタで仕様を詰めます。
必要十分な仕様書のテンプレート
# {アプリ名} Spec v1
## 位置づけと想定ユーザー
- ターゲット: {例: タスク管理に挫折し続けた20〜40代}
- 一行説明: {アプリストアに書ける50字の要約}
## 画面構成 (Information Architecture)
- Home: {表示要素・操作要素}
- Create: {...}
- Detail: {...}
- Settings: {...}
## データモデル
- {Entity1}: {field1 (type)}, ...
- {Entity2}: ...
## 非機能要件
- 対応OS: iOS 17+
- オフライン動作: 必須 / 不要
- 同期: iCloud / サーバー / なし
- 課金モデル: 買い切り / サブスク / 広告
## 審査対応準備
- プライバシーポリシーURL: (準備中)
- 利用規約URL: (準備中)
- 収集する個人情報: {なし/デバイスID/メール/...}これを最初に書いておくと、Rork への依頼がブレません。後から機能を足す時も、「v1スペックにこれを追加したい」と明示して差分で進められます。
画面数の現実的な上限
個人開発でRork Maxを使う場合、v1リリースは8画面以内に収めるのが現実的です。それ以上の規模になると、生成・修正サイクルで崩れ始める確率が上がります。9画面目が欲しくなったら、v1リリース後のアップデートに回すほうが成功率が高いです。
Phase 2: 生成フェーズ
仕様書ができたら、Rorkへの依頼を開始します。ここでも一括生成は避けて、段階的に進めます。
推奨する生成順序
- データモデルとストレージ層: 最初にこれを確立します。「仕様書のデータモデル通りに、SwiftDataで永続化層を実装してください。UIはまだ作らないでください」
- ナビゲーション骨格: 空のプレースホルダー画面を繋ぐナビゲーションだけを先に組みます
- 画面1つずつの実装: Home → Detail → Create の順で1画面ずつ依頼します
- 設定・認証などの周辺機能: メイン動線が固まってから足します
この順序を守ると、「後で大規模な書き換えが必要」という事態を7割くらい減らせます。
生成途中のコミット戦略
Rork内にビルドインのバージョン管理はありますが、私は節目ごとに自分のGitHubリポジトリへもエクスポートしてコミットしています。Rork内のロールバックで戻れない状態に陥ったとき、Git履歴が命綱になります。節目の定義は私の場合、「各画面の生成完了時」と「非機能要件の1つを満たした時」です。
Phase 3: 差分修正フェーズ
動くアプリができた後が、実は一番繊細です。ここで事故ると全体が壊れます。
差分依頼のテンプレート
## 修正依頼 v{番号}
### 対象画面 / 機能
{画面名 or 機能名} のみ
### 現状の問題
{具体的に何が困っているか、スクリーンショット貼付}
### 期待する動作
{箇条書きで明確に}
### 触ってほしくない範囲
- 他画面のコード
- データモデル
- ナビゲーション構造
### 成功条件
{このコミットをマージする判定基準}
毎回これを書くのはやりすぎに見えますが、「後で直す」のコストを考えると明確に安いです。私は自分のMarkdownスニペットに保存して、コピペで使っています。
レビューなしでマージしない
Rorkが出してきた差分は、必ずdiffで確認してからマージします。「説明文だけ読んで承認」は絶対にしません。経験上、説明と実装が食い違うケースが一定の割合で存在し、これを見逃すと後の審査で痛い目に合います。
Phase 4: App Store 提出準備
提出前チェックリスト
- [ ] アイコン（1024x1024・全サイズ）
- [ ] スクリーンショット（iPhone 6.9"・iPad 13"・必要に応じてApple Watch）
- [ ] プライバシーポリシーURL（公開済み）
- [ ] 利用規約URL（公開済み）
- [ ] プライバシー情報（App Store Connect の「App のプライバシー」タブ）
- [ ] キーワード（100文字以内・日英両方）
- [ ] アプリ説明（4000文字以内）
- [ ] サポートURL（公開済み）
- [ ] レビュー用ログイン情報（必要な場合）
これを仕様書と一緒に最初から準備しておくと、提出日がスッと進みます。
日英両対応のポイント
個人開発アプリでも、日本語と英語の両方をサポートしておくと、海外ユーザーが想定外のボリュームで来てくれることがあります。Rorkに「SwiftUIのLocalizable.strings（日本語・英語）で全文字列を外出ししてください」と最初から頼んでおくと、後付け対応の地獄を避けられます。
Phase 5: 審査リジェクト対応
避けて通れないのが、Appleの審査リジェクトです。私も何度か落ちています。落ちた時のリカバリで時間を溶かさないためのコツをお伝えします。
リジェクトメッセージをそのままRorkに渡す
リジェクト理由のメッセージを、そのまま英語でRorkに貼り付けて「このリジェクトに対応するコード修正と、レビュワーへの返信文案を出してください」と依頼します。要約して貼るよりも、原文のほうが正確に対処できます。
返信文の基本型
Dear App Review Team,
Thank you for your careful review. We have addressed the concern
regarding {issue name} as follows:
1. {具体的な修正内容1}
2. {具体的な修正内容2}
The relevant code changes are in the latest build {build number}.
Please let us know if any further changes are required.
Best regards,
{Your Name}
個人開発者でもプロフェッショナルな文面で返信すると、次のレビューが早く通る傾向があります（あくまで感覚ですが、経験上そうです）。
よく落ちるポイントと対策
4.3 Spam（類似アプリ）: 既存の類似アプリとの差別化を、説明欄とアプリ内表示の両方で明示します。「このアプリは〇〇が違う」と具体的に書きます。
5.1.1 Privacy（プライバシー）: 収集する情報を明示する宣言（App Privacy）を正確に埋める。不要なパーミッション（位置情報、写真など）を要求していないか確認します。
2.1 Performance（パフォーマンス / クラッシュ）: 実機で10分以上触って、起動・画面遷移・バックグラウンド復帰で落ちないかチェックします。Rork Maxの生成でもまれに落ちるパターンが残るので、実機確認は省略しないでください。
Phase 6: リリース後の運用
アップデートのリズム
私は個人開発アプリの場合、v1リリース後の最初の1ヶ月は大きな機能追加を控え、バグ修正と表示調整にとどめます。ユーザーからのフィードバックを数週間集めてから、v1.1の方向性を決めます。
クラッシュレポートの活用
App Store Connect のクラッシュレポートを週1で確認します。クラッシュが発生したら、そのスタックトレースをそのままRorkに貼り付けて修正を依頼します。「このクラッシュを修正してください。修正後の動作確認手順も含めて提示してください」と依頼すると、対処案と検証手順がセットで返ってきます。
コストとのバランス
Rork Max は便利ですが、無制限に使える道具ではありません。月間の生成量が予想を超えたら、新機能追加を止めて既存コードの手動メンテナンスに切り替える、というルールを自分に課しています。個人開発は持続性が命なので、コストコントロールも含めて運用設計です。
全体を振り返ってに代えて
Rork Max を使えば SwiftUI ネイティブアプリを短時間で作れる、というのは本当です。ただし、App Store に出す・出し続ける段階まで視野を広げると、必要な運用設計はRorkの外側にたくさんあります。仕様書の書き方、差分の管理方法、審査への返信文、リリース後のクラッシュ対応——どれも地味ですが、ここを押さえるかどうかで個人開発の持続性が変わります。
まずは仕様書テンプレートを1つ作っておくだけでも、次のプロジェクトがだいぶ楽になります。この記事を参考に、ご自身のスタイルにあった本番運用を組み立てていただけたらうれしいです。