AppleのApp Review新ヘルプ記事を、Mac開発者が読む

結論

2026年11月のHello Developerのお知らせで、AppleはApp Reviewの新しいヘルプ記事を紹介しました。私たちの多くがリジェクトを通じて学んできたことが、文章になっています。Appleは、提出の50%を24時間未満で、90%を48未満で審査することを目指しています。デモ用ログインは審査が始まるときにも使えなければなりません。質問に答えるために再提出せず、App Store Connectで返信します。「Bug Fix Submissions:」で始まるリジェクトでは、修正版を公開して、問題は次回に対応できます。スクリーンショットの半数より多くは、アプリを使っている様子を見せる必要があります。そして、すべての権限に、それぞれ明確なpurpose stringが必要です。Macに明確に触れている記事は1つだけですが、どのルールもMac App Storeへの提出に当てはまります。

App Reviewについて私が知っていることの大半は、リジェクトのメールから学びました。だから、Appleの2026年11月のHello Developerに「Browse new App Review help articles」とあったとき、全部読みました。今はApp Review Helpにまとめられていて、これまで言い伝えのようだったことの多くがはっきり書かれています。

Macアプリにとって大事な内容と、次の提出の前に私なら何を直すかをまとめます。

まず、この記事の対象者

App Reviewが見るのは、App Store Connectを通るものだけです。Mac App Store、TestFlight、In-App Purchasesなどが該当します。Developer IDを使って自分のサイトでMacアプリを販売する場合、Appleの誰かが審査することはありません。通るのは公証で、これは自動のチェックです。直接配布だけなら、さっと目を通して、Mac App Storeに出す日のために取っておいてください。

審査にかかる時間

審査状況の記事には、Apple自身の目標が書かれています。提出の少なくとも50%を24時間未満で、90%を48時間未満で審査するというものです。また、審査が遅くなる要因として、審査の履歴が少ないこと、Appleが必要とする書類、複雑または新しい問題などが挙げられています。

私ならこうします。ローンチ日の前に丸2日の余裕を持たせて計画します。初めてのアプリなら、もっと余裕を取ります。そして早めに提出し、手動リリースにして、公開する分を自分で選べるようにします。

審査はNotes欄で決まる

完全な審査についての記事ははっきりしています。「不完全な提出はリジェクトされます。」重要な点は次のとおりです。

デモ用ログインは、提出時だけでなく審査が始まるときにも使えなければなりません。その間に期限切れになったり変更されたりするテストアカウントは、リジェクトの原因になります。
ログインにコードが必要なら、Notesに書いてください。書かないと、Appleが電話での確認を必要とする場合があり、通話は通常3〜5営業日以内に行われます。それだけで1週間が過ぎてしまいます。
サブスクリプションには、期限切れのサブスクリプションを持つデモアカウントが必要です。審査担当者が購入の流れを最初から最後まで確認できるようにするためです。

私ならこうします。Notes欄は、初めて見る人向けの短い手順書のように書きます。最初にどこをクリックするか、どのアカウントを使うか、ウィンドウのないアプリならメニューバーのアイコンが何をするか、です。最後の点はとてもMacらしいところです。

リジェクトされたとき

何年も前に文章で読めていたらよかった、と思う部分です。

質問に答えるために再提出しないでください。App Reviewから情報を求められたら、App Store Connectで返信します。再提出するのは、ビルドの修正が必要なときだけで、指摘された問題をすべて直してからにしてください。
冒頭に「Bug Fix Submissions:」がないか確認してください。リジェクトの通知がこの一文で始まっていれば、Bug Fix Submissionsの記事によると、返信で承諾し、問題は次のアップデートで対応できます。再提出はしないでください。以前に承認されたことのあるアプリだけが対象で、法律や安全に関わる問題には使えず、同じ問題を2回先送りすることもできません。
加速審査は本当に必要なときだけ。Appleは、加速審査のリクエストは「本当に緊急の場合に限る」べきで、すでに審査に提出したビルドだけが対象だと述べています。イベントに合わせたローンチなら、イベント名と日付をNotesに書いてください。
異議申し立ては最後に。まず審査結果に返信して事情を説明します。それでも解決しない場合、App Review Boardはアプリごとに1回だけ異議を受け付けます。再提出すると、その却下に対しては異議を申し立てられなくなります。

数字つきの4つのルール

ガイドラインの記事は短く、具体的です。

スクリーンショット、2.3.3。スクリーンショットの半数より多くは、アプリを実際に使っている様子を見せる必要があります。数えるのはデバイスの種類ごとです。3枚なら、2枚はアプリの画面でなければなりません。スプラッシュ画面やタイトルカードは、少数であれば問題ありません。MacPipのスクリーンショットチェッカーはサイズを確認します。残りは自分で数えてください。
模倣アプリ、4.1。どのメタデータ欄にも、人気アプリの名前や商標用語を入れないでください。キーワード欄も対象で、競合の名前を入れてしまうのが定番のミスです。App Storeキーワードチェッカーは各欄の文字数を数えるので、中身を確認できます。
purpose string、5.1.1(ii)。保護されたリソースごとに、それぞれ明確なpurpose stringが必要です。アプリがローカライズされているなら、purpose stringもローカライズします。Apple自身が挙げる悪い例は「To use location.」です。SDKが要求する内容についても、責任はあなたにあります。Info.plistをInfo.plist解説ツールに貼り付けると、空のものや曖昧なものを指摘します。
アカウント削除、5.1.1(v)。アプリ内でアカウントを作れるなら、アプリ内で削除を始められるようにする必要があります。無効化だけでは足りず、電話をかけさせることもできません。サブスクリプションがある場合は、解約するまでAppleを通じて課金が続くことを伝えてください。

Macについての1行

Macに触れているのは、対応デバイスの記事だけです。対応するiPhoneアプリとiPadアプリは、Apple siliconを搭載したMacで変更なしに動作すること、そしてキーボードではできないタッチ操作に頼るアプリはmacOSにあまり向かないことが書かれています。iPadアプリを作っている方は、Mac App Storeに表示されていないか確認し、キーボードとトラックパッドでうまく使えないなら、表示をオフにしてください。同じページには、TestFlightでは内部テスターを最大100人、外部テスターを最大10,000人まで招待でき、外部テスターに渡す最初のビルドもApp Reviewに回ることが書かれています。

What's Newも審査の対象です

ガイドラインからもう1つ、新しい記事ではないものを。Guideline 2.3.12は、What's Newのテキストには新機能と変更点を書く必要があり、汎用的な一文で済ませられるのは単純なバグ修正とパフォーマンス改善だけだと定めています。新機能のあるリリースに「Bug fixes and improvements」と書くのは、質問を呼び込むようなものです。

そこで、今日の新しい無料ツールはリリースノートフォーマッターです。大まかなメモやgit log --onelineの行を貼り付けてください。新機能、改善、修正に振り分け、chore、ci、mergeの行を除き、チケット番号とファイル名に印を付け、4,000文字の上限を確認して、3つのコピーを用意します。App Store Connect用のプレーンテキスト、Sparkle appcast用のHTML、GitHub用のMarkdownです。メモはブラウザの中にとどまります。これらを載せるフィードの確認には、隣にあるSparkle appcastチェッカーが使えます。

私の短いリスト

ローンチ日まで丸2日の余裕と、手動リリース。
初めての人でも読み進められるNotes欄と、使えるデモアカウント。
質問されただけなら、再提出ではなく返信する。
スクリーンショットの枚数を数え、purpose stringを一つ残らず読み、キーワードに他のアプリの名前を入れない。
何が変わったかがわかるWhat's New。

そして公開されたら、Mac App Storeにあるかどうかに関係なく、MacPipへの掲載は無料です。掲載は提出時に自動でスキャンされ、青いチェックは、ある日に人が実際にアプリを試したことだけを意味します。

出典

続けて読む

アプリを登録開発者向けの無料ツール

AppleがApp Reviewの仕組みを文章にしました。提出前に私が直すことをまとめます