Archives de rejet de la communauté

L'histoire de rejet de l'app store

Les pires boucles de rejet de l'Apple App Store et Google Play, collectées sous forme d'écran et de texte pour que les équipes mobiles puissent apprendre ce que les files d'attente de revue coûtent vraiment.

Règle de soumission

1 à 5 images plus le texte de l'histoire.

Aucun lien à l'intérieur des histoires. Utilisez uniquement des images locales. Gardez le rejet douloureux, spécifique et utile.

Histoires semées

Magasins couverts

5 max

Images par histoire

L'archive

Les refus qui coûtent plus qu'un sprint raté

Chaque histoire est textuellement présentée, accompagnée d'images et délibérément privée de liens externes afin de maintenir l'archive lisible.

Message d'examen d'application Apple demandant qui seront les utilisateurs de l'application d'Adrien

App Store d'Apple Absurde Partagé par Adrien

L'application dont les utilisateurs Apple ne pouvait pas identifier

"Qui seront les utilisateurs de cette application ?"

Adrien a soumis la version 1.0 et Apple a interrompu la revue en vertu de la ligne directrice 2.1, Informations nécessaires. Il n'y avait pas de rapport de crash, ni de fonctionnalité brisée, ni de demande de correction binaire dans le message. Le seul bloqueur était que Apple voulait une réponse détaillée expliquant qui l'application était pour avant que la revue puisse continuer.

Application: Application iPad Version 1.0
Attente: La revue est suspendue le 29 mai 2026
Résultat: Apple a demandé une explication sur l'utilisateur cible avant de poursuivre la revue.

Message de revue de l'App Store d'Apple disant que l'application d'Adrien n'était pas suffisamment différente des applications similaires

App Store d'Apple Douloureux Partagé par Adrien

L'application que Apple a décidé n'était pas suffisamment différente

"Il y a déjà suffisamment d'applications de ce type sur l'App Store."

Adrien a reçu un refus de Design - Spam car Apple n'a pas vu suffisamment de valeur distincte par rapport aux applications similaires. La revue a indiqué que l'application était principalement une application de fumée ou de borborygme, et même si elle avait des fonctionnalités qui la distinguaient, cette fonctionnalité était suffisamment évidente pour que Apple traite l'application entière comme du contenu dupliqué dans une catégorie saturée.

Application: Application de son pour divertissement
Retard: Rejeté le 15 mai 2026
Résultat: L'Apple a rejeté l'application en vertu de la ligne directrice 4.3(b), affirmant que l'application dupliquait une catégorie saturée.

Écran de guide de revue d'application utilisé pour représenter un flux de travail de rejet de l'App Store d'Apple

Interface de publication de l'App Store d'Apple utilisée pour représenter une revue retardée d'Apple

App Store d'Apple Blockeur de lancement

Le boucle de métadonnées qui a englouti la semaine de lancement

"La build était fine. Le rejet se déplaçait constamment de l'application aux mots autour de l'application."

Lequipe a expédié une build propre, puis a passé plus d'une semaine à faire tourner les objections de métadonnées. Chaque réédition répondait à la note précédente, mais la réponse suivante se concentrait sur une autre phrase, écran d'aperçu ou explication. Aucun code n'a été modifié. Le calendrier de lancement, la fenêtre de presse et le plan de recrutement payé ont été tous retenus prisonniers par la copie de revue.

Application: Application de productivité pour les consommateurs
Retard: 9 jours
Résultat: Approuvé après avoir réécrit les captures d'écran, les sous-titres et les notes de revue sans modification binaire.

Écran de gestion de la mise en ligne d'App Store Connect représentant un bloqueur de mise en ligne post-approbation

Écran de conformité d'App Store Connect représentant une étape supplémentaire de revue de conformité

App Store d'Apple Absurde

Approuvé, puis bloqué par une autre question de conformité

"L'email d'approbation est arrivé avant le bloqueur."

Le build a obtenu l'approbation, mais la mise en ligne était toujours bloquée par un prompt de conformité que l'équipe pensait avoir déjà répondu. Le propriétaire de la mise en ligne devait arrêter le lancement, rassembler les termes juridiques, mettre à jour la réponse App Store Connect et attendre à nouveau. Les clients ont vu l'annonce avant que l'application ne soit vraiment disponible.

App: Application de tableau de bord B2B
Retard: 4 jours
Résultat: Sorti après avoir répondu à nouveau à la conformité d'exportation et avoir attendu la prochaine passe de revue.

Écran de libération de Google Play Console représentant une libération bloquée

Écran d'upload d'artefact de Google Play Console représentant des soumissions Android répétées

Écran de sauvegarde et de publication de Google Play Console représentant une publication retardée

Google Play Cout élevé

Le temps perdu en politique de permission

"L'application avait besoin de la permission pour une seule écran, mais la revue l'a traité comme le produit entier."

Une permission Android étroite a déclenché une revue de politique large. L'équipe a documenté la fonctionnalité, ajouté des instructions pour les réviseurs, enregistré un chemin de démonstration et a dû encore supprimer la permission de la version principale pour libérer les clients. La dernière version a été expédiée avec un flux de travail dégradé tandis que l'équipe préparait une séparation de permission plus propre.

Application: Application de gestion des opérations
Retard: 13 jours
Résultat: Approuvé après avoir supprimé une permission, enregistré une nouvelle démonstration et réécrit la déclaration de magasin.

Écran de confirmation du console Google Play représentant une mise à jour de hotfix retardée

Interface de l'application mobile représentant une mise à jour de hotfix en production en attente de la revue du magasin

Console Google Play Les douleurs

La mise à jour de secours qui attendait dans une file d'attente de politique

"La caisse de paiement brisée était urgente pour les utilisateurs, mais pas urgente pour la file d'attente de revue."

Un bug de caisse nécessitait une correction rapide pour les appareils mobiles, mais la mise à jour de l'application était entrée en revue au pire moment. Les tickets de support ont grimpé tandis que l'équipe regardait le même statut en attente. Ils ont finalement atténué le problème côté serveur, puis ont regardé l'approbation binaire arriver après que l'urgence avait déjà brûlé tout le week-end.

Application: Application de commerce électronique
Retard: 6 jours
Résultat: Évitez l'histoire de l'horreur suivante

Envoyez des correctifs urgents avec __CAPGO_KEEP_0__ tandis que les magasins prennent leur temps.

Ship urgent fixes with Capgo while the stores take their time.

Capgo permet aux Capacitor d'envoyer des mises à jour en direct, de revenir sur des versions brisées et de cibler des canaux sans attendre un cycle de revue complet de l'App Store ou Google Play.

Le support humain de Martin aide les équipes à réussir.

Commencez avec Capgo Voir les mises à jour en direct

Ajouter une histoire de refus

Éditez les données de l'histoire, incluez un à cinq chemins d'accès à des images locales, et ouvrez un PR. Gardez les noms anonymes à moins que vous ne soyez le propriétaire de l'histoire.

Éditez sur GitHub