記事一覧へ
週末でアプリを作りました。Claudeがコードを書きました。自分のデバイスでは完璧に動きます。自信を持ってApp Storeに提出しました。そして3日後、Appleから却下通知が届きます。
これは運が悪かったわけではありません。パターンです。そして誰も話題にしていない割合でバイブコーダーに起きています。
私はApp Storeで10本のアプリを承認されました。すべてクリーンに通過しました。違いはコードの品質ではありませんでした。Appleが実際に審査していることを理解していたかどうかです。そしてそれはアプリの動作とはほぼ関係ありません。
## バイブコーディングしたアプリがより高い確率でApp Storeに却下される理由
バイブコーディングはビルドの障壁を取り除きました。シッピングの障壁は取り除いていません。
Appleの審査プロセスは、フルスタックを理解している開発者のために設計されました。プライバシーポリシー・メタデータの正確さ・支払いアーキテクチャ・デザインコンプライアンス。これらはオプションの追加機能ではありません。Appleの審査員がアプリがユーザーに届く前に通過する必須チェックボックスです。
ほとんどのバイブコーダーはこれらに一切触れずに提出します。アプリが動くから準備完了だと思っています。その思い込みが却下です。
**チェックリストに載っていない却下理由の1つがアプリのユーティリティです。** Appleは機能が限定的すぎると判断したアプリや、ウェブサイトを再パッケージしたように見えるアプリを却下することがあります。バイブコーディングしたアプリが1画面・基本的なフォーム・ウェブビューの薄いラッパーであれば、提出がどれだけクリーンでもAppleの最低ユーティリティ基準を通過できないかもしれません。これは提出後に修正できない唯一の却下理由です。提出前にアプリ自体を再考する必要があります。アプリが1つのことをするなら、そのことが本当に有用であり、ブラウザを開くだけでは代替できないことを確認してください。
## AIツールがセットアップしなかったAppleが実際に確認すること
Claudeがあなたのアプリを作りました。ClaudeはApp Store提出を処理しませんでした。これらは2つの別々の仕事です。そして2番目の仕事は完全にあなたの責任です。
Appleが承認前にチェックすること：
**プライバシーラベル。** アプリが収集するすべてのデータポイントを正確に申告する必要があります。名前・メール・デバイスID・使用データ。何も申告しなければ却下。誤って申告すれば却下。プライバシーポリシーのURLが404を返せば却下。
**メタデータの正確さ。** アプリ名・サブタイトル・説明・スクリーンショットは、審査員がアプリを開いたときに見るものと正確に一致する必要があります。プレースホルダーテキスト・欠けている機能・開示なしに有料機能を示すスクリーンショットはフラグが立てられます。
**支払いアーキテクチャ。** デジタル商品やサブスクリプションはAppleのアプリ内購入システムを通じる必要があります。アプリ内にStripeのリンクは不可。デジタル製品の外部決済フローは不可。Appleは15〜30%を徴収し、交渉の余地なく徹底します。
**デザインコンプライアンス。** 最小タップターゲットサイズ・ノッチデバイスのセーフエリアインセット・ダイナミックタイプのサポート。これらはヒューマンインターフェースガイドラインであり、提案ではありません。審査員は実際のデバイスでテストします。
**年齢レーティング。** AppleはあなたにアプリのコンテンツレーティングをApp Store Connectのアンケートで自己申告させます。ユーザー生成コンテンツ・無制限のウェブアクセス・成熟したテーマがある場合に4+と評価すれば、それはフラグが立てられる矛盾です。アンケートには注意深く答えてください。現在表示しているものだけでなく、表示できるものに基づいて回答してください。
**サポートされているすべてのデバイスでクラッシュフリー。** あなたのデバイスだけでなく。デプロイメントターゲット範囲内のすべてのデバイスで。
## 毎回使う提出チェックリスト
10本のアプリをクリーンに保ったリストです。スクリーンショットして、提出前に毎回実行してください。
**プライバシー**
- [ ] プライバシーラベルが完成し、実際のデータ収集と一致している
- [ ] プライバシーポリシーが有効なURLで公開されている
- [ ] プライバシーポリシーのURLがApp Store Connectに正しく入力されている
**メタデータ**
- [ ] アプリの説明が初回ユーザーが見るものと正確に一致している
- [ ] スクリーンショットがデータが入っていないフレッシュなシミュレーターで撮影されている
- [ ] スクリーンショットに開示なしに有料機能が見えていない
**支払い**
- [ ] すべてのデジタル商品とサブスクリプションがStoreKitを通じている
- [ ] アプリ内のどこにもデジタル製品の外部決済リンクがない
**年齢レーティング**
- [ ] 年齢レーティングのアンケートがApp Store Connectで正確に完了している
- [ ] レーティングが現在のコンテンツだけでなく表示できるものを反映している
- [ ] ユーザー生成コンテンツとウェブアクセスが申告されている（該当する場合）
**デザイン**
- [ ] すべてのタップターゲットが44ptの最小サイズを満たしている
- [ ] コンテンツがサポートされている最も古いデバイスでテストされている
- [ ] ホームインジケーターやノッチの下に何もクリップされていない
**提出**
- [ ] App Store審査に提出する前にTestFlightでアプリがテストされている
- [ ] 審査員ノートフィールドにデモアカウントの資格情報が入っている
- [ ] フレッシュなシミュレーターでコールドテストされている
- [ ] すべてのターゲットデバイスで起動時にクラッシュしない
これを提出前に1回実行してください。90分かかります。何週間もの時間を節約できます。
## App Store提出の完全ウォークスルー
これはApp Store Connectのセットアップから提出まで完全なプロセスです。毎回順番通りに従ってください。
**ステップ1：App Store Connectにアプリレコードを作成する**
appstoreconnect.apple.comに行き、プラスアイコンをクリックして「New App」を選択します。プラットフォーム・名前・主要言語・バンドルID・SKUを記入します。バンドルIDはXcodeプロジェクトのものと正確に一致する必要があります。ここでの不一致は開始前に提出をブロックします。
**ステップ2：アプリ情報を完成させる**
サブタイトル・カテゴリ・コンテンツ権利申告を記入します。プライマリとセカンダリのカテゴリを慎重に選んでください。Appleはこれを使って適切な検索でアプリを表示します。ほとんどのビルダーは合うと思った最初の選択肢を選びます。ここに5分費やしてください。
**ステップ3：年齢レーティングを設定する**
アプリのバージョンをクリックしてAge Ratingまでスクロールし、アンケートを完成させます。アプリが表示できる最大のコンテンツに基づいてすべての質問に答えてください。不確かであれば、より高いレーティングを付けてください。間違ったレーティングは却下です。保守的なレーティングはそうではありません。
**ステップ4：価格と利用可能地域を設定する**
価格ティアを設定し、アプリが利用可能な地域を選択します。グローバルにローンチするなら全地域を選択してください。アプリに地域固有の法的考慮事項がある場合は、それに応じて利用可能地域を制限してください。
**ステップ5：XcodeからビルドをアップロードするXcode**でアプリをアーカイブし、App Store Connectを通じて配布します。アップロードされると、ビルドは15〜30分以内にApp Store Connectに表示されます。提出ビルドとして選択してください。
**ステップ6：スクリーンショットとプレビューを追加する**
必要なすべてのデバイスサイズのスクリーンショットをアップロードします。最小はiPhone 6.5インチとiPhone 5.5インチのディスプレイです。スクリーンショットは実際のアプリ体験を示す必要があります。インターフェースを隠すマーケティングオーバーレイは不可。提出するビルドに存在しない機能も不可。
**ステップ7：説明とキーワードを書く**
説明には4,000文字あります。最初の3行をフックとして使ってください。ユーザーが「続きを読む」をタップする前に見えるのはそこだけです。キーワードには100文字の制限があります。タイトルやサブタイトルにすでに載っている単語は繰り返さないでください。そのフィールドのすべての文字が個別のランキングシグナルです。
**ステップ8：プライバシー栄養ラベルを完成させる**
アプリレコードのApp Privacyまでスクロールします。アプリが収集するすべてのデータタイプ・収集目的・ユーザーのアイデンティティにリンクされているかどうかを申告します。これをアプリのすべてのAPI呼び出しと照合してください。バックエンドが何かを収集している場合は申告してください。疑わしいときは多めに申告してください。
**ステップ9：プライバシーポリシーのURLを追加する**
プライバシーポリシーは公開されてアクセス可能なURLでホストされている必要があります。App Store ConnectのPrivacy Policy URLフィールドに貼り付けます。提出前にプライベートブラウザウィンドウでURLを開いて読み込まれることを確認してください。壊れたURLは自動却下です。
**ステップ10：審査員ノートを記入する**
このフィールドは審査員への直接の連絡手段です。アプリにログインが必要な場合はデモアカウントの資格情報を含めてください。すぐには明らかでない機能を説明してください。アプリがバックグラウンド位置情報を使用する場合は理由を説明してください。審査員は人間です。コンテキストを与えれば使ってくれます。
**ステップ11：まずTestFlightを実行する**
App Store審査に提出する前に、TestFlightでビルドを配布してください。少なくとも2つの異なる実機にインストールしてください。フレッシュインストールからすべてのコアユーザーフローをテストしてください。クラッシュ・レイアウトの問題・壊れた状態をAppleの審査員より先に発見してください。TestFlightの通過は承認の保証ではありませんが、最も一般的な却下トリガーを排除できます。
**ステップ12：審査に提出する**
「Add for Review」をクリックして「Submit to App Review」を選択します。標準的な提出の平均審査時間は24〜48時間です。ステータスが変わるとメールを受け取ります。メール通知は遅延することがあるので、App Store Connectを直接確認してください。
## ほとんどのビルダーが完全にスキップするステップ
審査員ノートフィールドです。
Appleの審査員はアカウントを作れません。アプリがログインなしでコア機能にアクセスできず、デモの資格情報を提供していなければ、審査員はテストできません。それは自動却下です。
フルアクセスのテストアカウントを作成してください。提出時にユーザー名とパスワードを審査員ノートに入力してください。このシングルステップが、このリストのどの修正よりも多くの審査をアンブロックしてきました。
アプリにペイウォールがある場合は、デモアカウントでそれをアンロックしてください。オンボーディングがある場合は完了させ、審査員がコアな体験に直接着地するようにしてください。審査員の仕事をできるだけ簡単にしてください。すべての摩擦ポイントが潜在的な却下理由になります。
## 却下された場合の対処法
まず却下通知を最後まで読んでください。Appleはすべての却下に固有のガイドライン番号を提供しています。App Store Review Guidelinesで調べて、何がフラグされたかを正確に理解してから何かを変更してください。
次に、フラグされたものだけを修正してください。無関係な変更を加えて修正バージョンを提出しないでください。Apple審査員は再提出時に新たな問題をフラグします。サイクルごとに1つのターゲットを絞った修正を。
却下が不明確な場合は、App Store Connect内のResolution Centerを使って審査員に直接返信し、明確化を求めてください。これは使われていない機能です。Appleの審査員は返信します。そして1つの明確化のメッセージで再提出サイクル全体を節約できます。
App Store提出における自信は、アプリが通過することを願うことからではありません。Appleが何を確認するかを正確に知り、審査員がそれを見る前に各項目を処理することから生まれます。
上記のチェックリストとウォークスルーが、それを実践する方法です。
毎日のClaude AIツール・暗号分析・100K到達への全旅程は @damidefi でXをフォローしてください。これをブックマークして、初めてアプリを提出しようとしている人と共有してください。
business-modelai-thinkingApp Storeモバイル開発
App Store審査を通過する完全ガイド
♥ 192↻ 21
原文を表示 / Show original
You built the app in a weekend. Claude wrote the code. It runs perfectly on your device. You submit it to the App Store full of confidence and three days later Apple sends you a rejection.
This is not bad luck. It is a pattern. And it is happening to vibe coders at a rate that nobody is talking about.
I have had 10 apps approved on the App Store. Every single one went through clean. The difference was not better code. It was understanding what Apple is actually reviewing, and it has almost nothing to do with how the app functions.
Why the App Store Is Rejecting Vibe Coded Apps at a Higher Rate
Vibe coding removed the barrier to building. It did not remove the barrier to shipping.
Apple's review process was designed for developers who understand the full stack. Privacy policies, metadata accuracy, payment architecture, design compliance. These are not optional extras. They are mandatory checkboxes that Apple's reviewers go through before your app ever reaches a user.
Most vibe coders submit without touching any of them. The app works, so they assume it is ready. That assumption is the rejection.
Apple rejects close to 40% of first-time app submissions. The reasons are almost never about code quality. They are about submission hygiene that AI tools do not handle for you.
One rejection reason that does not appear on any checklist is app utility. Apple will reject apps they consider too limited in functionality or that appear to be a repackaged website. If your vibe coded app is a single screen, a basic form, or a thin wrapper around a web view, it may not pass Apple's minimum utility standard regardless of how clean your submission is. This is the one rejection that cannot be fixed after the fact. It requires rethinking the app itself before you submit. If your app does one thing, make sure that one thing is genuinely useful and cannot be replicated by just opening a browser.
What Apple Actually Looks For (That Your AI Tool Did Not Set Up)
Claude built your app. Claude did not handle your App Store submission. These are two separate jobs, and the second one is entirely on you.
Here is what Apple checks before approval:
Privacy labels. Every data point your app collects must be declared accurately. Name, email, device ID, usage data. If you declare nothing, rejected. If you declare incorrectly, rejected. If your privacy policy URL returns a 404, rejected.
Metadata accuracy. Your app name, subtitle, description, and screenshots must match exactly what the reviewer sees when they open the app. Placeholder text, missing features, or screenshots showing paid functionality without disclosure will get you flagged.
Payment architecture. Any digital goods or subscriptions must go through Apple's in-app purchase system. No Stripe links inside the app. No external payment flows for digital products. Apple takes 15 to 30% and enforces this without negotiation.
Design compliance. Minimum tap target sizes, safe area insets on notched devices, dynamic type support. These are Human Interface Guidelines, not suggestions. Reviewers test on real devices.
Age ratings. Apple requires you to self-declare your app's content rating through a questionnaire in App Store Connect. If your app includes user-generated content, unrestricted web access, or any mature themes and you rate it 4+, that is a flaggable inconsistency. Go through the questionnaire carefully. Answer based on what the app could display, not just what it currently shows.
Crash-free on all supported devices. Not just yours. Every device in your deployment target range.
The Submission Checklist I Use Every Time
This is the list that has kept 10 apps clean. Screenshot it. Run through it before every submission.
Privacy
Privacy labels completed and matched to actual data collection
Privacy policy live at a working URL
Privacy policy URL entered correctly in App Store Connect
Metadata
App description matches exactly what a first-time user sees
Screenshots taken from a fresh simulator with no pre-existing data
No paid features visible in screenshots without disclosure
Payments
All digital goods and subscriptions go through StoreKit
No external payment links for digital products anywhere in the app
Age Rating
Age rating questionnaire completed accurately in App Store Connect
Rating reflects what the app could display, not just current content
User-generated content and web access declared if applicable
Design
All tap targets meet 44pt minimum
Content tested on the oldest supported device
Nothing clips under the home indicator or notch
Submission
App tested on TestFlight before submitting to App Store review
Demo account credentials in the reviewer notes field
App tested cold on a fresh simulator
App does not crash on launch on any target device
Run this once before every submission. It takes 90 minutes. It saves weeks.
The Complete App Store Submission Walkthrough
This is the full process from App Store Connect setup to hitting submit. Follow it in order every time.
Step 1: Create your app record in App Store ConnectGo to appstoreconnect.apple.com, click the plus icon, and select New App. Fill in the platform, name, primary language, bundle ID, and SKU. Your bundle ID must match exactly what is in your Xcode project. A mismatch here blocks submission before it starts.
Step 2: Complete your app informationFill in the subtitle, category, and content rights declaration. Choose your primary and secondary categories carefully. Apple uses these to surface your app in the right searches. Most builders pick the first option that fits. Spend five minutes on this.
Step 3: Set your age ratingClick on your app version, scroll to Age Rating, and complete the questionnaire. Answer every question based on the maximum possible content your app could display. If you are unsure, rate higher. A wrong rating is a rejection. A conservative rating is not.
Step 4: Configure pricing and availabilitySet your price tier and select which territories your app will be available in. If you are launching globally, select all territories. If your app has region-specific legal considerations, limit availability accordingly.
Step 5: Upload your build via XcodeArchive your app in Xcode, then distribute it through App Store Connect. Once uploaded, the build will appear in App Store Connect within 15 to 30 minutes. Select it as your submission build.
Step 6: Add screenshots and previewsUpload screenshots for every required device size. The minimum is iPhone 6.5 inch and iPhone 5.5 inch displays. Screenshots must show the actual app experience. No marketing overlays that obscure the interface. No features that do not exist in the build you are submitting.
Step 7: Write your description and keywordsYour description has 4000 characters. Use the first three lines as your hook because that is all users see before tapping "more." Keywords have a 100 character limit. Do not repeat words that already appear in your title or subtitle. Every character in that field is a separate ranking signal.
Step 8: Complete your privacy nutrition labelScroll to App Privacy in your app record. Declare every data type your app collects, the purpose it is collected for, and whether it is linked to the user's identity. Cross-reference this against every API call in your app. If your backend collects anything, declare it. When in doubt, declare more rather than less.
Step 9: Add your privacy policy URLYour privacy policy must be hosted at a live, publicly accessible URL. Paste it into the Privacy Policy URL field in App Store Connect. Open the URL in a private browser window before submitting to confirm it loads. A broken URL is an automatic rejection.
Step 10: Fill in reviewer notesThis field is your direct line to the reviewer. Include demo account credentials if your app requires login. Explain any features that are not immediately obvious. If your app uses background location, explain why. Reviewers are humans. Give them context and they will use it.
Step 11: Run TestFlight firstBefore submitting for App Store review, distribute your build through TestFlight. Install it on at least two different physical devices. Test every core user flow from a fresh install. Catch crashes, layout issues, and broken states before Apple's reviewer does. A TestFlight pass is not a guarantee of approval but it eliminates the most common rejection triggers.
Step 12: Submit for reviewClick Add for Review, then Submit to App Review. Average review time is 24 to 48 hours for standard submissions. You will receive an email when the status changes. Check App Store Connect directly rather than waiting on email notifications, which can lag.
The One Step Most Builders Skip Entirely
The reviewer notes field.
Apple's reviewers cannot create accounts. If your app requires a login to access core functionality and you have not provided demo credentials, the reviewer cannot test it. That is an automatic rejection.
Create a test account with full access. Drop the username and password into the reviewer notes during submission. This single step has unblocked more reviews than any other fix on this list.
If your app has a paywall, unlock it for the demo account. If your app has onboarding, complete it so the reviewer lands directly in the core experience. Make their job as easy as possible. Every friction point is a potential rejection reason.
What to Do If You Get Rejected
First, read the rejection notice fully. Apple gives a specific guideline number for every rejection. Look it up in the App Store Review Guidelines and understand exactly what was flagged before you change anything.
Then fix only what was flagged. Do not submit a revised version with unrelated changes. Apple reviewers flag new issues on resubmission. One targeted fix per cycle.
If the rejection is unclear, use the Resolution Center inside App Store Connect to reply directly to the reviewer and ask for clarification. This is underused. Apple reviewers do respond, and a single clarifying message can save you an entire resubmission cycle.
Confidence in App Store submission does not come from hoping your app passes. It comes from knowing exactly what Apple checks and handling each item before they ever see it.
The checklist and walkthrough above are what that looks like in practice.
Follow @damidefi on X for daily Claude AI tools, crypto analysis, and the full journey to 100K. Bookmark this. Share it with one person who is about to submit their first app.