コミュニティからの却下アーカイブ
Apple App Store と Google Play の拒否ループの最悪の例をスクリーンショットと平文で収集し、モバイルチームが実際にレビュー キューがどれだけコストを掛けているかを学ぶことができるようにします。
投稿規則
1 から 5 までの画像とストーリーテキスト。
ストーリー内にリンクは使用しないでください。ローカル画像のみを使用してください。拒否を痛み、具体的、そして役に立つものにしましょう。
6
ストーリーをシードする
2
カバーするストア
最大 5 つ
ストーリーあたり画像 5 つまで
アーカイブ
各ストーリーはテキストから始まり、画像をバックに、意図的に外部リンクを除外して、アーカイブが読みやすくなるように設計されています。
「このアプリのユーザーは誰ですか？」
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 チームは、App Store または Google Play の完全なレビューサイクルを待たずに、ライブアップデートを送信し、破損したリリースをロールバックし、チャンネルをターゲットにします。
ストーリー データを編集し、1 つから 5 つまでのローカル画像パスを含め、PR を開きます。名前は匿名のままにします。ストーリーを所有している場合除きます。