Ce que coûte une critique de l'App Store aux équipes

Afficher tous les 39 récits.

1. 

   4.3(a) Spam iOS Lignes directrices 4.3

   Tout le portefeuille signalé en même temps

   Ce qui s'est passé

   A un développeur avec plusieurs applications créées à partir du même projet de démarrage, on a trouvé le même avis 4.3 sur chacune d'elles : les applications partageaient un code binaire, des métadonnées ou une idée similaires avec des différences mineures seulement. Ils ont décidé de travailler sur les applications une à la fois.

   Résolution

   En cours de réalisation au moment de la publication.

   Leçon

   4.3(a) couvre également les chevauchements entre vos propres applications. Si plusieurs applications sont issues d'un même modèle, chacune doit avoir un noyau réellement distinct, et non simplement un nouveau logo et un nom.

2. 

   4.3(a) Spam iOS Ligne directrice 4.3

   La même lettre deux fois en une semaine

   Ce qui s'est passé

   Au milieu de la nuit, une petite application photo à usage unique a été rejetée en vertu de l'article 4.3(a), une semaine après avoir reçu le même texte de rejet exact pour une version antérieure.

   Résolution

   Non précisé.

   Leçon

   Réessayer avec des changements cosmétiques n'a rarement d'effet sur une décision 4.3. Changez de concept ou expliquez clairement dans les notes de revue ce qui rend l'application différente.

3. 

   4.3 Conception / Spam iOS La ligne directrice 4.3

   Construire dans une catégorie surpeuplée

   Ce qui s'est passé

   A un constructeur solo documentant un défi de construction quotidienne, un rejet de conception/design de 4,3 / Spam le jour quatre a commencé à remettre en question si le choix d'une catégorie saturée avait été une erreur.

   Résolution

   Non indiqué.

   Leçon

   Catégories que Apple considère saturées sont soumises à une plus grande attention. Vérifiez ce qui différencie votre application avant de la construire, et non après la revue.

5. 

   2.1 Informations nécessaires iOS Lignement 2.1

   Sept questions pour un nouveau compte

   Ce qui s'est passé

   Un premier dépôt d'une équipe a été retourné sous 2.1 Informations nécessaires : sept questions, une demande de capture d'écran et un compte de démonstration. La réponse honnête a révélé quatre choses qu'ils avaient manquées.

   Résolution

   Ils ont corrigé les problèmes et ont répondu.

   Leçon

   Nouveaux développeurs devraient s'attendre à cela. Préparez un compte de démonstration, une enregistrement et des notes de revue claires avant de soumettre.

6. 

   2.1 Complétude de l'application iOS La ligne directrice 2.1

   Le réviseur n'a pas pu suivre l'application

   Ce qui s'est passé

   Un développeur débutant a été rejeté deux fois avant de passer en ligne. Le premier rejet, en vertu de 2.1, est survenu parce que le réviseur n'a pas pu comprendre comment l'application devait être utilisée.

   Résolution

   Apruvé après avoir ajouté une vidéo de démonstration enregistrée sur un appareil réel et des notes de revue étape par étape.

   Leçon

   Les réviseurs ont des minutes, pas de contexte. Dites-leur exactement ce qu'ils doivent appuyer et ce qu'ils devraient voir.

7. 

   Metadata and in app purchase setup iOS Métadonnées et achats en ligne

   Deux rejets pour des cases à cocher connues

   Ce qui s'est passé

   Un développeur indépendant a été rejeté deux fois pour des choses qu'il connaissait déjà. Tout d'abord, la build a été envoyée sans ses achats en ligne attachés et la description n'a pas lié les termes d'utilisation. Quelques semaines plus tard, un écran d'écriture a décrit l'application comme étant gratuite.

   Résolution

   Réparé et resoumis chaque fois.

   Leçon

   Conservez un checklist pré-submission pour les métadonnées, les abonnements et les liens juridiques. La plupart des refus de métadonnées sont évitables.

8. 

   Temps de file d'attente de revue iOS Revue sans fin

   9 jours d'attente, puis 8 jours en revue

   Ce qui s'est passé

   Un développeur a attendu neuf jours pour que le statut passe de Waiting for Review à In Review, puis il a attendu huit jours de plus en revue sans aucune mise à jour.

   Résolution

   Aucune à la date de publication.

   Leçon

   Les temps de revue ne sont pas garantis. N'attachez jamais une date de lancement, une conférence de presse ou une campagne créatrice à une date d'approbation attendue.

9. 

   Temps de file d'attente de revue iOS Revue sans fin

   20 jours dans le boucle de refus, correction, attente

   Ce qui s'est passé

   Plus de 20 jours, le développeur a connu rejet, correction, en attente de révision, rejet, correction, et attendait toujours au moment de la publication.

   context

   Résolution

   En attente.

   Chaque voyage aller-retour peut durer des jours. Rassembler toutes les corrections d'un refus dans une seule mise à jour.

10. 

    Annulation de compte iOS Annulation de compte

    Clôturé avant la première critique

    Qu'est-ce qui s'est passé

    Un développeur de dix ans d'expérience a vu son compte développeur annulé, avec une accusation de fraude qui ne disait pas ce qu'il avait fait, tandis qu'un jeu de langues était toujours en attente de sa première critique. Ses applications existantes ont disparu et les clients ont commencé à demander pourquoi.

    Résolution

    Aucune signalée.

    Leçon

    Une annulation de compte supprime toutes les applications à la fois. Gardez votre propre canal vers les utilisateurs (courriel, site web) afin de pouvoir les contacter si la boutique disparaît.

11. 

    Avertissement de résiliation de compte iOS Résiliation de compte

    Nombre de versions rejetées trop élevé

    Qu'est-ce qui s'est passé

    Un développeur indépendant prolifique a reçu un avis selon lequel son compte serait résilié dans dix jours. Apple a indiqué que le nombre de versions rejetées faisait partie des raisons. Après une attention publique et un recours, le compte n'a pas été résilié.

    Résolution

    Le compte a été conservé après recours.

    Leçon

    Les refus s'accumulent. Évitez les réinscriptions du même jour avec des changements uniques et des clones presque identiques de vos propres applications.

12. 

    Exigence de connexion (numéro de ligne directrice non indiqué) iOS Exigence de connexion

    Inscription requise : vous n'êtes pas une grande application.

    Qu'est-ce qui s'est passé

    Une application sociale de développeur a été rejetée car elle exigeait que les utilisateurs créent un compte avant d'accéder au flux de la page d'accueil. Lorsque le développeur a expliqué que chaque utilisateur a besoin d'un pseudonyme pour que l'application fonctionne du tout, et a fait référence à un réseau photo majeur qui fait la même chose, le réviseur a répondu, en substance, que leur application n'était pas ce réseau.

    Résolution

    Non indiqué.

    Leçon

    Ce que les grandes applications obtiennent grâce à quoi n'est pas un précédent que vous pouvez citer. Si vous exigez l'inscription, expliquez dans les notes de revue pourquoi la fonctionnalité de base ne peut pas fonctionner sans un compte, et considérez laisser les réviseurs ou les invités voir du contenu avant.

13. 

    4.3 Spam iOS Ligne directrice 4.3

    De pas de révision à presque tout refusé

    Ce qui s'est passé

    Un développeur n'a vu aucune de leurs applications être examinées pendant des jours. Au fil d'une semaine environ, tandis qu'ils attendaient, ils ont créé plus de soumissions. Lorsque la révision a enfin bougé, presque toutes d'entre elles sont revenues refusées en vertu de la ligne directrice 4.3 spam.

    Résolution

    Non indiqué.

    Leçon

    Une file d'attente bloquée n'est pas un signal pour soumettre plus. Accumuler des soumissions pendant que rien n'est examiné peut faire de votre compte une forme de modèle de spam une fois que l'un des examinateurs les voit tous ensemble.

14. 

    4.3 Spam iOS Ligne directrice 4.3

    Les applications non liées rejetées ensemble

    Ce qui s'est passé

    Un développeur avait plusieurs applications, construites sur des mois et non liées les unes aux autres, toutes rejetées en même temps comme du spam. Il a demandé publiquement si cela était normal.

    Résolution

    Non indiqué.

    Leçon

    4.3 peut être appliqué au niveau du compte, et non application par application. Si plusieurs applications sont rejetées en même temps, répondre à chaque une séparément et détailler dans les notes de revue ce qui rend chaque application distincte.

15. 

    Temps de file d'attente de revue iOS Revue sans fin

    Un rejet, puis deux mois de silence

    Qu'est-ce qui s'est passé

    Après un rejet unique, l'application d'un développeur est restée en revue pendant environ deux mois, chaque cycle de revue prenant environ un mois. Ils soupçonnaient que les cycles longs étaient devenus un moyen de garder les nouvelles applications à l'écart.

    Résolution

    Encore bloqué à la date de publication.

    Leçon

    Après un rejet, le prochain cycle peut être beaucoup plus lent que le premier. Assurez-vous que votre resubmission soit complète et bien documentée afin d'éviter de passer un autre mois dans une deuxième ronde.

16. 

    Contenu inacceptable iOS Contenu inacceptable

    Rejeté pour résoumission sans correction

    Qu'est-ce qui s'est passé

    Une application d'édition photo par IA a été rejetée car elle avait été resubmise plusieurs fois sans corriger le problème signalé par Apple, qui concernait du contenu inacceptable.

    Résolution

    Rejeté.

    Leçon

    Réessayer la même build en espérant une autre évaluateur peut vous nuire. Corrigez le problème signalé ou demandez des précisions via le Centre de Résolution avant de résoumettre. Pour les fonctionnalités d'IA générative, ajoutez des filtres pour le contenu que Apple considère inacceptable.

17. 

    4.3 Spam iOS La ligne directrice 4.3

    Rejeté au même instant où la revue a commencé

    Ce qui s'est passé

    Un développeur a passé des semaines à construire une application et elle a été rejetée sous 4.3 spam dans la même minute où elle est entrée en revue. Ils croyaient que le réviseur avait jugé la niche, et non l'application.

    Résolution

    Non indiqué.

    Leçon

    Dans les niches bondées, un rapide 4.3 peut arriver avant que personne n'examine de près. Commencez vos notes de revue par ce qui est unique et montrez au réviseur directement vers cela.

18. 

    4.2.6 Modèle iOS Règle 4.2.6

    Signalé pour un modèle qui n'a jamais été utilisé

    Ce qui s'est passé

    Une équipe a été rejetée en vertu de la règle 4.2.6, qui couvre les applications créées à partir d'un modèle commercialisé ou d'un service de génération d'applications, même si elles n'ont utilisé aucun modèl’ou service de génération à l'heure actuelle.

    Résolution

    Non indiqué.

    Leçon

    4.2.6 peut être un faux positif. Répondez dans le Centre de résolution en déclarant clairement que l'application est construite sur mesure et qui l'a construite, et proposez de montrer le code source ou l'histoire de développement.

19. 

    3.1.2 Abonnements iOS Règle 3.1.2

    Le prix mensuel était plus élevé que le prix facturé

    Ce qui s'est passé

    Un développeur a vu son mur payant refusé car il montrait le prix mensuel calculé d'une abonnement plus long plus en évidence que le montant réellement facturé. Le même mur payant avait passé les évaluations précédentes sans commentaire. Ils étaient d'accord avec la règle mais frustrés qu'il était signalé seulement maintenant, et ont redessiné le mur payant pour donner la priorité au montant facturé.

    Résolution

    Résubmit avec le nouveau design.

    Leçon

    Un mur payant qui a passé avant peut toujours être refusé plus tard. Faites toujours le montant facturé et la période le plus visible; montrez toute la décomposition par mois plus petite et secondaire.

20. 

    Enregistrement (pas une directive d'examen d'application) Programme de développeur Apple Enregistrement et compte

    Deux mois, puis une refus avec aucune raison

    Ce qui s'est passé

    Un développeur a passé plus de deux mois pour s'inscrire, avec plusieurs appels et emails de support, vérification d'identité, détails de dispositif et même des preuves vidéo. Apple a ensuite rejeté l'enregistrement sans donner une raison spécifique.

    Résolution

    Aucune à la date de publication.

    Leçon

    L'enregistrement peut prendre beaucoup plus de temps que la construction de l'application. Commencez l'enregistrement tôt, avant que votre plan de lancement ne s'en dépende, et gardez un enregistrement de chaque échange de support.

21. 

    5.1.2 Utilisation et partage de données iOS Article 5.1.2

    Une refus de transparence de l'application qui menaçait une startup

    Qu'est-ce qui s'est passé

    Après quelques mois de livraison rapide et de solides commentaires des utilisateurs, l'application d'une startup a été rejetée à la fin de l'automne en raison de l'App Tracking Transparency, la règle de confidentialité iOS qui exige la permission de l'utilisateur avant de suivre à travers les applications et les sites Web. Le fondateur a plus tard décrit cela comme un rejet qui a mis toute la société en danger.

    Résolution

    Non indiqué dans l'article.

    Leçon

    Vérifiez chaque SDK dans votre application pour le suivi avant de soumettre. Si quelque chose relie les données de l'utilisateur aux données d'autres sociétés, vous avez besoin de la demande de permission de suivi et des étiquettes de confidentialité correspondantes, même si le suivi provient d'une bibliothèque tiers.

22. 

    Connexion (numéro de ligne de conduite non indiqué) iOS Connexion

    Le rédacteur n'a pas pu se connecter avec Apple ou Google.

    Qu'est-ce qui s'est passé

    To stop bot signups, a developer removed email and password login and kept only Sign in with Apple and Google sign in. It worked on their own iPhone and iPad, and even for the previous reviewer, who had rejected the app for a different reason. The next reviewer rejected it because they could not log in.

    Resolution

    Résolution

    Non indiqué.

    If your app only offers social login, reviewers can still get stuck. Give them a working path in the review notes, such as a demo account or a review only login, and test sign in on a fresh device and account before each submission.

23. 

    Jeux de hasard simulés (numéro de ligne non indiqué) iOS Jeux de hasard simulés

    Une fonctionnalité de mise en jeu dans un compte individuel

    Ce qui s'est passé

    Un jeu a été rejeté pour inclure des jeux de hasard simulés : les joueurs pouvaient miser des éléments de jeu les uns contre les autres, un mécanisme courant dans les anciens jeux de rôl’en ligne. Puisque le développeur a publié sous un compte individuel plutôt qu'une entreprise, ils ont décidé de supprimer la fonctionnalité pour l'instant.

    Résolution

    Supprimer la fonctionnalité et résoumettre.

    Leçon

    Les mécanismes de jeu de hasard reçoivent une plus grande attention même sans argent réel, et certaines choses que Apple autorise dépendent de votre type de compte et de vos documents. Vérifiez les règles de jeu de hasard avant de créer des fonctionnalités de mise, de butin ou de pari, et planifiez votre type de compte de développeur en fonction d'elles.

24. 

    Documents fictifs (numéro de ligne non indiqué) iOS Documents fictifs

    A PDF editor blamed for what users might do

    Ce qui s'est passé

    Un éditeur de PDF a été rejeté car Apple a dit qu'il permettait aux utilisateurs de créer des faux identités et des documents fictifs. Le développeur a argué que, par la même logique, tout application bancaire ou de messagerie pourrait être rejetée pour ce que les acteurs malveillants pourraient faire avec elle.

    Résolution

    Non indiqué.

    Leçon

    Les outils de usage général peuvent être jugés par leur utilisation la plus mauvaise possible. Évitez les modèles ou les campagnes de marketing qui ressemblent à des documents officiels ou des certificats, et expliquez dans les notes de revue ce que l'application est pour et ce qu'elle ne prend pas en charge.

25. 

    Partage de données AI (numéro de ligne directrice non indiqué) iOS Partage de données AI

    Pas d'écran de consentement pour le partage de données AI tiers

    Ce qui s'est passé

    Une équipe a obtenu leur première refus pour partager des données d'utilisateur avec un fournisseur AI tiers. Apple a exigé une autorisation explicite des utilisateurs ainsi que des informations claires sur les données transmises et auquel fournisseur AI. La préoccupation de l'équipe était de créer un écran de consentement qui passe la revue sans nuire à la conversion.

    Résolution

    En cours.

    Leçon

    Si votre application envoie du contenu utilisateur à un service AI externe, demandez le consentement avant la première demande et nommez le fournisseur et les données impliquées. Créez cet écran avant la soumission, et non après le refus.

26. 

    Contrôle familial (numéro de ligne non clairement indiqué) iOS Meta-données et IAP

    Cinq refus pour une case non cochée

    Ce qui s'est passé

    Un développeur expédiant une application de style temps d'écran a été rejeté cinq fois. Les notes de revue vagues ont conduit à penser que le design lui-même était le problème. La cause réelle était une seule case non cochée Contrôle familial dans leur configuration de développeur. Une fois qu'ils l'ont cochée, l'application a été approuvée.

    Résolution

    Approuvé après avoir activé la case Contrôle familial et avoir resoumis l'application.

    Leçon

    Lorsque les notes de rejet restent vagues, vérifiez les autorisations et les certificats avant de redessiner le produit. Les applications de temps d'écran et de contrôle familial nécessitent la capacité correspondante activée dans le portail des développeurs, et non seulement dans Xcode.

27. 

    Règle 5.1.1(v) iOS Règle 5.1.1 Exigence de connexion

    Un compte requis pour un fonctionnalité payante exécutée sur appareil

    Ce qui s'est passé

    Un développeur venant des applications web a été rejeté en vertu de la règle 5.1.1(v). Sur le web, ils ont toujours lié les achats à un compte. Sur iOS, Apple possède l'achat, donc les acheteurs peuvent payer sans s'inscrire. Leur niveau payant déverrouillé sur appareil filtres qui ne fonctionnaient que sur le téléphone, mais à la fois le déverrouillage de ce niveau et la restauration des achats ont toujours obligé la création d'un compte avant.

    Résolution

    Reconstruction pour que les achats effectués sans compte trouvent leur propriétaire après inscription facultative. En cours au moment de la publication.

    Leçon

    Si une fonctionnalité payante fonctionne sur l'appareil et n'a pas besoin d'une identité de serveur, laissez les gens acheter et restaurer sans compte. Gardez l'inscription uniquement pour les fonctionnalités qui en ont vraiment besoin, comme le sauvegarde cloud.

28. 

    Règle 1.4.2 Injure corporelle iOS Règle 1.4.2

    Live dosage calculator apps pulled in a rule crackdown

    Ce qui s'est passé

    Un développeur s'est réveillé pour trouver deux de ses applications signalées en vertu de la règle 1.4.2, même si ni l'une ni l'autre n'avait rien en revue. Les deux étaient déjà en ligne : un calculateur de dose de peptides autonome et un suiveur avec le même calculateur intégré, qui ensemble avaient constitué leur premier véritable succès en termes de revenus. D'autres développeurs dans le même domaine ont signalé le même avis au même moment. Il disait que les applications qui calculent les doses de médicaments, y compris les doses de peptides et de reconstitution, doivent être publiées par le fabricant de médicaments ou une institution reconnue comme un hôpital, une assurance, une pharmacie ou une université.

    Résolution

    Aucune. Le développeur a dit qu'il comprenait la préoccupation de sécurité et qu'il l'a traitée comme la fin de ces applications.

    Leçon

    L'approbation n'est pas permanente. Apple peut réévaluer une application en ligne lorsqu'elle resserre une règle. Si votre application calcule des doses ou donne des conseils de santé qui pourraient nuire à quelqu'un, lisez la règle 1.4 avant de construire, et prévoyez de publier par une institution qualifiée ou laissez tomber la calculatrice.

29. 

    Règles 4.3 Spam et 4.2.6 Services de génération d'applications iOS Ligne directrice 4.3 Règle 4.2.6

    An offline ticketing app called spam, again

    Ce qui s'est passé

    Un développeur a créé une petite application qui transforme un tableur en un système de billetterie et de check-in qui fonctionne entièrement hors ligne, sans compte et sans abonnement. Elle avait déjà géré l'entrée à un événement local avec plusieurs centaines d'assistsants pendant l'été. Apple l'a rejetée à nouveau avec un avis combiné 4.3 et 4.2.6, disant qu'elle pourrait dupliquer des applications déjà disponibles sur le magasin, être une variante opportuniste d'une catégorie surpeuplée, ou provenir d'un modèl’ou d'un service de génération d'applications. Le développeur a dit qu'il n'en connaissait pas d'autre qui faisait la même chose, et que la version Android avait été en ligne pendant environ une semaine.

    Résolution

    Rejeté encore à la date de publication. Le développeur a dit qu'il ne cherchait pas à gagner d'argent avec l'App Store de toute façon.

    Leçon

    Un examinateur de la règle 4.3 voit votre liste et quelques minutes de l'application, pas vos utilisateurs réels. Si l'application est vraiment différente, dites exactement comment dans les notes de revue et les premières captures d'écran, mentionnez l'utilisation dans le monde réel, et dites clairement que vous n'avez pas utilisé un modèl’ou un générateur d'applications.

30. 

    Norme 5.6.4 Qualité de l'application Programme d'Apple Developer Norme 5.6.4

    Payouts frozen over a rising refund rate

    Qu'est-ce qui s'est passé

    Un développeur exécutant une application de souscription en croissance rapide a reçu un avertissement d'Apple indiquant que son compte développeur violait la charte du développeur Code en vertu de la norme 5.6.4, Qualité de l'application. Le message a fait référence à des demandes de remboursement excessives et à des plaintes de clients, a averti que le compte pourrait être résilié et a indiqué que tous les paiements d'earnings étaient suspendus et que les transferts d'applications étaient désactivés. Le taux de remboursement avait environ doublé au cours des deux derniers mois. Lorsque le développeur a plongé dans les données, la plupart des demandes de remboursement étaient étiquetées comme achats non intentionnels, qu'il croyait provenir principalement de personnes oubliant de supprimer un essai gratuit de 3 jours qui s'est transformé en un plan annuel. L'avertissement est tombé pendant que la grande refonte de l'application était déjà en cours de test.

    Résolution

    Encore ouverte au moment de la publication. Le développeur a ajouté plus de rappels pendant le test, a rendu l'avenir de la charge plus évident, a ajouté un moyen de gérer et d'annuler l'abonnement à l'intérieur de l'application, a terminé la refonte avec plus de tests et a suspendu tous les marketing payants des créateurs pendant l'attente.

    Leçon

    Apple examine les taux de remboursement et les plaintes, et non seulement votre version binaire. Une période d'essai gratuite qui se convertit discrètement en une facture annuelle peut se transformer en un problème d'achat non intentionnel à grande échelle. Rappellez aux gens avant la fin de la période d'essai, montrez le prix réel clairement, faites facilement annuler et considérez une augmentation du taux de remboursement comme un risque pour le compte bien avant que Apple ne le fasse.

31. 

    Metadata and in app purchase setup iOS Métadonnées et IAP

    Rejeté trois fois en raison d'une image que le console ne pouvait pas supprimer

    Ce qui s'est passé

    Un développeur a ajouté une image promotionnelle à une souscription dans App Store Connect et s'est accidentellement retrouvé avec la même image ajoutée deux fois. Après cela, l'image ne pouvait pas être supprimée ou remplacée, et chaque tentative a échoué avec une erreur générique leur demandant de réessayer plus tard. L'application a été rejetée trois fois en raison de cette configuration de souscription. Chaque fois, le développeur a répondu avec une capture d'écran de l'essai de suppression et de l'erreur, et chaque fois cela a semblé que le réviseur l'ignorait. Le développeur pensait que la cause racine était un bug dans App Store Connect lui-même.

    Résolution

    Encore bloqué au moment de la publication, sans correction de la part d'Apple.

    Leçon

    When App Store Connect bloque la correction, une réponse dans le fil de rejet peut ne pas atteindre qui peut la résoudre. Téléchargez les images de souscription avec soin et n'envoyez-les qu'une seule fois, et si le console se brise, contactez séparément le support du développeur Apple pour signaler le bug tout en répondant à la revue d'App.

32. 

    Règle 4.3 Spam iOS Ligne directrice 4.3

    Trois refus pour une application conçue pour une salle de sport.

    Ce qui s'est passé

    Un développeur a créé une application iOS pour gérer son propre gymnase, environ 176 commits de travail. Apple l'a rejetée le 29 septembre, la rejeta à nouveau le 7 octobre et le 13 octobre, sous la règle 4.3 Spam. La même journée, ils ont répondu à toutes les neuf questions que leur a envoyées la revue d'App. Six jours plus tard, le 19 octobre, ils n'avaient encore rien reçu. La liste de leurs applications App Store Connect montrait plusieurs autres applications sur le même compte qui se trouvaient également en état de rejet à la même époque, sur les deux iOS et macOS.

    Résolution

    Encore ouverte au moment de la publication, sans réponse de la revue d'App après les réponses envoyées.

    Leçon

    Efforts et comptes de commit ne sont pas ce que mesure 4.3. Si une application est vraiment conçue pour une entreprise, une application non listée peut rester hors de la recherche tout en restant accessible à tout le monde avec son lien direct ; La distribution d'application personnalisée restreint la disponibilité aux organisations spécifiées. Choisissez l'option qui correspond au contrôle d'accès requis. Pour une liste publique, faites ce qui est différent des applications existantes évident dans les premières écrans, captures d'écran et notes de révision.

33. 

    Règles 5.6 Développeur Code du Code de Conduite et 2.5.19 Fonctionnalités Cachées iOS Règle 5.6 du Développeur Code de la Conduite La ligne directrice 2.5.19 Fonctionnalités cachées

    Rejeté comme fraude pour les commutateurs de test restants

    Ce qui s'est passé

    In September 2026 a developer had an iOS app rejected under guideline 5.6 Developer Code of Conduct. Apple said it had found a pattern of behavior it associates with fraud, specifically features that looked like they had been deliberately hidden during review. The developer traced it to three testing switches they had left in the release build: a mode for taking store screenshots, a switch that simulated a slow entitlement check, and a switch that unlocked mock purchases. None of them could be reached by normal users of the App Store version. In Apple's October 16 App Review Guidelines update, hidden, dormant, or undocumented features became their own guideline, 2.5.19, and Apple says breaking it can put the whole developer account at risk.

    Résolution

    Le développeur inspecte maintenant les chaînes de caractères à l'intérieur de chaque archive de version avant de les télécharger.

    Leçon

    Conservez les code de test uniquement dans les builds de compilation, par exemple avec les drapeaux DEBUG, plutôt que derrière un contrôle de temps d'exécution. Vérifiez ce qui est réellement expédié dans le fichier binaire archivé, et notez tout commutateur qui reste dans les notes de revue de l'App Store.

34. 

    2.1 Informations nécessaires iOS Directive 2.1

    Review paused until Apple knew who the app was for

    Qu'est-ce qui s'est passé

    A un développeur a soumis la version 1.0 d'une application iPad et la revue s'est arrêtée sous la ligne directrice 2.1, Informations nécessaires. Il n'y avait pas de rapport de crash, aucune fonctionnalité cassée et aucune mise à jour binaire demandée. Apple ne voulait qu'une réponse détaillée à une seule question avant que la revue puisse continuer : qui utiliserait cette application ?

    Résolution

    Apple a demandé une explication du public cible avant de poursuivre la revue.

    Leçon

    Traitez l'audience et le cas d'utilisation comme des entrées de revue, et non comme du contenu marketing que vous pouvez remplir plus tard. Écrivez une réponse claire à l'utilisateur cible avant de soumettre une première version.

35. 

    4.3 Conception / Spam iOS Ligne directrice 4.3

    Non différent suffisamment dans une catégorie d'applications sonores saturée

    Ce qui s'est passé

    Une application de sons d'entertainment a été rejetée en vertu de la directive 4.3(b). Apple a déclaré que l'App Store avait déjà suffisamment d'applications similaires et a traité le produit comme un contenu dupliqué dans une catégorie saturée, même où l'équipe croyait que des fonctionnalités supplémentaires le distinguaient.

    Résolution

    Rejeté en vertu de 4.3(b) pour une différenciation insuffisante dans une catégorie encombrée.

    Leçon

    En catégories que Apple appelle saturées, la novauté doit être évidente dans la première minute de revue. Commencez par ce qui est unique, et non par un gimmick que les réviseurs ont vu de nombreuses fois.

36. 

    L'histoire de refus de l'app store iOS Métadonnées et IAP Évaluation interminable

    The metadata loop that ate launch week

    Qu'est-ce qui s'est passé

    Une équipe de productivité pour les consommateurs a expédié une version de build propre, puis a passé plus de neuf jours à passer par des objections de métadonnées. Chaque réenvoi répondait à la note précédente, mais la réponse suivante se concentrait sur une autre phrase, capture d'écran ou explication. Aucun code n'a changé pendant que les plans de lancement, de presse et d'acquisition payante attendaient la copie de revue.

    Résolution

    Apruvé après reprise des captures d'écran, des sous-titres et des notes de revue sans changement binaire.

    Leçon

    Verrouillez la copie de liste, les captures d'écran et les notes de revue en une seule passe avant d'attacher une date de lancement. Les rejets de métadonnées peuvent s'accumuler même lorsque le binaire ne bouge pas.

37. 

    Conformité à l'exportation (App Store Connect) iOS Métadonnées et IAP

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

    Qu'est-ce qui s'est passé

    Un accompagnement de tableau de bord B2B a obtenu l'approbation, mais la mise en production est restée bloquée lorsque le prompt de conformité est réapparu après que l'équipe a cru que les questions d'exportation étaient déjà répondues. Le propriétaire de la mise en production a arrêté le lancement, rassemblé les termes juridiques, mis à jour la réponse App Store Connect et attendu une autre passe de revue pendant que les clients voyaient l'annonce avant que l'application ne soit disponible.

    Résolution

    Sorti après avoir répondu à nouveau à la conformité d'exportation et avoir attendu la prochaine passe de revue.

    Leçon

    Treat export compliance as a release gate, not a one time checkbox. Confirm App Store Connect shows a releasable state before you announce a ship date.

38. 

    Revues des autorisations Google Play et des politiques Google Play Métadonnées et IAP Révision sans fin

    Le temps perdu en politique de permission

    Ce qui s'est passé

    Une application Android de gestion opérationnelle a déclenché une revue de politique large après l'utilisation d'une permission étroite sur une seule écran. L'équipe a documenté la fonctionnalité, ajouté des instructions pour les réviseurs, enregistré un chemin de démonstration et a tout de même dû supprimer la permission de la version principale de libération pour libérer les clients après treize jours.

    Résolution

    Approuvé après avoir supprimé la permission, enregistré une nouvelle démonstration et réécrit la déclaration de magasin.

    Leçon

    Restreignez les permissions sensibles au plus petit espace que vous pouvez déployer en premier. Une seule permission peut déclencher une revue complète de politique sur Google Play.

39. 

    File d'attente de la file d'attente de Google Play Google Play Révision sans fin

    The hotfix that waited behind a policy queue

    Ce qui s'est passé

    Un équipe de commerce en ligne avait besoin d'une solution mobile rapide pour un bug de paiement, mais la mise à jour du magasin était en revue pendant six jours au pire moment possible. Les tickets de support grimpaient tandis que le statut restait en attente. Ils ont d'abord atténué le côté serveur, puis ont regardé l'approbation binaire arriver après que l'urgence avait déjà brûlé un week-end.

    Résolution

    La mise à jour native du magasin est arrivée après que l'équipe avait déjà atténué l'incident ailleurs.

    Leçon

    La revue de magasin n'est pas un canal de réponse aux incidents. Gardez un chemin de mitigation hors magasin pour les bugs de production urgents pendant que le binaire attend dans la file d'attente.

40. 

    Lignes directrices 3.1.1 Achat en ligne et 3.1.3(f) Applications autonomes gratuites iOS Ligne directrice 3.1.1 Règle 3.1.3

    Une application de compagnie rejetée car son essai expire

    Ce qui s'est passé

    Un développeur a expédié une application iOS gratuite pour leur service web payant d'email. L'application n'offrait rien à l'intérieur. Ils ont fait référence à l'exception 3.1.3(f) pour les applications de compagnie gratuites, mais l'application a été rejetée quatre fois. Ils ont fait appel, et le conseil de la revue a confirmé le rejet. Sa raison était que le service offrait un essai gratuit de 14 jours, donc pour un utilisateur iOS, l'application cesserait d'être utile après 14 jours et n'était pas une expérience réelle en stand-alone. Apple a proposé deux façons de sortir : donner à l'application suffisamment de contenu et de fonctionnalités gratuites pour se tenir debout, ou permettre aux clients de l'App Store d'acheter le service avec une mise à jour en application. Le développeur a fait remarquer que l'application d'email bien connue semblait faire la même chose avec une limite de 14 jours.

    Résolution

    Encore non résolu au moment de la publication. L'appel a été perdu, et le développeur pesait un niveau minimal gratuit contre l'ajout d'une mise à jour en application.

    Leçon

    L'exception 3.1.3(f) de la compagnie est lue étroitement. Si votre service web a un essai limité dans le temps, Apple peut considérer l'application comme un mur payant déguisé une fois l'essai expiré. Avant de soumettre, décidez ce que quelqu'un peut toujours faire dans l'application gratuitement après l'essai, ou prévoyez une mise à jour en application. Faire référence à d'autres applications qui semblent faire la même chose rarement gagne un appel.

Ceci n'est pas un conseil juridique et ne prédit pas ce que Apple fera à votre prochaine soumission.