App Review Guidelines d'octobre 2026 : ce que changent 1.2, 2.3.14, 2.5.19 et 3.1.1(a) pour votre app

Les changements d'octobre 2026 des App Review Guidelines ont été annoncés dans le billet d'Apple Updated App Review Guidelines are now available du 16 octobre 2026. Deux guidelines sont nouvelles (2.3.14 et 2.5.19), trois passages ont été reformulés (1.2, 3.1.1(a) et section 5), et les sections Before You Submit et After You Submit renvoient désormais vers davantage de documentation. Voici chaque changement expliqué clairement, qui doit agir, et une checklist pour votre prochaine soumission.

Qu'est-ce qui a changé dans les App Review Guidelines le 16 octobre 2026 ?

Apple a ajouté la guideline 2.3.14 pour les ressources créatives et la guideline 2.5.19 pour les fonctionnalités cachées. Elle a aussi clarifié la 1.2 (contenu généré par les utilisateurs), la 3.1.1(a) (liens d'achat externes) et la section 5 (Legal). Le journal des modifications d'Apple les présente ainsi :

Apple indique que les traductions « seront disponibles sur le site Apple Developer d'ici un mois ». En octobre 2026, consultez les App Review Guidelines en anglais dès qu'une version traduite diverge.

Qu'exige la nouvelle guideline 2.5.19 sur les fonctionnalités cachées ?

La guideline 2.5.19 exige que chaque fonctionnalité de votre binaire soit visible et documentée, à la fois pour les utilisateurs et pour l'App Review. Masquer des fonctionnalités, y compris par obfuscation, peut entraîner le retrait de l'app et la résiliation du compte développeur.

Le texte exact (traduit) : « N'incluez aucune fonctionnalité cachée, dormante ou non documentée dans votre app ; les fonctionnalités de votre app doivent être claires pour les utilisateurs finaux et pour l'App Review. Tenter de dissimuler des fonctionnalités non documentées dans le binaire de votre app, par exemple via l'obfuscation de code ou d'autres méthodes, constitue un motif de retrait de votre app de l'App Store et de résiliation de votre compte développeur. » Apple présente cette règle comme une politique de longue date, mais elle figurait auparavant dans la 2.3.1. L'actuelle 2.3.1(a) exige toujours que les nouvelles fonctionnalités soient « décrites de manière précise dans la section Notes for Review ». Les refus pour fonctionnalités cachées devraient désormais citer la 2.5.19.

Concrètement, listez dans vos notes de review chaque fonctionnalité qu'un interrupteur côté serveur, un code d'invitation, un scan de QR code, une région ou un niveau de compte peut activer. Si un flag doit activer une fonctionnalité après validation, activez-la dans le build soumis à la review, ou retirez le code jusqu'à la version qui la livre réellement.

Quelles apps sont concernées par les changements de la guideline 1.2 ?

La guideline 1.2 couvre désormais toute app qui permet aux utilisateurs de « créer, générer, importer, partager ou contribuer de toute autre manière à du contenu », et cite les réseaux sociaux, les plateformes d'UGC et les apps de création de contenu par IA. Ces apps doivent filtrer les contenus répréhensibles, proposer un signalement avec des réponses rapides, permettre de bloquer les utilisateurs abusifs et publier des coordonnées de contact.

Le texte révisé mentionne les « images intimes non consenties » aux côtés de la violation de propriété intellectuelle et du harcèlement. Il ajoute : « Les développeurs qui ne mettent pas en place des garde-fous appropriés ou ne corrigent pas les violations identifiées après notification peuvent être considérés comme en infraction avec le Developer Code of Conduct. » Une app d'images ou d'avatars IA qui génère du contenu uniquement pour l'utilisateur peut donc désormais être concernée. Le filtrage des prompts et des résultats, le signalement et les coordonnées publiées doivent figurer dans le build que vous soumettez, pas dans une roadmap.

Que dit la guideline 2.3.14 sur les ressources créatives ?

La guideline 2.3.14 stipule que les ressources créatives doivent être liées au contenu, aux fonctionnalités ou à la marque de votre app, respecter les règles habituelles sur les métadonnées et convenir à tous les publics. Elle interdit les contenus inappropriés, les références trompeuses à d'autres apps, les affirmations invérifiables et les « informations de prix précises ou remisées ».

Les ressources créatives sont les éléments image et vidéo introduits par Apple le 5 octobre 2026. Selon les App Store asset best practices d'Apple, ils apparaissent « dans iOS 27 et iPadOS 27 et versions ultérieures, y compris sur votre page produit, dans les résultats de recherche et lorsque votre app est mise en avant ». Cette page va plus loin que la guideline. Elle recommande d'exclure les URL de sites web, les symboles de copyright, les logos d'autres plateformes et les distinctions Apple comme « Editor's Choice ». Elle précise aussi que les ressources « doivent respecter une classification 4+, même si celle de votre app est plus élevée ». Un en-tête affichant « -50 % cette semaine » ou « appli budget n° 1 » enfreint la 2.3.14.

Qu'est-ce qui a changé dans la guideline 3.1.1(a) sur les liens d'achat externes ?

La guideline 3.1.1(a) ne comporte plus de point distinct pour le Music Streaming Services Entitlement. Cet entitlement est désormais intégré au point StoreKit External Purchase Link Entitlements, et le texte précise que les liens peuvent mener à « une destination autorisée ». Les destinations approuvées peuvent varier selon la région.

Les règles sur l'endroit où les liens sont autorisés n'ont pas changé avec cette mise à jour. Les entitlements restent limités à certains storefronts. Le storefront des États-Unis reste l'exception où les boutons, liens externes et autres incitations à l'action sont autorisés sans entitlement. Si vous utilisez déjà l'un de ces entitlements, vérifiez que votre lien mène toujours à une destination autorisée dans chaque storefront où vous distribuez votre app.

Comment les développeurs corrigent-ils concrètement les refus pour fonctionnalités cachées et UGC ?

Les cas rapportés publiquement montrent que les refus sous l'ancienne formulation de la 2.3.1 sur les fonctionnalités cachées et sous la 1.2 se résolvaient généralement en rendant chaque fonctionnalité et chaque garde-fou faciles à trouver pour le reviewer, ou par un appel. Les modifications de code seules suffisaient rarement.

• En mars 2026, un développeur a signalé sur les Apple Developer Forums qu'une app native de réveil social avait été refusée au titre de « Guideline 2.3.1(a) - Hidden Features » et de la 4.2. Selon lui, les WebViews servaient uniquement à la politique de confidentialité, aux conditions d'utilisation et à la FAQ, et il a fait appel. L'App Review a répondu que l'App Review Board avait rendu sa réponse. Le développeur a ensuite demandé quels écrans précis étaient en cause, et aucune solution n'a été publiée.
• Dans une issue GitHub de Flutter, plusieurs développeurs ont reçu le message « We discovered that your app contains hidden features » pour des apps simples. Un contributeur Flutter a qualifié le framework de « fausse piste » et a pointé des API non documentées dans le code de l'app ou dans des plugins. Deux développeurs ont indiqué avoir été validés après appel, sans modifier leur code.
• Un développeur sur les Apple Developer Forums a été refusé au titre de la 1.2 alors qu'il disposait d'un CLUF, de filtrage, de signalement et de blocage. On lui a demandé de faire accepter des conditions prévoyant une « tolérance zéro envers les contenus répréhensibles » et de « traiter les signalements de contenus répréhensibles sous 24 heures ». Un second refus a ajouté une classification 18+, la suppression instantanée des publications et des coordonnées de contact dans l'app. Il a répondu en documentant chaque garde-fou et en fournissant des identifiants administrateur dans les notes de review.

À retenir : dans les trois cas, les reviewers ne pouvaient ni voir ni vérifier des fonctionnalités que les développeurs jugeaient évidentes. Avec la 2.5.19 et une 1.2 plus stricte, les notes de review et le compte de démo comptent autant que le code. Notre guide sur le compte de démo pour la review App Store explique comment les mettre en place.

Que vérifier avant votre prochaine soumission ?

Avant votre prochain build, confrontez vos feature flags, vos garde-fous UGC, vos ressources créatives et vos liens externes au nouveau texte, puis rédigez des notes de review qui renvoient vers chacun d'eux. La checklist ci-dessous couvre les changements d'octobre 2026.

1. Listez chaque flag contrôlé par le serveur, chaque clé de configuration distante et chaque menu caché. Activez-les tous pour le reviewer, ou supprimez le code qu'ils contrôlent.
2. Décrivez précisément chaque nouvelle fonctionnalité dans Notes for Review, comme l'exige la 2.3.1(a), y compris comment accéder à tout ce qui se trouve derrière des invitations, des scans ou des offres payantes.
3. Si les utilisateurs peuvent publier, discuter ou générer du contenu, vérifiez que le filtrage, le signalement, le blocage et les coordonnées publiées sont tous présents dans le build, et documentez votre processus de traitement des signalements.
4. Pour la génération d'images ou de vidéos par IA, ajoutez des filtres sur les prompts et les résultats qui bloquent les images sexuelles de personnes réelles, et offrez aux utilisateurs un moyen de signaler les résultats.
5. Vérifiez dans chaque ressource créative l'absence de prix, de remises, d'URL, de revendications de récompenses, de logos d'autres plateformes et de tout contenu au-delà d'une classification 4+.
6. Si vous utilisez un entitlement de lien d'achat externe ou de streaming musical, vérifiez que le lien mène à une destination autorisée dans chaque storefront.
7. Relisez les guidelines en anglais pour toute section sur laquelle vous vous appuyez, car les traductions peuvent avoir jusqu'à un mois de retard.

Exemple concret : prenons une app d'avatars IA avec une galerie publique et un pack de styles « Pro » activé par configuration distante après le lancement. Avec le nouveau texte, elle doit modérer la galerie et proposer le signalement (1.2). Le pack Pro doit soit être visible dans le build soumis, soit être retenu jusqu'à une version ultérieure (2.5.19). Sa ressource d'en-tête iOS 27 ne peut pas afficher « Pro à -40 % » (2.3.14). Si vous faites déjà face à un refus, notre guide de correction guideline par guideline explique comment répondre dans App Store Connect. Pour un regard extérieur avant de soumettre, consultez nos services.