コミュニティの拒否アーカイブ
Apple App StoreとGoogle Playの拒否ループの最悪の例をスクリーンショットとテキストで収集し、モバイルチームが実際のレビューキューのコストを学ぶことができるようにします。
提出規則
1から5の画像とストーリーテキスト。
ストーリー内にリンクはありません。ローカル画像のみを使用してください。拒否を痛み、具体的、そして有益にしましょう。
6
ストーリー
2
対象のストア
最大5
ストーリーあたりの画像数
アーカイブ
各エピソードはテキストを中心に、画像をバックに、外部リンクを意図的に省略して、アーカイブが読みやすいようにしています。
「このアプリのユーザーは誰ですか？」
Adrienはバージョン1.0を提出し、Appleは審査を停止しました。理由はGuideline 2.1、情報が不足していることです。メッセージにはクラッシュレポート、機能が壊れたこと、バイナリ修正の要求はありません。ただし、審査を続行するには、アプリのユーザーを詳細に説明する必要があります。
「App Storeにはすでにこれらのアプリが多すぎます。」
アドリアンは、デザイン - スパム拒否を受けました。Appleは、類似アプリと比較して十分な独自の価値を見つけられなかったためです。レビューでは、アプリは主に風船や腹式呼吸アプリであり、機能が異なる部分があっても、その機能は目立つほどでした。Appleは、類似アプリが多くある分野のアプリ全体を重複コンテンツとして扱うことにしました。
「ビルドは問題なかった。拒否はアプリからアプリ周辺の言葉に移り続けた。」
チームはクリーンなビルドをリリースし、1週間以上メタデータの異議を唱えるサイクルを繰り返した。各リリースは前の注文に答えたが、次の返信は別のフレーズ、スクリーンショット、説明に焦点を当てた。codeは変更されなかった。リリースカレンダー、プレスウィンドウ、有料アクイジション計画はすべてレビューのコピーに囚われていた。
承認メールはブロッカーの到着よりも前に到着した。
アプリのビルドは承認されたが、リリースはまだコンプライアンスのポップアップによってブロックされていた。チームはすでに答えていたと考えていたが、実際にはまだ答えていなかった。リリースオーナーはロールアウトを停止し、法的用語を集め、App Store Connectの回答を更新し、また待つ必要があった。顧客はアプリが実際に利用可能になる前にアナウンスを確認した。
「アプリは1つの画面に必要な許可だったが、レビューでは全体の製品として扱われた。」
Androidの許可が狭いが、広範なポリシーレビューを引き起こした。チームは機能をドキュメント化し、レビューアーに指示を追加し、デモパスを記録し、最終的には主なリリースから許可を削除して顧客をブロック解除するために、まだ許可を削除する必要があった。最終的なビルドは、チームが許可のクリーンな分割を準備するために、劣化したワークフローでリリースされた。
"チェックアウトが壊れたことはユーザーにとって急務ではあったが、レビュー キューにとっては急務ではなかった"
チェックアウトのバグにはモバイル用の速い修正が必要だったが、ストアのリリースは最悪のタイミングでレビューに入った。サポート チケットは増え続けていたが、チームは同じステータスの待ち状態を眺めていた。チームは最終的にサーバー側で問題を緩和し、緊急事態がすでに週末を終えた後も、バイナリ アプローバルの到着を待った。
次のホラー ストーリーを避けよう
CapgoはCapacitorチームがライブアップデートを送信し、破損したリリースを巻き戻し、チャンネルをターゲットに設定することを待つ必要なくApp StoreまたはGoogle Playのフルレビューサイクルを待つことなく。
__CAPGO_KEEP_0__はマーティンから人間のサポートを受けます。
ストーリーのデータを編集し、1から5のローカル画像パスを含め、PRを開きます。名前を匿名にしない場合は、ストーリーの所有者です。
