コミュニティからの却下アーカイブ
Apple App StoreとGoogle Playの拒否ループの最悪の例をスクリーンショットと平文で収集し、モバイルチームが実際にレビューキューがどれだけコストを掛けているかを学ぶことができるようにします。
投稿規則
1から5の画像と投稿テキスト。
投稿内にリンクはありません。ローカル画像のみを使用してください。拒否を痛み、具体的、そして役に立つものにしましょう。
6
投稿されたストーリー
2
カバーされているストア
最大5
1つの投稿あたりの画像数
アーカイブ
各ストーリーはテキストから始まり、画像で裏付けられており、意図的に外部リンクがなく、アーカイブが読みやすくなるように設計されています。
「このアプリのユーザーは誰ですか？」
Adrien がバージョン 1.0 を提出し、Apple はガイドライン 2.1、情報が必要ですという理由でレビューを停止した。メッセージにはクラッシュレポート、機能が壊れたり、バイナリ修正が求められたりするものはなかった。ただし、レビューが続行できるのは、アプリが何のために作られたのかについて詳細な回答が必要だったためだった。
"There are already enough of these apps on the App Store."
App Storeにはすでにこれらのアプリが十分にある。
「ビルドは問題なかった。却下はアプリからアプリの周りの言葉に移り続けた。」
チームはクリーンなビルドをリリースし、1週間以上メタデータの異議を唱えるサイクルを繰り返した。各リサブミッションは前の注文に答えたが、次の返信は別のフレーズ、スクリーンショット、または説明に焦点を当てた。codeは変更されなかった。リリースカレンダー、プレスウィンドウ、有料アクイジション計画はすべてレビューのコピーに囚われていた。
「承認メールはブロッカーよりも先に到着した。」
ビルドは承認されたが、リリースはまだコンプライアンスのポップアップによってブロックされていた。チームはすでに答えていたと考えていたが、実際にはまだ答えていなかった。リリースオーナーはロールアウトを停止し、法的表現を集め、App Store Connectの回答を更新し、また待つ必要があった。顧客はアプリが実際に利用可能になる前にアナウンスを確認した。
"アプリは1つの画面で許可が必要だったのに、レビューでは全体の製品として扱われた"
Androidの許可が狭いが、広いポリシーレビューを引き起こした。チームは機能をドキュメント化し、レビューユーザーに指示を追加し、デモパスのレコードを作成し、依然として主なリリースから許可を削除して顧客をブロックするのを防ぐために、まだ許可を削除する必要があった。最終的なビルドは、許可のクリーンな分割を準備するチームのために、劣化したワークフローで出荷された。
"ユーザーにとってはチェックアウトが壊れたことは急いでいたが、レビュー キューにとっては急いでいなかった."
チェックアウトのバグには急いでいるモバイルの修正が必要だったが、ストア リリースは最悪のタイミングでレビューに登録されていた。サポート チケットは増え続けていたが、チームは同じステータスの待ち状態を眺めていた。チームは最終的にサーバー側で問題を緩和し、緊急事態がすでに週末を乗り越えていたことを確認した後、バイナリ アプロバルが到着した。
次のホラー ストーリーを避けよう
Capgo は Capacitor チームにライブアップデートを送信、破損したリリースをロールバック、チャンネルをターゲットに設定することを可能にします。アプリストアまたはGoogle Playのフルレビューサイクルを待つ必要はありません。
__CAPGO_KEEP_0__ のデータを編集して、1 から 5 までのローカル画像パスを含み、PR を開きます。名前は匿名化しておきます。ストーリーの所有者でない限り。