Délai de validation App Store : combien de temps dure la review d’Apple en 2026 ?

La plupart des reviews App Store se terminent en 24 à 48 heures. La page App Review d’Apple indique qu’au moins 50 % des soumissions sont en général examinées en moins de 24 heures, et 90 % en moins de 48 heures. Les données de Runway, mises à jour le 29 octobre 2026, donnaient en moyenne 14 heures 53 minutes en Waiting for Review puis 49 minutes en In Review, soit environ 15 heures 42 minutes au total.

C’est le cas courant, pas une garantie. La file s’allonge quand Apple ouvre les soumissions pour un nouveau système en septembre, autour des fêtes de fin d’année, et pour toute app qui doit fournir des documents, utilise un entitlement sensible ou arrive pour la première fois sur le store. Ces jours-là, une review peut durer plusieurs jours, et quelques développeurs rapportent des attentes de deux semaines ou plus. Apple publie des objectifs et un total annuel de reviews, mais pas la longueur de la file en temps réel. Tous les chiffres en direct de cette page viennent donc d’un tiers qui mesure de vraies soumissions.

Le délai de validation App Store se compose de trois chronomètres qui tournent l’un après l’autre. D’abord le traitement du build après l’envoi. Ensuite l’attente en Waiting for Review, jusqu’à ce qu’un examinateur prenne la soumission. Puis la phase In Review, pendant laquelle quelqu’un teste l’app. Après l’acceptation vient une quatrième étape plus courte, la publication, qui peut être immédiate, retenue par vous ou programmée. Chaque section ci-dessous traite une de ces étapes, avec les mots d’Apple pour chaque statut et ce que vous avez le droit de faire pendant l’attente.

En français, on cherche tout cela de plusieurs façons : délai de validation App Store, temps de review App Store, combien de temps pour publier une app sur l’App Store, app en attente de vérification. Apple elle-même parle de « vérification » dans ses textes en français, par exemple sur la fiche française de l’app App Store Connect, qui évoque l’envoi de contenus « pour vérification » et l’équipe de vérification des apps. Les noms de statuts de cette page sont ceux de l’aide d’Apple, qui n’existe qu’en anglais : nous les laissons en anglais plutôt que de deviner leur libellé dans l’interface française. Tous renvoient au même processus, mené par l’équipe App Review selon les App Review Guidelines. Cette page ne parle pas des avis clients et des notes, qui forment un système à part traité dans notre guide pour obtenir des avis sur l’App Store.

Une première soumission prend souvent plus de temps qu’une mise à jour, parce qu’il y a plus à vérifier : le concept, le modèle économique, les parcours de compte, les réponses sur la confidentialité et chaque écran. Apple ne publie pas de chiffre propre aux nouvelles apps. Son aide sur le statut de review donne la règle générale, la plupart des soumissions examinées en 48 heures et certaines qui demandent plus de temps, et cite trois cas : les apps avec peu ou pas d’historique auprès de l’App Review, ce qui décrit toute nouvelle app ; les apps pour lesquelles l’App Review doit confirmer des documents comme des licences, des autorisations ou des accords de partenariat ; et les apps qui touchent à un contenu réglementé, à de nouvelles capacités de la plateforme, à des entitlements ou à d’autres fonctions sensibles.

En pratique, comptez deux à cinq jours pour une première sortie dans une semaine normale, et une semaine ou plus en septembre ou fin décembre. Ces fourchettes sont notre estimation de planning, construite à partir des objectifs d’Apple, des données de suivi ci-dessus et des témoignages rassemblés plus bas, pas un chiffre d’Apple. Les apps de santé, de finance, de crédit, de cryptomonnaie, de jeux d’argent et des autres domaines réglementés doivent viser le haut de la fourchette, car elles ont presque toujours des documents à fournir.

L’essentiel du retard sur une première app peut s’éviter. La page d’Apple sur les informations pour une review complète demande une description du concept et du modèle économique, de l’objectif et du public visé, des appareils et versions du système testés, de chaque service extérieur dont l’app dépend, un compte de démo qui fonctionne au moment de la review, et des éventuelles différences selon les régions. Elle dit sans détour que les soumissions incomplètes seront rejetées, et que tout fournir dès le départ rend la review plus rapide et plus prévisible. Sur une première soumission, un rejet coûte bien plus de temps que la file elle-même.

Un nouveau compte développeur passe aussi par l’inscription à l’Apple Developer Program avant de pouvoir soumettre quoi que ce soit, une étape distincte de l’App Review et non comprise dans ces délais. Notre guide du compte développeur Apple détaille cette inscription et son prix. Une fois le compte actif, le chronomètre de la review démarre quand vous cliquez sur Submit for Review. Si vous préparez tout le lancement, la checklist de lancement d’une application mobile place la fenêtre de review dans les huit semaines qui précèdent le jour J.

Les mises à jour sont en général les soumissions les plus rapides de la file. L’aide d’Apple sur le statut de review indique que les mises à jour avec des changements mineurs et des corrections de bugs passent en général vite, alors que d’autres soumissions peuvent demander plus de temps de vérification. Pour une app installée qui livre une mise à jour de routine, une acceptation le jour même est courante, et la moyenne de fin octobre 2026, environ 16 heures entre la soumission et la décision, est une attente raisonnable.

Une mise à jour ralentit quand elle change quelque chose que l’App Review doit regarder de près : une nouvelle méthode de connexion, de nouveaux achats intégrés ou abonnements, un nouvel entitlement, une nouvelle collecte de données, ou du contenu dans un domaine réglementé. La règle 2.3.1(a) des guidelines demande que chaque nouvelle fonction et chaque changement du produit soient décrits précisément dans le champ Notes for Review, et précise que les descriptions génériques seront rejetées. Une note claire qui dit ce qui a changé et où l’examinateur peut le trouver reste le moyen le moins coûteux de faire avancer une mise à jour.

Depuis le 29 octobre 2025, Apple permet d’envoyer des éléments à l’App Review séparément d’une soumission déjà dans la file. Vous pouvez soumettre une version qui corrige un bug critique alors que des pages produit personnalisées sont encore en review, ou envoyer des In App Events à part pendant qu’une version est examinée. Un élément marketing bloqué n’empêche donc plus une correction urgente de passer. Si vous vous demandez à quel rythme publier, notre étude sur la fréquence des mises à jour d’apps donne des repères.

Quand une mise à jour est rejetée pour un motif sans enjeu juridique ni de sécurité, Apple peut proposer une Bug Fix Submission : la mise à jour est acceptée tout de suite et vous corrigez le problème dans la version suivante. La page d’Apple sur les Bug Fix Submissions précise que l’offre apparaît en haut du message de rejet, qu’elle ne concerne que les apps déjà acceptées, et qu’un problème reporté une fois ne peut pas l’être de nouveau à la soumission suivante. Pour accepter, vous répondez au message au lieu de soumettre à nouveau, car une nouvelle soumission relance une review.

La review bêta TestFlight est une review plus légère, qui s’applique dès que vous testez avec des testeurs externes. La présentation de TestFlight par Apple indique que le premier build ajouté à un groupe externe est envoyé à l’App Review, que cette review n’est obligatoire que pour le premier build, et que les builds suivants peuvent ne pas demander de review complète. Les testeurs internes, jusqu’à 100 membres de votre équipe App Store Connect, peuvent tester sans cette étape. Les testeurs externes peuvent être jusqu’à 10 000, et chaque build reste testable 90 jours au plus.

Côté délai, Runway affichait en moyenne 11 heures 11 minutes d’attente avant la review bêta et 1 heure 3 minutes de review bêta dans les données du 29 octobre 2026, soit environ 12 heures 14 minutes au total, avec un traitement du build de 2 heures 26 minutes en moyenne. Dans ce relevé, la review bêta était un peu plus rapide que l’App Review complète, mais le 6 octobre c’était l’inverse : ne comptez pas sur l’une plus que sur l’autre. Si une bêta publique compte pour votre lancement, ajoutez tôt le premier build externe pour que la review soit faite avant d’en avoir besoin.

Un build TestFlight rejeté ne touche pas votre app en ligne. La page des statuts d’Apple précise que pour TestFlight, il faut soumettre un nouveau build à la review avant de pouvoir inviter à nouveau des testeurs externes. Corrigez donc le problème dans un nouveau build plutôt que d’attendre sur celui qui a été rejeté. Si votre build TestFlight reste bloqué en attente de vérification, il attend l’App Review comme une soumission App Store, avec les délais propres à la bêta donnés plus haut.

Oui. L’aide d’Apple sur l’examen accéléré indique que l’App Review travaille jour et nuit, et le tableau par jour plus haut montre des moyennes du samedi et du dimanche dans la même fourchette que le reste de la semaine : 9 heures 23 minutes d’attente le samedi et 13 heures 48 minutes le dimanche dans les données de Runway. Soumettre un vendredi soir ne veut pas dire attendre jusqu’au lundi.

Les fêtes, c’est autre chose. Pour la saison 2022, Apple a continué d’accepter les soumissions, et 9to5Mac a rapporté la note d’Apple prévenant que les reviews pourraient prendre un peu plus de temps du 23 au 27 décembre. Pour 2024, la note d’Apple du 2 décembre 2024 annonçait de nouveau des soumissions ouvertes pendant toute la saison, demandait d’envoyer tôt les soumissions urgentes et prévenait que les reviews pourraient être plus longues du 20 au 26 décembre. C’est la dernière note datée de ce type au 4 novembre 2026. Une éventuelle note pour la saison en cours paraîtra sur la page des actualités développeurs d’Apple : consultez-la avant de prévoir une sortie pendant la dernière semaine de décembre.

Deux autres périodes se comportent comme des fêtes. Les jours qui suivent l’ouverture des soumissions pour un nouveau système, chaque septembre, apportent une vague de mises à jour, même si dans les données actuelles du suivi septembre 2026 affichait une attente moyenne plus courte qu’août. Et les semaines qui suivent une grosse mise à jour des App Review Guidelines, comme celle du 16 octobre 2026, peuvent amener plus de questions des examinateurs le temps que les équipes s’adaptent. Ni l’une ni l’autre n’est annoncée comme un ralentissement, prévoyez donc pour les deux.

Waiting for Review, le statut que l’on cherche souvent sous les mots « en attente de vérification », veut dire qu’Apple a reçu votre soumission et que personne ne l’a encore ouverte. Un ou deux jours d’attente, c’est normal. Au-delà de trois jours, quelques vérifications valent la peine, car certains retards viennent de la soumission elle-même et non de la file.

Apple liste les raisons d’une review plus longue sur son aide sur le statut de review. La première, sur cette page telle que nous l’avons lue en novembre 2026, est l’historique limité : les apps avec peu ou pas d’historique auprès de l’App Review demandent plus de temps. Vient ensuite la documentation : si l’App Review doit demander et vérifier des autorisations, des licences ou des accords de partenariat, le chronomètre s’arrête jusqu’à leur réception. Puis la complexité : contenu réglementé, nouvelles capacités de la plateforme, entitlements activés ou autres fonctions sensibles font l’objet d’un examen plus poussé. Enfin l’enquête : l’App Review examine les comportements signalés ou repérés qui sortent du Developer Code of Conduct, comme une identité de développeur trompeuse, une manipulation de l’App Store ou des apps de faible qualité visées par de nombreux signalements de clients, et Apple précise qu’une enquête peut allonger la review d’une soumission.

Le volume est la dernière raison, et celle sur laquelle vous avez le moins de prise. Apple a examiné 9 100 620 soumissions en 2025, selon son rapport de transparence 2025. Cela fait environ 175 000 par semaine, soit à peu près 24 900 par jour (notre division). Début avril 2026, Apple a contesté auprès de The Information tout allongement des délais : selon Apple, l’équipe traite 90 % des soumissions en 48 heures, la review dure 1,5 jour en moyenne, et plus de 200 000 soumissions sont arrivées chaque semaine pendant les douze semaines précédentes, des propos repris par 9to5Mac le 6 avril 2026. Les témoignages rassemblés par Michael Tsai racontent autre chose. En mai 2026, Paulo Andrade y écrit que le Mac App Store demande régulièrement cinq jours ou plus. En août, Marco Arment estime que la plupart des reviews prennent désormais six jours ou plus, alors qu’il en fallait d’ordinaire un à trois depuis dix ans. En septembre, Craig Hockenberry raconte une app macOS restée des jours en review alors que sa version iOS avait été acceptée le jour même.

Il existe aussi une raison facile à manquer : la review attend peut-être déjà votre réponse. Un message de l’App Review qui demande une information met tout en pause jusqu’à ce que vous répondiez, et il n’arrive pas toujours sous la forme d’un mail bien visible. Ouvrez la section App Review d’App Store Connect et cherchez les messages avant de conclure que la file est en cause.

Un examen accéléré demande à Apple de regarder une soumission avant la file normale. L’aide d’Apple sur l’examen accéléré précise que ces demandes doivent être réservées aux vraies urgences et cite deux cas : corriger un bug critique, et sortir à temps pour un événement auquel l’app est directement liée. Une date de lancement que vous avez choisie vous-même, une campagne marketing ou une démo devant des investisseurs ne comptent pas.

La démarche est courte. D’abord, soumettez l’app à la review dans App Store Connect, car seules les soumissions déjà envoyées à l’App Review peuvent être accélérées. Vérifiez que la soumission est complète, avec le champ Notes rempli et un compte ou un mode de démo pour tout ce qui demande une connexion. Ensuite, ouvrez le formulaire Request an Expedited App Review dans les pages Contact Us d’Apple, choisissez l’app et la plateforme, puis envoyez. Enfin, attendez : l’App Review évalue la demande et accélère la review selon la disponibilité et la demande.

Ce qu’il faut écrire dépend du motif. Pour un bug critique, Apple demande de l’indiquer dans le champ Notes d’App Store Connect au moment de soumettre. Pour un événement, indiquez dans ce même champ l’événement, sa date et le lien entre votre app et cet événement, et programmez si possible la sortie à l’avance dans App Store Connect. Notre conseil : une bonne demande se lit comme un rapport de bug ou une fiche d’événement, pas comme une supplique. Ce qui est cassé ou ce qui a lieu, qui est touché, et la date qui compte.

Combien de temps dure un examen accéléré ? Apple ne le dit pas, et ne garantit pas que la demande soit acceptée. Dans ses engagements britanniques auprès de la CMA, Apple promet de maintenir un mécanisme d’examen accéléré pour les situations urgentes, en citant les correctifs de bugs critiques et les apps liées à un événement comme une compétition de jeu vidéo ou une expérience diffusée en direct, et de publier chaque année le nombre d’examens accélérés pour les développeurs basés au Royaume-Uni, selon les points 5(c) et 9 de son document d’engagements. Apple ne publie aucune limite au nombre de demandes, mais en faire une demande rare la garde crédible.

Plus que la file, la plupart du temps. Apple a rejeté 2 093 244 des 9 100 620 soumissions examinées en 2025, soit un taux de rejet de 23,0 % selon notre division des chiffres du rapport de transparence 2025. À peu près une soumission sur quatre revient au moins une fois. Chaque rejet, c’est lire le message, corriger, puis attendre de nouveau : pour une app rejetée une fois, le vrai délai de validation fait souvent deux ou trois fois le temps de file.

Le temps perdu dépend de ce que vous faites ensuite. Si l’App Review a seulement besoin d’une information, vous répondez au message et la review continue sans nouveau build. Si le problème vient des métadonnées ou de votre serveur, vous corrigez et vous répondez, là encore sans soumettre à nouveau. Si le problème est dans le build, vous envoyez un nouveau build et soumettez cette version, et la review repart de zéro. Apple est précise sur ce point : ne soumettez pas à nouveau avant d’avoir réglé chaque problème relevé, car soumettre avec des problèmes non résolus retarde la review et aboutit au même résultat.

La plupart des rejets finissent par une acceptation. Le même rapport compte 387 087 soumissions acceptées après un rejet en 2025, soit 18,5 % des soumissions rejetées selon notre calcul. Si vous contestez la décision, vous pouvez d’abord répondre, puis faire appel auprès de l’App Review Board ; Apple précise qu’une nouvelle soumission clôt l’appel. La liste complète des motifs de rejet, avec les chiffres d’Apple pour chaque section des guidelines et la façon de corriger chacun, se trouve dans notre guide des motifs de rejet App Store.

En partie. Tant que la soumission est en Waiting for Review, l’aide d’Apple sur le statut de review indique que vous pouvez encore modifier certaines informations ou retirer des éléments de la soumission, mais pas envoyer ni modifier les captures d’écran et les aperçus vidéo. Un texte comme la description ou le texte promotionnel peut en général être changé ; une nouvelle série de captures oblige à retirer la soumission. Si vous préparez de nouveaux visuels, notre guide des tailles de captures d’écran App Store et celui de la vidéo d’aperçu App Store vous évitent un deuxième passage.

Pendant la phase In Review, vous pouvez annuler la soumission pour la retirer de la review. La version passe alors en Developer Rejected, et vous soumettez à nouveau le même build ou un nouveau quand vous êtes prêt. La review repart de zéro : n’annulez que si vous avez trouvé un vrai problème, comme un crash reproductible ou un mauvais build. Changer de build pour ajouter une petite modification vaut rarement la place perdue.

On demande souvent si l’on peut soumettre une autre version pendant qu’une première attend. Une seule version de l’app peut être en review à la fois, mais d’autres éléments comme les In App Events, les pages produit personnalisées ou les fonctions Game Center peuvent désormais partir séparément, et une version qui corrige un bug critique peut être soumise à part des pages produit encore en review.

Acceptation et publication sont deux étapes distinctes, que vous contrôlez. La page d’Apple sur les options de publication propose trois choix pour chaque version : la publier vous-même, la publier automatiquement dès son acceptation, ou la publier automatiquement après l’App Review mais pas avant une date et une heure que vous fixez. La troisième option est celle à choisir quand la date de lancement est fixe : soumettez tôt, laissez la review se terminer quand elle se termine, et la version sort à votre date.

Si vous publiez à la main, la version reste en Pending Developer Release jusqu’à ce que vous cliquiez, et Apple envoie un rappel par mail si elle y reste plus de 30 jours. Apple précise aussi qu’après une publication manuelle, la version peut mettre jusqu’à 24 heures à apparaître sur l’App Store. En pratique c’est souvent plus rapide, mais une fenêtre de 24 heures est le chiffre honnête pour planifier, surtout avec des fuseaux horaires différents.

Pour les mises à jour, vous pouvez aussi publier par étapes sur 7 jours. Le calendrier d’Apple envoie la mise à jour à 1 % des utilisateurs qui ont activé les mises à jour automatiques le premier jour, puis 2 %, 5 %, 10 %, 20 %, 50 % et 100 % le septième jour, et vous laisse mettre en pause jusqu’à 30 jours au total. Pendant le déploiement, n’importe qui peut toujours télécharger la mise à jour à la main depuis l’App Store. Une publication par étapes ne change pas le délai de validation, mais elle limite les dégâts si quelque chose a échappé à la review et aux tests.

Le rapport de transparence 2025 d’Apple est le meilleur décompte public de la file. Il recense 9 100 620 soumissions d’apps examinées et 2 093 244 rejetées en 2025. Ramené au temps, cela donne environ 175 000 reviews par semaine, 24 900 par jour et plus de 1 000 par heure, à toute heure de l’année. La page App Store d’Apple indique que chaque semaine, près de 500 spécialistes à travers le monde évaluent plus de 130 000 apps, soit environ 260 apps par examinateur et par semaine si les deux chiffres décrivent le même travail. Les deux chiffres hebdomadaires ne concordent pas et Apple n’explique pas l’écart : prenez-les comme des ordres de grandeur plutôt que des décomptes exacts.

Le volume a grandi plus vite que ne le laissent penser les objectifs publiés. Les chiffres que nous suivons sur notre page de statistiques App Store montrent des soumissions examinées passées d’environ 6,1 millions en 2022 à 9,1 millions en 2025, une hausse de 49,1 %. Les témoignages rassemblés par Michael Tsai relient en partie la hausse de 2026 aux apps construites vite avec des outils de code par IA, et citent des données Appfigures selon lesquelles les soumissions sur l’App Store ont augmenté de 24 % en 2025 jusqu’à novembre. Apple n’a confirmé aucune cause.

Le discours d’Apple a lui aussi bougé. Sa note pour les fêtes 2022, rapportée par 9to5Mac, disait que 90 % des soumissions étaient examinées en moins de 24 heures. Sa page App Review actuelle parle d’au moins 50 % en moins de 24 heures et de 90 % en moins de 48 heures. Pour les développeurs britanniques, ses engagements de mars 2026 reviennent à la promesse plus forte d’une décision pour 90 % des soumissions en 24 heures, et y ajoutent un rapport annuel sur la part des reviews terminées en 24 heures et en 4 jours. Le premier de ces rapports couvre l’année 2026 et doit paraître au plus tard le 31 mars 2027.

Apple ne publie pas de délai de review par pays, et rien dans ses pages d’aide n’indique que la file soit découpée par région. Ce qui change, c’est la promesse. Au Royaume-Uni, les engagements d’Apple auprès de la Competition and Markets Authority, datés du 30 mars 2026 et en vigueur depuis le 1er avril 2026, disent qu’Apple cherchera à rendre une décision de rejet ou d’acceptation pour 90 % des soumissions d’apps en 24 heures, donnera des nouvelles du statut sur demande raisonnable, expliquera chaque rejet au regard des guidelines et ouvrira de plein droit un appel devant l’App Review Board.

Le même document engage Apple à publier chaque année des indicateurs pour les développeurs basés au Royaume-Uni : soumissions examinées, rejets, acceptations après rejet, appels, part des reviews terminées en 24 heures et en 4 jours, nombre d’examens accélérés et part des appels traités en 60 jours. Quand le premier rapport paraîtra en 2027, ce seront les premières données officielles de délai de review publiées par Apple pour un marché, quel qu’il soit.

Pour les développeurs de l’UE et des États-Unis, les objectifs généraux d’Apple cités plus haut restent les seuls chiffres publiés. Le rapport britannique sera tout de même utile partout, parce qu’Apple fait tourner une seule équipe App Review selon un seul jeu de guidelines, et qu’une année lente dans les chiffres britanniques a peu de chances d’être une année rapide ailleurs. Ce dernier point est notre déduction, Apple ne le dit pas.

Google donne une fourchette plus large qu’Apple. Son aide Play Console sur la publication gérée indique que le traitement peut prendre quelques heures ou jusqu’à sept jours, voire plus dans des cas exceptionnels, que le délai se compte à partir de la dernière modification envoyée, et conseille de laisser au moins une semaine entre l’envoi et la mise en ligne. Son aide sur la publication ajoute que certains comptes développeur et certaines apps passent une review plus poussée, ce qui peut signifier des délais de sept jours ou plus.

Les nouveaux comptes développeur personnels ont une étape de plus avant leur première sortie en production. La page de Google sur les exigences de test indique que les comptes personnels créés après le 13 novembre 2023 doivent mener un test fermé avec au moins 12 testeurs inscrits pendant au moins 14 jours, puis demander l’accès à la production, dont la review prend en général sept jours ou moins selon Google. Pour un premier lancement Android depuis un nouveau compte personnel, cela fait trois semaines ou plus avant la mise en ligne, en plus de la review normale.

Google Play a aussi son équivalent de la publication programmée. Avec la publication gérée activée, les modifications acceptées attendent que vous choisissiez de les publier : vous pouvez envoyer une mise à jour tôt en review et la sortir à votre date, comme avec l’option de publication programmée d’Apple. Google bloque la lecture automatique de ses pages d’aide : les faits Google Play de cette page sont repris tels que les a relevés notre version anglaise de l’article, mise à jour le 2 novembre 2026.

Voyez la review comme une fenêtre, pas comme un instant. Le plan le plus sûr pour un lancement daté consiste à avoir le build accepté avant la date et publié par programmation. Dans App Store Connect, cela veut dire choisir la publication automatique après l’App Review mais pas avant votre date et votre heure de lancement, puis soumettre assez tôt pour que la review se termine même dans une mauvaise semaine, pas seulement dans une bonne.

Comptez à rebours depuis le lancement. Dans une semaine normale, trois jours ouvrés de marge couvrent la file habituelle plus une question rapide de l’App Review. Pour une première sortie, une sortie en septembre ou fin décembre, prévoyez une à deux semaines, de quoi absorber un rejet et un deuxième passage. Placez la review bêta TestFlight encore plus tôt, puisque le premier build externe d’une version passe par sa propre review.

Alignez au même moment tout ce qui dépend de la date de sortie. Apple demande au moins deux semaines de préavis pour les demandes de mise en avant, et notre guide pour être mis en avant sur l’App Store explique pourquoi trois semaines sont un minimum plus sûr. Les notes de version, les posts sur les réseaux sociaux et la presse du jour J s’écrivent plus facilement pendant que le build attend dans la file, et nos exemples d’annonces de lancement d’app donnent de quoi partir. Nos exemples de notes de version et nos exemples d’annonces de mise à jour montrent quoi dire une fois la version en ligne. S’il n’y a pas encore de plan pour les posts, commencez par notre guide pour promouvoir une app sur les réseaux sociaux.

Si la date est vraiment imposée par quelque chose qui vous dépasse, comme un événement sportif, une première ou une diffusion en direct dont l’app fait partie, c’est exactement le cas prévu pour l’examen accéléré d’Apple. Soumettez un build complet, indiquez l’événement et sa date dans le champ Notes, programmez la publication, puis envoyez la demande d’examen accéléré.

Beaucoup de recherches sur la « review App Store » parlent en fait de l’autre sorte de review : un avis écrit par un client qui n’est pas encore visible. Apple ne publie aucun délai pour cela. Les notes et les avis passent par les contrôles d’Apple avant de s’afficher, et le communiqué d’Apple de mai 2026 sur la fraude indique qu’en 2025 Apple a passé en revue plus de 1,3 milliard de notes et d’avis et en a identifié près de 195 millions comme frauduleux, dont elle a empêché la publication.

Si des avis sur votre app semblent manquer, les raisons habituelles sont qu’ils ont été publiés sur le store d’un autre pays, que la note a été laissée sans texte, ou que les contrôles d’Apple contre la fraude les ont retenus. Notre guide pour obtenir des avis sur l’App Store explique pourquoi des avis n’apparaissent pas, comment demander des notes dans le respect des règles d’Apple et comment y répondre.

Quand une version passe la review, l’étape que la plupart des équipes sautent, c’est de la faire savoir. Spreadcast consulte chaque jour votre fiche App Store publique, repère la nouvelle version dès sa mise en ligne et en fait un post illustré avec votre icône et vos captures d’écran dans un cadre d’iPhone, avec une légende écrite pour chaque réseau. Il publie sur Instagram, Facebook, LinkedIn, Pinterest et vos autres comptes connectés selon le calendrier que vous avez fixé.

Vous validez d’un geste, ou vous le laissez publier tout seul. Le même passage quotidien transforme aussi un nouvel avis 5 étoiles ou un cap de notes en post : la mise à jour qui a mis une semaine à passer l’App Review ne sort pas dans le silence. Collez le lien App Store de votre app sur la page de démarrage pour voir le premier post préparé à partir de votre fiche, et consultez les offres pour la publication automatique. Pour un post de lancement ponctuel, le générateur de posts de lancement fait la même chose à partir d’un lien.