ストリーミングはほとんどのブラウザと
Developerアプリで視聴できます。
-
審査でよくある問題を回避するためのヒント
App Reviewチームが紹介するヒントを活用して、審査に向けてAppを準備する方法を確認します。最も一般的な問題を回避する方法や、スムーズに審査を通過するのに役立つベストプラクティスを紹介します。
リソース
関連ビデオ
Tech Talks
-
ダウンロード
Greg Bradley:App Storeの デベロッパの皆さん こんにちは App Store Review TeamのGregです 私たちの目標は デベロッパがApp Store で成功するようサポートすることです 私たちは国際的なチームで 80以上の言語に精通した 3大陸の審査担当者が 24時間体制で Appに対するフィードバックを 提供しています 今日は私たちのチームから 審査に向けてAppを準備する方法や よくある問題を回避する ためのヒントを紹介します これから紹介する3つのヒントは 審査で却下されたAppの30%に 見られる問題を回避するのに役立ちます そうした問題は 一般的である と同時に防げるものです Appを提出する前に これから紹介する ヒントを実行することで App Storeのユーザーに Appをリリースする準備と Appleの審査を受ける準備が整います この点をイメージするために ヒントをすべて実行して提出されたAppと そうでないAppがたどる道のり を見ていきたいと思います 「2つのAppの物語」です また Appを審査に提出する前や 提出時 および提出後に役立つ リソースについても紹介します Appを提出する際の3つのヒントとは Appを徹底的にテストして ユーザーに リリースできる状態にすること Appが提供するユニークな体験 について詳しく説明すること そして App審査を完全な形で実施できるよう アクセスを提供することです まず Appのテストについて説明します 素晴らしいコンセプトのAppであっても バグやクラッシュが発生すると せっかくの体験が台無しになってしまいます ですので 重大なバグを発見したり 審査中にAppがクラッシュしたりした場合 Appleはデベロッパに連絡して できる限り 問題解決に向けたサポートを提供します 問題の再現手順を共有し クラッシュした場合は クラッシュログを提供します 現実の使用条件が反映 されるよう すべてのAppを シミュレータ上ではなく 実際の デバイスで審査しています 審査中に発生する問題はAppを使用する すべてのユーザーにも影響を与えるので 問題を未然に防げるよう サポートしたいと考えています とはいえ バグやクラッシュを 修正する最適なタイミングは Appを審査に提出する前です App Reviewでは ユーザーが使用 する方法でAppを審査しますが それは必ずしも 適切なQAチームが品質保証 を行う方法ではありません 実際のデバイスで 品質保証や ベータ版テストを実施するのに 最適なツールは TestFlightです TestFlightを使えば 本番環境で公開する前に ベータ版で簡単に問題を解決できます ベータ版ビルドをApp Store Connectに直接アップロードして Apple Developer Program アカウントの 内部テスターにAppを配信できます また iOS iPadOS macOS およびtvOSの デバイスのユーザーを Eメールで招待するか パブリックリンクを共有することで ベータ版Appを共有することもできます TestFlightビルドもApp Store Reviewによる審査を受けます ベータ版テストを実施できなくなる 問題がある場合や App Storeに 掲載できないようなコンテンツ が含まれる場合 提出されたTestFlightが 却下されることがあります TestFlightの審査は AppがApp Storeに 提出される前に App Store Reviewガイドライン上の 問題をデベロッパが解決できる ようにするためのものです なお デベロッパアカウント からアクセスできるため デベロッパはすぐにテストを開始できます App StoreでAppが公開済みで 問題を修正するための重要な アップデートを提出する場合 Appleではそのアップデートがユーザーに 提供されるようデベロッパと協力します こうしたサポートには いわゆる 「バグ修正の提出」も含まれます これは アップデートの審査中に Appに問題が見つかった場合 Appleがデベロッパに連絡して 次回の提出時にその問題を 解決するつもりがあるかどうか をたずねるものです デベロッパにその意向があれば アップデートは承認されます このシンプルなプロセスの 対象に該当する場合は App Store Connect上の メッセージで通知されます ただし 法的な問題や 信頼性 安全性に問題があるAppは このプロセスの対象外です では 2つのAppが提出されるシナリオを例に これらの準備について考えてみましょう App名は それぞれ TurtlrとR-bitとします 一方のAppは デベロッパが時間をかけて 業界標準の品質保証プロセスを 実行してから提出されましたが もう一方はデベロッパが手抜きをして Appのテストもそこそこに提出したとします イソップ物語をご存じの方は 名前からどんな結果になるか きっともうお分かりだと思います TurtlrはTestFlightを使用して 品質保証のプロセス全体を 実行したので デベロッパが胸を張って バグがないと言える状態であり テストされたすべてのデバイスで 非常にスムーズに動作しています R-bitはTestFlightを使用せず 包括的ではない品質保証を簡単に行いました その結果 R-bitには いくつかのバグが残っていて 審査担当者がサインインしようとすると クラッシュすることがありました では 2つ目のヒントに進みましょう 提出する際は Appについて できるだけ詳しく入力してください 素晴らしいAppを開発いただいたので Appleとしてはデベロッパ自身の言葉で 表現されたAppのコンセプトや機能を 読みたいと思っています App Store Connectで Appバージョンのページの 「App Reviewに関する情報」に Appに関する情報を すべて入力してください 新規Appを初めて提出する場合は Appのコンセプトや Appの主な機能を 有効にする方法に加えて ターゲットユーザーについても 説明できます 大きなアップデートを提出する場合は 変更点および 重要な新規コンテンツを確認 できる場所を教えてください なお Appの変更に伴い 以前の提出時に回答いただいたのと同じ 質問をする場合があります これは Appに対するAppleの理解が 順次追加されるすべての改善点や 新機能を踏まえたものになって いるかを確認するためです またAppによっては 規制当局からの書類や 保護されたコンテンツの 使用許可を証明するものなど 追加書類が必要になる場合があります 例えば 医療用ハードウェアと 同期するAppについて しかるべきプロセスを経て 規制に関わる承認を取得した場合は Appの初回提出時に その書類を添付できます 書類を提出すべきかどうか判断に悩む場合 特に規制が厳しい分野に関しては Appに関する情報をできるだけ多く Appleに提供してください 追加書類が必要な Appについて詳しくは ガイドラインの1.3, 1.4, 4.1, 5, および5.2 を参照してください Appを提供する地域の法令に 準拠するかどうか決めるのは デベロッパです コンテンツや機能について 追加情報が必要な場合は 「Information Needed」の メッセージで通知されます とはいえ Appを利用するユーザーが どのような質問をするかを デベロッパが予測できれば その情報はAppの審査を 効率化するのに役立ちます さて 先ほどのシナリオの 続きに戻って考えましょう Turtlrでは デベロッパが時間 をかけてAppを十分に説明し Appのターゲットユーザーについて Appの説明欄だけでなく App Review のメモ欄にも記載しました また 規制当局の承認を 得るための書類が必要かどうか 確証を持てませんでしたが とにかく提出しておきました R-bitのマーケティングプランは 話題性を高めるため故意に内容を 明示していないこともあり 不明な点が多すぎます というのも Appが審査に提出された段階で Appの内容や機能について あまり情報が提供されていないので 全容を把握するのに時間がかかります Appを起動するにも ちょっとしたコツが必要です それでは スムーズなAppの提出に役立つ 3つ目のヒントを見ていきましょう AppleではApp全体を審査するので アカウントベースの機能がある場合は アカウントがある場合とない場合の App体験を審査する必要があります このためには デモアカウントを使用するか デモモードを作成します まず デモアカウントについて説明します 審査担当者がアカウントベースの機能すべてに 簡単にアクセスできるように App Store Connectに用意した デモアカウントの最新のログイン 認証情報を提供してください アカウントを最新の状態に 保つことは重要な手順です 審査ではAppの登録フローの確認のために 新規アカウントを作成する場合がありますが 一方で アカウントを作成済みの ユーザーの環境で Appが想定通りに動作することを 確認する必要もあるからです Appにアカウント作成機能がない場合は この最新のログイン認証情報の 提供がいっそう重要になります また Appのコンセプトに基づいて アカウントの作成が妥当であれば 関連コンテンツが入力されたフル機能 のデモアカウントを用意することで Appを最大限にアピールできます 例えば ソーシャルメディア プラットフォームを作成している場合 Appが提供するサービスや ユーザー体験などの コンテンツを確認できる デモアカウントを用意できます 機密性の高いユーザー情報を扱うAppや アカウントの新規作成に制限を設けている 規制の厳しい業界のAppなどの場合 社内のQAチームやマーケティングチームが すでに使用しているような デモモードの作成を検討してください デモモードでは代替データを使用しながら Appのすべてのコンテンツと 機能を示すことができます デベロッパが Appleを含め 外部に公開できないデータを 扱っている場合もあると思います デモモードを使用すれば ユーザーの機密情報を 侵害することなく Appの ユーザー体験全体を 審査担当者が 確認することができます このデモアカウントの準備を もう一度あのウサギとカメの例で 考えてみましょう Turtlrのアカウントは最新の 状態に保たれ 機能していました まさかと思われるかもしれませんが 認証情報が無効または 期限切れのアカウントは 審査で頻繁に見受けられます 提供されたTurtlrのアカウントでは 関連コンテンツにアクセスでき まるでこのAppを毎日 使用しているユーザーの 実際のアカウントを見ているようでした これにより 審査担当者は自然な ユーザー体験ができました Appを初めて起動したのに まるでずっと使っていたかのような感覚です 一方 R-bitのデモアカウント は期限切れでした そうなると 審査担当者は アカウントの新規作成を試すか 最新の認証情報をあらためて リクエストする必要があります ゴールが近づいてきました TurtlrとR-bitのどちらが 先にゴールできるでしょうか では いよいよ 「2つのAppの物語」の結論を見てみましょう Turtlrは3つのヒントをすべて守り 比較的簡単なことをいくつか実行しました Appの品質保証を行い 詳細な情報を提供し デモアカウントが有効で 機能していることを 確認しました R-bitはAppのテストを 少しだけ行ったものの すべての問題を検出するには不十分でした 審査担当者や将来のユーザーに対して Appの使い方に関するガイダンスがあまりなく デモアカウントの期限はAppが提出 される前の時点で切れていました TurtlrのデベロッパがAppを提出する ための準備に時間をかけたことは 結果的に時間の節約になりました Appは審査に提出され 徹底的な検証の結果 問題は検出されなかったので Appは承認されました 一方 R-bitはいくつかの 障害に直面しています デモアカウントは機能せず バグがいくつか起きていたり コンセプトが不明瞭だったりと Appのユーザビリティにも問題があるため App StoreでのAppの公開には 時間がかかると思われます 両Appとも結果的には承認されましたが より綿密な準備をして提出したことで こちらのTurtlrが あの物語に出てくるカメのように 最後には勝利を手にしたのです 結果が出るまでに 実際どのくらい 時間がかかるのでしょうか 90%のAppは 24時間以内に 審査を完了しています 通常1日程度で Appleから 却下または承認の通知が 届きます つまりAppに問題がなければ 24時間以内に審査 および承認される可能性が 高いということです また 修正すべき点があれば 24時間以内に連絡があるでしょう とはいえ 問題の解決に何度か 提出が必要な場合は Appを承認できる状態になるまで 数日かかることがあります Appの世界では 1日と数日の違いが 大きな差を生むことがあるので 何度も提出したり審査を受けたりせずに 承認されるよう Appを 準備するためのヒントを 皆さんにお伝えしています 最後に AppをApp Storeに 提出する際に参照できる 関連リソースを紹介します 最初のリソースは あなたの Appを審査した担当者です App Store Reviewから Appの問題点について連絡があり 要件がよく理解できない場合は App Store Connectで 届いたメッセージに直接返信して 知らせてください 問題点を説明し ガイドラインを理解できるよう サポートします 重大なバグの修正や 開催日が迫っているイベントに 合わせたアップデートの提出など 正当な理由がある場合 デベロッパはApp Reviewの 優先処理をリクエストできます 事情をお聞かせいただければ できる限りのサポートを行います Appが誤解されていると思われる場合や 審査結果に合意できない場合 デベロッパはApp Review Boardに 異議の申し立てを行うことができます その場合は App Review Boardが 検討しやすいように Appがガイドラインに準拠していると言える 具体的な理由を必ず提示してください 優先処理のリクエストや異議の申し立て を行うフォームへのリンクについては Apple Developer Webサイト の「App Review」ページに 掲載されています このページでは 審査に向けて Appを準備するための様々なヒントや 注意すべきその他の一般的な問題 についての情報が掲載されています 以上 ご視聴ありがとうございました 私たちは App Storeデベロッパの 皆さんの 今後のさらなる活躍を楽しみにしており App Storeでの成功を サポートできることを心待ちにしています
-
-
特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。
クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。