App Review en 48 h : ce qui est vrai, ce qui est exagéré, ce qui est faux

Les esprits s'échauffent en ce moment chez les développeurs iOS, sur X comme dans les communautés WhatsApp, dont une que j'anime. On y parle de reviews qui s'éternisent, de comptes résiliés, et on y échange des recettes pour « être validé en moins de 48 h » : review notes détaillées, vidéo de démo, appel avec Apple pour passer dans une file à part, MVP minimaliste pour éviter « la pile des 14 jours »…

Il y a de très bonnes intuitions dans ces conseils. Il y a aussi des affirmations invérifiables, et une ou deux idées qui, mal appliquées, peuvent coûter bien plus qu'un rejet.

Les délais et les résiliations méritent chacun leur chapitre, parce qu'ils éclairent tout le reste.

Pour le contexte (même si, arrivé sur ce site, vous « savez » sans doute qui je suis) : je publie sur l'App Store depuis 2008, pour mes propres apps comme pour des clients. J'ai repris chaque conseil et je l'ai confronté à ce qu'Apple écrit noir sur blanc dans sa page App Review, ses App Review Guidelines et l'aide App Review. Voici ce qui tient, et ce qui ne tient pas.

---

D'abord, remettre les 48 h à leur place

Les recettes qui circulent laissent entendre que 48 h est une performance. Sur le papier, c'est la norme affichée par Apple : l'équipe App Review travaille 24 h/24, tout autour de la planète (Cupertino, Cork et ailleurs), et vise au moins 50 % des soumissions traitées en moins de 24 h, et 90 % en moins de 48 h.

Sur le terrain, c'est plus nuancé. Ces chiffres sont des moyennes calculées sur toutes les soumissions, et une grande partie d'entre elles sont des mises à jour d'apps déjà publiées, qui passent souvent en quelques heures. Ces dernières semaines, j'ai eu des mises à jour validées en 7 h, d'autres en 12 h. Une nouvelle app, elle, peut attendre beaucoup plus longtemps : au moment où j'écris ces lignes, certaines de mes nouvelles apps sont en review depuis plus de dix jours. C'est long, mais c'est le jeu.

Apple a d'ailleurs partagé des chiffres récents. Interrogée par MobileGamer.biz le 20 octobre, l'entreprise indique avoir traité en moyenne 378 000 soumissions par semaine sur les douze dernières semaines, avec un délai moyen de 1,5 jour toutes apps confondues et 14 heures pour les mises à jour mineures. Elle précise aussi que certaines nouvelles apps prennent plus de temps lorsqu'elles demandent un examen approfondi. Pour un tel volume, la moyenne est remarquable ; les écarts se concentrent sur les premières soumissions.

Pour suivre ces délais, la communauté avait autrefois son outil. Les plus anciens se souviennent d'appreviewtimes.com, lancé au début des années 2010 par l'ami Dave Verwer, l'auteur d'iOS Dev Weekly. Le principe était simple : les développeurs tweetaient la durée de leurs reviews avec le hashtag #iosreviewtime (oui, c'était encore Twitter), et le site calculait une moyenne. À l'époque où il fallait compter en semaines, c'était un outil indispensable pour gérer les attentes des clients.

En 2019, Dave a fermé le site pour la meilleure des raisons : les reviews étaient devenues si rapides, de l'ordre d'une journée, que les mesurer n'avait plus beaucoup d'intérêt. Il ne l'a jamais rouvert. Dave a d'ailleurs rejoint Apple cet été avec le Swift Package Index, et c'est Alex Ozun qui a repris iOS Dev Weekly.

Résultat : en 2026, il n'existe plus de baromètre communautaire de référence, seulement des témoignages épars sur les forums et les réseaux. Signe des temps : l'outil qui avait fermé parce que la review était devenue rapide retrouverait aujourd'hui sa place.

Une brève histoire du temps

Ce n'est pas la première fois que les délais bougent. Aux débuts de l'App Store, une review pouvait prendre plusieurs semaines. Ma toute première app a attendu 26 jours avant d'être validée, pour une sortie le 14 juillet 2008, quatre jours après l'ouverture de l'App Store. On est ensuite descendu à une semaine, qui a longtemps été la norme. Puis Apple a fortement accéléré, jusqu'à ce que un à trois jours devienne l'habitude. Depuis le début de 2026, les délais remontent pour les nouvelles apps, et la raison mérite un chapitre à elle seule (juste en dessous).

Viser 48 h, ce n'est donc pas chercher un passe-droit : c'est ne pas sortir du flux normal, en sachant que pour un lancement, le flux normal se compte aujourd'hui en jours. Planifiez en conséquence.

La vraie question devient : qu'est-ce qui fait sortir une soumission de ce flux ? Apple donne un indice précieux sur sa page App Review : plus de 40 % des problèmes non résolus relèvent de la guideline 2.1, App Completeness — crashs, contenu provisoire, informations manquantes. Ce n'est pas la subjectivité du reviewer qui ralentit la majorité des apps. C'est une soumission incomplète.

---

Les agents de code : plus d'apps, plus d'attente

Pourquoi les délais remontent-ils ? L'explication la plus probable tient en un mot : les agents.

Claude Code, Codex, Cursor, les agents intégrés à Xcode : écrire une app iOS n'a jamais été aussi accessible. Selon Sensor Tower, cité par The Information, l'App Store a reçu 235 800 nouvelles apps au premier trimestre 2026, soit 84 % de plus qu'un an plus tôt — la plus forte croissance mesurée depuis quatre ans. Sur l'ensemble du premier semestre, Sensor Tower estime le nombre de nouvelles apps à environ 560 000, le double de l'année précédente, alors que les téléchargements n'ont progressé que de 2 %. Apple elle-même a écrit dans son bilan antifraude de mai que les outils de développement IA font grimper les soumissions.

Apple maintient son objectif de 90 % en 48 h, et a adapté son organisation : davantage d'automatisation et priorité donnée aux mises à jour. Côté développeurs, le constat est cohérent avec ce choix : les mises à jour d'apps établies passent toujours vite, les nouvelles apps attendent davantage.

Le bon côté : what a great time to be a developer

C'est d'abord une excellente nouvelle, à plein de titres. La barrière du code n'a jamais été aussi basse. Des designers, des experts métier, des indies qui n'auraient jamais appris Swift peuvent aujourd'hui sortir une app utile. Des développeurs expérimentés livrent en une semaine ce qui prenait un trimestre. Je travaille moi-même avec des agents au quotidien : ils écrivent du SwiftUI, des tests, et même un premier jet de review notes.

Attention quand même : dire que la barrière a disparu serait un mensonge. Un agent écrit du code ; il ne sait pas à votre place quel framework choisir, quel pattern tiendra quand l'app grossira, comment se comportent la concurrence Swift, StoreKit ou les permissions, ni pourquoi une review bloque. Les agents amplifient ce que vous savez déjà. Plus vous connaissez la plateforme, plus ils vous rendent rapide ; moins vous la connaissez, plus vite vous accumulez des problèmes que vous ne savez pas lire.

Les ingrédients sont les mêmes pour tout le monde : Swift, SwiftUI, Xcode, les Human Interface Guidelines, et désormais un agent. Ce qui fait une grande app, c'est la façon de les assembler, avec intention et avec soin : une raison d'exister formulable en une phrase, une seule source de vérité pour les données, une accessibilité auditée honnêtement, des tests sur de vrais appareils. Un agent peut écrire l'écran ; il ne vous dira pas si l'app mérite d'exister. Ou pire, il se transformera en maman fière de son petit : « C’est une idée fantastique, mon chéri ! » Puis il vous aidera à brûler un milliard de tokens pour construire une app dont le public se résume à vous, votre maman, votre chat, votre canari et peut-être — mais alors, peut-être seulement — votre moitié. J'ai détaillé toute cette démarche, des huit principes de design d'Apple jusqu'à la publication, dans La recette d'une grande app iOS.

Bien utilisés, ils aident aussi à la conformité. Un agent peut relire vos purpose strings, vérifier que la suppression de compte existe, confronter votre parcours aux guidelines, lister les fonctionnalités non évidentes à documenter. Tout ce que décrit cet article, un agent peut le vérifier avant vous.

D'ailleurs, pour vous simplifier la tâche, je vous offre un skill qui vous aidera à débusquer les erreurs avant de soumettre : app-review-skill. Ce n'est pas une garantie d'approbation, mais au moins un garde-fou. 😉

Bref : what a great time to be a developer.

Le mirage du millionnaire en trois prompts

L'autre face de la médaille, c'est le discours qui accompagne cette vague. On voit passer partout la même promesse : trois prompts, un abonnement (ou des pubs partout), et vous voilà millionnaire en trois jours.

Spoiler : c'est faux. Et les chiffres sont sans appel. Le rapport State of Subscription Apps 2026 de RevenueCat, qui porte sur plus de 115 000 apps et 16 milliards de dollars de revenus, montre que :

• un an après son lancement, l'app médiane génère environ 72 $ par mois ;
• seules 17,3 % des apps atteignent 1 000 $ de revenus mensuels dans leurs deux premières années, et 4,6 % franchissent les 10 000 $ ;
• même les 10 % les plus performantes dépassent tout juste 2 574 $ par mois après un an : loin, très loin du million ;
• les apps lancées en 2025 ou après ne pèsent que 3 % des revenus d'abonnement, quand celles lancées avant 2020 en captent 69 %.

Et on parle là d'apps suffisamment sérieuses pour avoir intégré un système d'abonnement.

Tout le monde pense avoir la next big idea. Désolé de vous faire redescendre. Si votre idée n'existe pas encore sur l'App Store, il n'y a que deux possibilités : soit elle a déjà été tentée et ça n'a pas marché, soit une centaine d'autres personnes sont en train de la construire en ce moment même. Et avec les agents, la centaine devient vite un millier.

Ce n'est pas du pessimisme, c'est un phénomène bien documenté : les découvertes simultanées. Alexander Graham Bell et Elisha Gray ont déposé leur demande de brevet pour le téléphone le même jour, en 1876. Darwin et Wallace sont arrivés chacun de leur côté à la sélection naturelle, au point de présenter leurs travaux ensemble en 1858. Newton et Leibniz ont inventé le calcul infinitésimal en parallèle. Rien de magique : à une époque donnée, tout le monde partage les mêmes outils, les mêmes problèmes et le même accès à l'information. Deux esprits face au même problème, avec les mêmes outils, aboutissent naturellement à la même solution. Comme le dit la formule souvent attribuée à Victor Hugo, rien n'est plus puissant qu'une idée dont le temps est venu.

Le conseil qui en découle : ne gardez pas votre idée secrète par peur qu'on vous la vole. D'autres y travaillent déjà. Les personnes à qui vous en parlez peuvent même vous faire découvrir des apps concurrentes passées sous votre radar. La différence ne se fera pas sur l'idée, mais sur l'exécution, la distribution, le temps, et votre touche personnelle.

Je connais des développeurs dont les apps rapportent de 80 000 $ à plus d'un million de dollars par mois. Ils existent, ils sont brillants, et ils ont souvent des années d'itérations derrière eux. Ce n'est clairement pas la majorité.

Ce n'est pas une raison pour ne pas se lancer. C'est une raison de le faire pour de bonnes raisons : résoudre un vrai problème, apprendre, construire quelque chose dans la durée. Et de soigner ce qui, lui, ne s'automatise pas : la qualité.

Le moins bon

Des apps bâclées arrivent en review, et la file est partagée. Générer une app en un week-end ne veut pas dire qu'elle est prête : beaucoup de soumissions arrivent sans avoir été testées sur un appareil, avec du contenu provisoire, sans politique de confidentialité ni review notes. D'autres n'ont aucun intérêt pour qui que ce soit d'autre que leur développeur. Apple le dit pourtant dès l'introduction de ses guidelines : une app qu'on veut seulement montrer à sa famille et à ses amis n'a pas sa place sur l'App Store, Xcode et la distribution Ad Hoc sont faits pour ça. Chacune de ces soumissions occupe un reviewer qui ne s'occupe pas de la vôtre. En donnant la priorité aux mises à jour d'apps existantes, Apple protège les utilisateurs actuels et les développeurs établis ; la contrepartie, c'est une attente plus longue pour les nouvelles apps.

Le spam est la première cible. La guideline 4.3 interdit de soumettre plusieurs variantes d'une même app et les catégories saturées sans réelle différence. Avec un agent, produire cinq clones prend une après-midi ; c'est exactement ce qu'Apple filtre. Apple indique avoir renforcé l'automatisation et la détection d'abus, et ajouté des garde-fous contre les soumissions répétées avec les mêmes problèmes non résolus. Ses guidelines le disaient déjà : un rejet répété pour la même raison rallonge la review.

Les apps qui génèrent du code sont dans le viseur. Apple a bloqué des mises à jour ou retiré plusieurs apps de vibe coding cette année, dont Replit, Vibecode et Anything. Le motif n'est pas le vibe coding en soi, mais la guideline 2.5.2 : une app ne peut pas télécharger ou exécuter du code qui change ses fonctionnalités après la review.

Plus d'apps ne veut pas dire plus d'utilisateurs. Avec des téléchargements quasi stables, chaque nouvelle app se bat pour la même attention. La barrière technique a baissé ; la barrière de la qualité, elle, a monté.

Ce que ça change pour vous

• Vous restez responsable. Les guidelines le rappellent : tout ce qui se trouve dans votre app, SDK tiers compris, est sous votre responsabilité. « C'est l'agent qui l'a écrit » n'est pas un argument recevable.
• La qualité de la soumission devient un avantage. Dans une file engorgée, une app complète avec des notes claires se distingue encore plus qu'avant.
• Une app, pas cinq variantes. Utilisez les achats intégrés ou les réglages pour les déclinaisons plutôt que de multiplier les bundle IDs.
• Ne resoumettez jamais sans corriger. Un aller-retour inutile vous coûte des jours, et peut vous classer parmi les comportements qu'Apple surveille.
• Prévoyez de la marge. Pour une nouvelle app, comptez une semaine, plus un aller-retour éventuel. Si ça passe en 48 h, tant mieux.

---

Les conseils qui tiennent la route

La qualité compte, et elle est écrite dans les règles

« Une app soignée sera mieux traitée » : c'est vrai, mais pas pour une question d'humeur du reviewer. La section 4 des guidelines l'écrit clairement : Apple attend des interfaces simples, raffinées et faciles à utiliser. La guideline 4.2 (Minimum Functionality) rejette les apps qui ne sont qu'un site web reconditionné, une collection de liens ou un contenu sans valeur durable.

« Faites du natif en SwiftUI » : un bon conseil, pas une règle

Je suis développeur iOS natif : je le pratique, je le défends, je le promeus et je l'enseigne. Pour moi, c'est la voie de référence pour construire une app qui respecte les usages de la plateforme et exploite pleinement ce que l'iPhone et l'iPad savent faire. Avec SwiftUI, vous profitez de Dynamic Type, des safe areas, des sheets, de la navigation système et de l'adaptation iPhone/iPad, avec un accès direct aux widgets, Live Activities, App Intents et à bien d'autres possibilités des frameworks Apple. Cette intégration fait une vraie différence au quotidien et réduit mécaniquement les petits défauts qu'un reviewer remarque.

Mais aucune guideline n'impose SwiftUI. Une app Expo, Flutter ou UIKit bien faite passe sans problème. Ce qui est sanctionné, c'est le résultat : une web view déguisée, une interface qui casse sur iPad (la guideline 2.4.1 encourage le support iPad dès que possible), un clavier qui masque un champ. Le natif augmente vos chances d'excellence ; il ne les garantit pas.

P.S. : Martin, pas taper, pas taper, pas taaaaa... slap

Politique de confidentialité, support et permissions

Là, on reste souvent en dessous de la réalité. Ce ne sont pas des bonnes pratiques, ce sont des obligations :

• Une politique de confidentialité accessible dans App Store Connect et dans l'app (5.1.1(i)). Elle doit décrire les données collectées et leurs usages, engager les tiers à un niveau de protection équivalent, et expliquer la conservation, la suppression et le retrait du consentement.
• Un lien de support avec des coordonnées à jour, et tous les liens fonctionnels (2.1 et 5.1).
• Des purpose strings claires pour chaque permission sensible, idéalement avec un exemple concret d'usage.
• La minimisation des données (5.1.1(iii)) : privilégiez les pickers système, comme le sélecteur de photos, plutôt qu'un accès complet à la photothèque.
• La suppression de compte dans l'app dès qu'on peut en créer un (5.1.1(v)).

Le format « HTML statique » souvent conseillé n'a rien d'obligatoire. Ce qui compte, c'est que la page soit accessible, à jour et cohérente avec ce que fait l'app.

Les apps sociales : quatre exigences précises

Signalement, blocage, contact, modération : c'est exactement la guideline 1.2 (User-Generated Content), qui exige :

1. un moyen de filtrer les contenus inacceptables avant publication ;
2. un mécanisme de signalement et une réponse rapide aux signalements ;
3. la possibilité de bloquer les utilisateurs abusifs ;
4. des coordonnées publiées pour vous joindre.

Depuis la mise à jour du 16 octobre 2026, la guideline cite explicitement les apps de création par IA, et Apple précise que les images intimes non consenties, y compris générées par IA, doivent être activement prévenues et retirées. Un développeur qui ne met pas de garde-fous en place, ou ne corrige pas après notification, peut être considéré en violation du code de conduite.

L'API de modération gratuite d'OpenAI revient souvent dans les discussions. C'est une option technique valable, avec une précision importante : la guideline 5.1.2(i) impose de dire clairement quand des données personnelles sont partagées avec des tiers, y compris une IA tierce, et d'obtenir une permission explicite. Envoyer les photos de vos utilisateurs à un modèle externe sans le dire, c'est remplacer un rejet par un autre.

Les achats intégrés doivent fonctionner

Évident, mais souvent raté : la guideline 2.1(b) demande des in-app purchases complets, visibles et fonctionnels pour le reviewer. Si un produit configuré n'est pas accessible dans le build soumis, expliquez pourquoi dans les notes. Et prévoyez un bouton « Restaurer les achats ».

---

Les review notes : le levier le plus sous-estimé

C'est le conseil le plus utile de tous, et Apple va encore plus loin.

Ce qu'Apple demande dans la checklist « Before You Submit » :

• un accès complet à l'app : compte de démo actif ou mode démo complet, plus le matériel ou les ressources nécessaires (identifiants, QR code d'exemple…) ;
• un back-end en ligne pendant toute la review ;
• une explication détaillée des fonctionnalités non évidentes et des achats intégrés dans les notes, avec documentation si besoin.

Oui, il y a une part d'automatisation, et c'est normal à ce volume. Mais Apple l'écrit noir sur blanc dans l'introduction de ses guidelines : chaque app est examinée par des experts. Dans neuf cas sur dix, sinon plus, c'est un humain qui est aux manettes, et qui appuie sur le petit bouton vert (ou rouge).

Vos notes s'adressent donc à une personne, qui découvre votre app en quelques minutes. Écrivez-les pour elle.

Et la guideline 2.3.1(a) est sans ambiguïté : toute nouvelle fonctionnalité doit être décrite avec précision dans les notes, et les descriptions génériques sont rejetées.

Attention à un détail : un mode démo à la place d'un compte de démo n'est accepté qu'avec l'accord préalable d'Apple, et seulement si des obligations légales ou de sécurité vous empêchent de fournir un compte.

Une structure qui marche

Inutile de recopier le roman d'un autre. Voici le squelette que j'utilise :

Bonjour,

[Nom de l'app] est [une phrase : ce que fait l'app, pour qui, et le problème qu'elle résout].
Modèle économique : [gratuit / abonnement / achat unique], via In-App Purchase.

Accès :
- Compte de démo : [identifiant] / [mot de passe]
  (ou : aucun compte requis)

Parcours principal :
1. …
2. …
3. …

Achats intégrés :
- Où apparaît le paywall, comment tester en sandbox.
- « Restaurer les achats » : [emplacement].

Fonctionnalités non évidentes :
- [Fonction] : comment y accéder, ce qu'elle fait.

Données et permissions :
- Quelles permissions, quand elles sont demandées, pourquoi.
- Données partagées avec des tiers (y compris IA) et consentement.

Services externes :
- [Service] : à quoi il sert (données, authentification, paiement, IA, publicité…).

Différences régionales :
- [Aucune / lesquelles].

Réglementation et contenus tiers :
- [Non applicable / documents joints].

Compte et sécurité :
- Suppression de compte : [chemin].
- Signaler / bloquer : [chemin] (si contenu utilisateur).

Pour le style, la règle d'or : des phrases courtes, compréhensibles par quelqu'un qui découvre l'app. Je nuancerais seulement le « n'utilisez pas l'IA » qu'on lit parfois : faire rédiger un premier jet par un agent qui connaît votre code est un gain de temps réel. Ce qui compte, c'est de relire et simplifier avant de soumettre.

Un exemple réel : déclarer ce qui est piloté à distance

Voici une note que j'ai laissée sur l'une de mes apps (anonymisée). Le cas est classique : le SDK publicitaire est intégré, mais les pubs ne peuvent pas être activées avant la publication, car AdMob exige une app publiée sur un store pour valider son « app readiness ». Les pubs sont donc coupées par un feature flag au moment de la review.

ADVERTISING DISCLOSURE - INITIAL 1.0 RELEASE
This app includes the Google Mobile Ads (AdMob) SDK and Google UMP consent integration. Production advertising is currently disabled through a remote feature flag. This is the general launch configuration, not a condition targeting App Review. We are disclosing the advertising integration explicitly; it is not disabled to hide it from reviewers.

The reason is that this initial release is not yet publicly available on the App Store. AdMob requires a published, downloadable app linked to a supported store for its app readiness review, and approval before full ad serving. We therefore cannot complete that activation process before publication. After release, we plan to link the App Store listing, complete AdMob's readiness process and enable production advertising through the feature flag.

The absence of ads during review should not be interpreted as an ad-free product. Ad presentation will remain subject to the applicable consent and tracking permissions.
Google's explanation: https://support.google.com/admob/answer/10564477?hl=en

Pourquoi cette note fonctionne :

• Elle nomme ce qui est dans le binaire : le SDK AdMob et le module de consentement UMP.
• Elle déclare le feature flag et précise qu'il ne cible pas la review. C'est exactement l'inverse d'une fonctionnalité dormante au sens de la guideline 2.5.19.
• Elle explique pourquoi, avec une source externe vérifiable.
• Elle annonce ce qui changera après la publication, pour que l'activation des pubs ne soit pas une surprise.
• Elle rappelle le consentement : les pubs personnalisées resteront soumises aux autorisations de suivi.

Rien de caché, rien à interpréter : le reviewer sait exactement ce qu'il valide.

La vidéo de démo : pas obligatoire, mais de plus en plus demandée

On lit parfois que les premières soumissions sans notes ni vidéo seraient rejetées automatiquement. Rien dans la documentation d'Apple ne le dit. Ce qu'Apple écrit, c'est qu'il faut être prêt à fournir une vidéo de démo ou le matériel lorsque certaines fonctionnalités dépendent d'un environnement difficile à reproduire ou d'un matériel spécifique.

En pratique, une courte capture d'écran commentée, déposée en pièce jointe dans App Review Information, aide beaucoup dès que l'app sort de l'ordinaire : objet connecté, géolocalisation, fonctionnalité sociale qui nécessite plusieurs comptes. Pour une app de notes sans compte, c'est superflu.

L'objectif reste juste : rendre la review évidente. Un reviewer qui comprend votre app en trois minutes n'a aucune raison de vous poser de questions.

Quand Apple vous demande « plus d'informations »

Pour les nouvelles apps, un message revient de plus en plus souvent : une demande d'informations standardisée, rattachée à la guideline 2.1. Voici celle que j'ai reçue récemment pour l'une de mes apps :

We need additional information to better understand the app and complete the review.

Reply in App Store Connect with all of the following information and also add this
information to the Notes field of the App Review Information section in App Store
Connect, for reference on future submissions:

1. A screen recording captured on a physical device, running the latest operating
   system, demonstrating the app's functionality. The recording must begin with
   launching the app and show the typical user flow. If the app has any of the
   following, include them in the recording:
   - Account registration, login, and account deletion flows.
   - Any user-generated content, including the required content reporting and
     blocking mechanisms.
   - Accessing paid content or features within the app.
2. A description of the app's purpose and target audience, including the problem
   it solves and the value it provides
3. Instructions for setting up and accessing the app's main features, including
   any required login credentials or sample files
4. A list of the external services, tools, or platforms the app uses to deliver
   its core functionality (for example, data providers, authentication services,
   payment processors, or AI services)
5. Describe any regional differences in the app's features or content, or confirm
   that the app functions consistently across all regions
6. If the app operates in a highly regulated industry or includes protected
   third-party material, provide any relevant documentation or credentials to
   demonstrate you are authorized to provide these services or protected material

Le message rappelle au passage les pièges classiques : bugs sur appareil physique, compte de démo, captures d'écran qui montrent l'app en usage, achats intégrés configurés avec l'app, distribution réservée aux entreprises.

Et voici ma réponse, anonymisée :

1. [Screen recording attached, captured on a physical device.]

2. [App] is a [category] app that [what the app does]. It's inspired by
   [well-known reference], but adds [its own distinctive features]. It's designed
   for [target audience], and [the problem it solves / the value it provides].

3. There's no account to create and no login required. Users can simply open the
   app and start using it. The main flow consists of [main interaction]. Users
   can also [secondary features] directly from the app. The app includes optional
   rewarded ads to unlock [optional extra].

4. The app runs primarily on the device. [Core processing] is handled locally,
   so there's no external API involved in the core functionality. Google's AdMob
   is used to display advertisements, including optional rewarded ads.

5. The app works the same way in every region where it's available. The main
   difference is the language: the app has a localized name and content adapted
   to each language. Features and core mechanics remain consistent across all
   supported regions.

6. Not applicable. [App] is an original app and doesn't operate in a regulated
   industry.

Trois enseignements :

• La vidéo n'est pas exigée d'office, mais elle est explicitement demandée ici, filmée sur un appareil physique, avec la dernière version d'iOS, depuis le lancement de l'app. Autant la préparer avant la première soumission.
• Apple demande d'ajouter ces réponses dans le champ Notes, pour les soumissions suivantes. Autrement dit : si elles y avaient été dès le départ, l'aller-retour aurait sans doute été évité.
• Les six questions sont une excellente checklist. But, public, accès, services externes, différences régionales, réglementation : je les ai intégrées au modèle de notes plus haut.

---

Ce qu'il ne faut pas faire (et pourquoi c'est parfois pire qu'un rejet)

Les écrans « bientôt disponible »

Contenu provisoire, boutons morts, liens vides : c'est le cœur de la guideline 2.1, et la première cause de problèmes selon Apple. Supprimez la fonctionnalité du build plutôt que de la montrer à moitié.

Modifier le paywall après la review

On voit parfois « rendre un paywall distant non conforme après la review » rangé parmi les simples dark patterns. C'est bien plus grave que ça.

La guideline 2.5.19, ajoutée le 16 octobre 2026 pour viser nommément le bait-and-switch, interdit les fonctionnalités cachées, dormantes ou non documentées, et prévoit le retrait de l'app et la résiliation du compte développeur. L'introduction des guidelines est encore plus directe : tenter de tromper le processus de review mène au retrait des apps et à l'exclusion de l'Apple Developer Program. Ce n'est pas un pari sur la clémence d'un reviewer, c'est un risque pour toute votre activité.

Configurer son paywall à distance n'a rien d'interdit. Le faire basculer vers quelque chose que le reviewer n'a pas vu, si.

Les demandes de note

La guideline 5.6.1 impose l'API fournie par Apple pour demander une note, et interdit les prompts personnalisés. La guideline 3.2.2(x) interdit de conditionner l'accès à une fonctionnalité au fait de noter l'app.

Demander une note pendant l'onboarding n'est pas explicitement interdit, mais c'est absurde : l'utilisateur n'a encore rien vu, et le système limite de toute façon la fréquence d'affichage de cette demande. Attendez un vrai moment de satisfaction.

La fausse preuve sociale et les promesses invérifiables

« 1 million d'utilisateurs » inventé, faux avis, « corrige 100 % de vos problèmes » : la guideline 5.6.3 interdit toute manipulation des avis, des classements ou de la recherche, et la 2.3.7 interdit les affirmations invérifiables dans les métadonnées. Pour les apps de santé, la 1.4.1 exige de documenter la méthodologie derrière toute promesse de précision.

Copier une app

Évident, et Apple va plus loin. La guideline 4.1 rejette les copies, et l'usurpation d'une autre app est une violation du code de conduite. La 4.3 ferme la porte aux catégories saturées (lampes torches, fonds d'écran, apps de rencontre, minuteurs simples…) sauf expérience réellement différente. Il existe déjà un million de boîtes à prout, de lampes torches et d'apps de rencontre : Apple cite d'ailleurs nommément les apps de pets et de rots parmi celles qui n'apportent rien à l'App Store.

Les offres de rétention : passer par les outils officiels

On parle beaucoup de « transaction abandon » et d'« exit offers » (proposer une offre à quelqu'un qui hésite ou veut résilier). Ces pratiques ne sont pas interdites en soi, et StoreKit propose des mécanismes officiels pour cela : offres promotionnelles, offres de reconquête (win-back offers), écran système de gestion des abonnements.

Les garder pour une mise à jour ultérieure est raisonnable : moins de surface, moins de questions. Mais la vraie règle est ailleurs. La guideline 3.1.2(c) exige de décrire clairement ce que l'utilisateur obtient pour le prix, et la 5.6 interdit de pousser à des achats non désirés. Une offre claire, décrite dans les notes, n'a rien à craindre. Une offre qui brouille le prix, si.

---

Les résiliations de comptes : comprendre pour ne pas être concerné

Un rejet coûte quelques jours. Une résiliation coûte toutes vos apps. Le sujet occupe beaucoup les réseaux ces dernières semaines, et il mérite d'être abordé calmement.

Pourquoi Apple serre la vis

Le 16 octobre 2026, Apple a renforcé ses guidelines sur deux points : les images intimes non consenties, y compris générées par IA, que les apps doivent prévenir et retirer (1.2), et le bait-and-switch, ces apps qui se présentent sous un jour anodin pendant la review et activent des fonctionnalités nuisibles après validation (2.5.19). Dans la même annonce, Apple indique avoir empêché plus de 150 000 apps présentant des problèmes de sécurité d'atteindre les utilisateurs l'an dernier, et résilié plus de 193 000 comptes développeurs pour fraude et abus.

Ces chiffres disent l'essentiel : la fraude sur l'App Store est massive et organisée. Les apps de « nudification » se sont multipliées, des autorités comme la ville de San Francisco en ont exigé le retrait, et l'afflux de soumissions générées par IA augmente encore la pression. Que la confiance des utilisateurs dans l'App Store tienne malgré tout, c'est en grande partie grâce à ce travail.

À cette échelle, il arrive aussi que des développeurs de bonne foi se retrouvent pris dans les filets. C'est précisément pour ces cas qu'existe l'appel auprès de l'App Review Board.

Ce que décrivent des développeurs

Les notifications partagées invoquent la section 3.2(f) du Developer Program License Agreement et évoquent un « schéma de comportement manipulateur ou trompeur », suivi d'une liste de comportements possibles : métadonnées inexactes, contenu trompeur, faux avis, réponses trompeuses au support ou dans App Store Connect, achats en bait-and-switch…

Phillip Shoemaker, qui a dirigé l'App Review, a publié fin octobre son analyse. Il estime que l'historique de rejets pèse désormais lourd : nombre de soumissions, changements de nom, rejets répétés pour contenu inacceptable, en particulier pour les apps photo génératives. Il reconnaît aussi la difficulté du côté d'Apple : les apps génératives sont très difficiles à reviewer, une correction côté serveur peut être annulée à tout moment, et Apple relie les comptes entre eux, ce qui lui donne une vision que le développeur n'a pas toujours. Ses propositions sont constructives : des rejets plus précis sur ce qui doit changer, et des éléments concrets dans les notifications pour que l'appel soit utile.

Qui fait le malin tombe dans le ravin

Pas besoin de citer de noms : les histoires qui circulent se ressemblent. Et quand on les lit de près, on retrouve souvent les mêmes réflexes. Ils partent rarement d'une mauvaise intention, mais vus depuis Cupertino, ils ressemblent furieusement à ce qu'Apple cherche à repérer :

• Resoumettre en boucle en changeant un détail à chaque fois, « pour voir si ça passe ».
• Renommer l'app, changer de concept ou de catégorie en cours de route, parfois plusieurs fois.
• Corriger en surface : retirer une option d'un menu pendant que la fonctionnalité reste accessible autrement.
• Garder un interrupteur côté serveur que le reviewer n'a jamais vu.
• Bourrer les mots-clés, ou s'inspirer un peu trop du nom d'une app concurrente.
• Multiplier les comptes, ou prêter le sien, pour contourner un rejet.
• Arranger la vérité dans les réponses à App Review.

Pris isolément, chacun de ces gestes peut sembler anodin. Mis bout à bout, ils dessinent un schéma. Et à l'échelle de centaines de milliers de soumissions par semaine, c'est ce schéma qu'Apple lit, pas vos intentions.

La morale est simple : jouer au plus malin avec l'App Review, c'est parier contre la maison. Et la maison a l'historique complet.

L'App Review Board reste là pour corriger une erreur, et des développeurs de bonne foi y obtiennent gain de cause. Mais le meilleur appel, c'est celui qu'on n'a jamais besoin de faire.

Ce que ça change pour vous

Je ne vais pas jouer les juristes : pour une résiliation, la seule voie est l'appel auprès de l'App Review Board, et dans les cas rapportés la notification ouvre un délai de 30 jours pour le faire. Si ça vous arrive, faites-vous accompagner. En revanche, quelques réflexes réduisent nettement le risque :

• Votre historique de rejets compte. Chaque soumission laisse une trace. Ne resoumettez jamais « pour voir » : posez une question précise dans App Store Connect avant de corriger.
• Ne changez pas l'identité de l'app en cours de route. Nom, concept, catégorie : des changements répétés ressemblent à ce qu'Apple cherche à repérer. Si c'est App Review qui vous le demande, faites-le confirmer par écrit dans App Store Connect, y compris après un appel, et récapitulez par écrit ce qui a été dit au téléphone.
• Quand un rejet tourne en boucle, arrêtez de resoumettre. Demandez par écrit la liste complète des points bloquants, puis passez par l'appel au App Review Board plutôt que d'enchaîner les tentatives.
• Documentez tout ce qui est configurable à distance. Feature flags, paywall, modèles d'IA : dites-le dans les notes, et montrez ce qui peut changer.
• Pour une app générative, corrigez à la source. Retirer une option d'un menu ne suffit pas si le modèle produit toujours le contenu sur simple prompt. Le filtrage doit être réel, côté modèle et côté sortie.
• Répondez avec exactitude dans App Store Connect. Les « réponses trompeuses » figurent explicitement dans la liste des motifs.
• Gardez une archive de chaque soumission. Build, notes, captures, échanges avec App Review : c'est votre seul dossier en cas d'appel.
• Surveillez vos fréquentations. Comptes partagés, certificats prêtés, associés aux pratiques douteuses : Apple relie les comptes entre eux.

C'est aussi pourquoi je ne suis pas l'idée, parfois avancée, qu'« Apple voudrait qu'on cherche la limite ». En 2026, chaque soumission compte dans votre historique. Mieux vaut viser la clarté que la limite.

---

Accélérer une review : ce qui existe vraiment

C'est là que circulent le plus d'idées reçues.

La review accélérée (expedite)

Elle existe, pour des circonstances exceptionnelles : un bug critique ou une sortie liée à un événement auquel vous êtes directement associé. Quelques précisions souvent oubliées :

• seule une soumission déjà envoyée à la review peut être accélérée ;
• pour un bug critique, indiquez dans les notes les étapes pour le reproduire sur la version actuelle ;
• pour un événement, indiquez l'événement, sa date et le lien de l'app avec lui ;
• Apple traite la demande selon la disponibilité et la demande, sans garantie ;
• et surtout, en cas d'abus, Apple se réserve le droit de rejeter vos futures demandes.

« Pas besoin de donner une raison » est donc trompeur : le formulaire est simple, mais la justification doit être dans les notes. Quant au « moment viral » ou au « marketing », ils ne figurent pas dans les critères. Je ne grillerais pas cette cartouche pour ça.

L'appel avec Apple : pas une file rapide

L'appel est souvent présenté comme une méthode méconnue qui ferait passer dans une file à part. Ce n'est pas ce que décrit Apple.

On peut demander un appel avec un représentant Apple depuis la fenêtre de réponse à App Review, après une première réponse de leur part, en précisant son fuseau horaire et sa langue. Ces appels ont généralement lieu sous trois à cinq jours ouvrés. C'est un excellent outil pour débloquer un malentendu sur un rejet. Ce n'est en aucun cas un raccourci vers 48 h. Gardez en tête que la review suivante peut être menée par une autre personne : faites toujours confirmer les conclusions par écrit dans App Store Connect.

Les rendez-vous App Review : le vrai secret

Ce qu'on mentionne rarement, et que je recommande à tous mes clients avant une première soumission délicate : les rendez-vous App Review via Meet with Apple. Trente minutes en visio avec un expert App Review, les mardis et jeudis selon disponibilités, pour poser des questions précises sur la façon dont une guideline s'applique à votre app.

Deux limites à connaître : le rendez-vous est informatif, il ne remplace, n'accélère ni ne garantit la review, et Apple ne pré-approuve aucune fonctionnalité. Mais arriver à la soumission en sachant déjà comment Apple lit votre cas, c'est le meilleur investissement possible.

Sortir de la boucle des rejets successifs

Le cauchemar est bien connu : un rejet, une correction, puis un nouveau rejet pour une autre raison. Pour en sortir, encore faut-il utiliser les bons canaux :

• Répondre dans App Store Connect avec une question précise : la fonctionnalité, la guideline ou l'étape à clarifier. Un spécialiste qui connaît votre app vous répond. Demander « y a-t-il d'autres points bloquants ? » est légitime, même si personne ne peut vous le garantir.
• Le Bug Fix Submission : pour une app déjà publiée, une mise à jour corrective n'est pas bloquée par d'autres problèmes de guidelines, sauf enjeu légal ou de sécurité. Vous corrigez le reste dans la soumission suivante.
• L'appel au App Review Board si vous estimez que l'app a été mal comprise : une seule fois par soumission rejetée, avec des arguments précis.

Et sur le ton, la guideline 5.6 rappelle de traiter tout le monde avec respect, y compris dans les échanges avec Apple. Se plaindre ne sert à rien ; argumenter avec les guidelines, si.

---

Le scope creep : le meilleur conseil, avec une nuance

« Soumettez un MVP » est un excellent conseil, et Apple le confirme à sa manière : une app complexe ou qui soulève des questions nouvelles peut demander un examen plus approfondi, et les rejets répétés pour la même guideline rallongent la review.

En revanche, la description de « deux piles » avec une escalade vers un spécialiste senior et 14 jours d'attente n'est documentée nulle part. Ce qu'Apple documente, ce sont des domaines réglementés qui demandent plus de pièces et de temps :

• les apps de banque, finance, santé, jeux d'argent, crypto ou transport aérien doivent être soumises par l'entité juridique qui fournit le service (5.1.1(ix)) ;
• les jeux d'argent doivent prévoir un délai supplémentaire (5.3) ;
• les apps médicales ou liées à des contenus sous licence doivent fournir les autorisations correspondantes.

Une nuance enfin : un MVP n'est pas une app maigre. Le seuil de la guideline 4.2 s'applique dès la première version. Réduisez le nombre de fonctionnalités, pas leur finition.

---

En résumé : vrai, à nuancer, faux

---

Ma checklist avant soumission

Complétude (2.1)

• Testé sur appareil, dernière version d'iOS, iPhone et iPad
• Aucun contenu provisoire, aucun lien mort
• Back-end en ligne, compte de démo valide
• Achats intégrés visibles, fonctionnels en sandbox, restauration disponible

Informations pour la review

• Notes : ce que fait l'app, parcours principal, fonctionnalités non évidentes, achats
• Coordonnées de contact à jour dans App Review Information
• Vidéo ou documents joints si l'environnement est difficile à reproduire

Confidentialité et sécurité (5.1, 1.2)

• Politique de confidentialité dans App Store Connect et dans l'app
• Purpose strings précises, pickers système quand c'est possible
• Partage avec des tiers (y compris IA) annoncé et consenti
• Suppression de compte dans l'app
• Si contenu utilisateur : filtrage, signalement, blocage, contact

Métadonnées (2.3)

• Captures qui montrent l'app en usage
• Aucune promesse invérifiable, aucune fausse preuve sociale
• Achats payants clairement signalés

Stratégie

• Première version resserrée, offres avancées dans une mise à jour suivante
• Au moins une semaine de marge avant la date de lancement d'une nouvelle app
• Archive de chaque soumission : build, notes, captures, échanges avec App Review
• Rendez-vous App Review pris si une guideline vous fait hésiter

---

Le vrai secret : être ennuyeux et honnête

On lit parfois qu'Apple voudrait qu'on cherche la limite. Je ne suis pas d'accord. Les guidelines sont un document vivant, et Apple assume une part d'appréciation. Mais l'introduction est claire : le principe, c'est une expérience sûre pour les utilisateurs, et toute tentative de tromper la review se paie très cher.

Pour le reste, une règle fait consensus : soyez clair, soyez honnête, expliquez ce que vous faites et montrez-le. Une soumission complète, lisible et sans surprise passe dans les délais normaux. Pour une mise à jour, c'est souvent moins de 48 h. Pour une nouvelle app en 2026, prévoyez plutôt une semaine, et laissez-vous agréablement surprendre.

Avec des agents qui permettent à tout le monde de soumettre une app en un week-end, l'App Review redevient ce qu'elle était au début : un filtre. Et c'est une bonne chose. C'est ce filtre qui permet à un utilisateur d'installer une app inconnue sans se méfier, et c'est cette confiance qui fait la valeur de l'App Store pour nous, développeurs. Les équipes d'App Review traitent des centaines de milliers de soumissions par semaine ; leur faciliter le travail, c'est aussi se faciliter la vie.

Autant être du bon côté du filtre.

---

Je crée et je publie des apps depuis la naissance de l'App Store, pour moi, pour des startups ou pour des maisons qui ont leur boutique sur les Champs-Élysées. Si vous préparez une première soumission délicate, une app sociale, un modèle d'abonnement ou une app dans un domaine réglementé, c'est le genre d'accompagnement que je propose avec BNC Consulting. Écrivez-moi.

Me contacter

Et pour en parler entre développeurs, rejoignez la communauté ⌘+F : les histoires de rejets, on les partage aussi en meetup, autour d'un café ou d'un dîner.

Et pour finir, un gros bisou à Raph’, Anders, Erica, Ewelina et à tous mes autres amis de l’App Review, qui font un travail particulièrement difficile. Un autre à Martin, Mac, SiQing et aux équipes WWDR, qui font souvent tampon — ainsi qu’à toutes les autres personnes que je connais aux quatre coins du monde, mais que je ne peux pas citer ici.

Merci d’être là pour protéger les utilisateurs. C’est ça aussi, le bon côté de l’App Store.

— Clément

---

Sources officielles (consultées le 1er novembre 2026)

• App Review — Apple Developer
• App Review Guidelines (mise à jour du 16 octobre 2026)
• Demander une review accélérée
• Contacter App Review et demander un appel
• Demander un rendez-vous App Review

Données et presse

• MobileGamer.biz — délais de review et afflux d'apps générées par IA (20 octobre 2026, avec la réponse chiffrée d'Apple)
• 9to5Mac — hausse de 84 % des nouvelles apps
• TweakTown — 560 000 nouvelles apps au premier semestre 2026
• RevenueCat — State of Subscription Apps 2026
• iPhoneSoft — AppReviewTimes ferme ses portes (mars 2019)
• Apple — Strengthening App Review Guidelines against nonconsensual intimate imagery and bait-and-switch apps (16 octobre 2026)
• Phillip Shoemaker — Apple approved the fix. Then it called the developer a liar. (30 octobre 2026)
• 9to5Mac — nouvelles règles contre la nudification et le bait-and-switch

---

Comme d'habitude, article rédigé à la main en français. Traductions et illustrations réalisées avec les outils d'OpenAI.