Préparer une app iPhone, iPad ou Apple Watch pour l’App Store.

Sans adhésion active, aucun envoi vers App Store Connect n’est possible. Choisissez le bon statut : une personne ou une organisation. Les apps de domaines réglementés (finance, santé, jeux d’argent, crypto) doivent être publiées par l’entité juridique qui fournit le service, pas par un développeur individuel (5.1.1(ix)).

Vérifier : Ouvrez developer.apple.com → Compte : l’adhésion est active, la date de renouvellement est connue et le nom du vendeur affiché est le bon.

Preuve : Capture de la page Compte avec statut et date d’expiration.

Échec courant : Une app de paiement publiée sous un compte individuel est refusée au titre de 5.1.1(ix).

Apple Developer Program — Enrollment ↗ · revu le 2026-10-23

Vendre une app ou des achats intégrés exige le contrat Paid Apps actif dans App Store Connect, avec les informations fiscales et bancaires. Sans lui, les produits ne sont pas disponibles à la vente.

Vérifier : App Store Connect → Business : le contrat Paid Apps affiche « Active ».

Preuve : Capture de la section Business avec le statut du contrat.

Échec courant : Les achats intégrés restent introuvables pour le testeur et la soumission est refusée au titre de 2.1.

App Store Connect Help — Sign and update agreements ↗ · revu le 2026-10-23

Depuis le 17 février 2025, les apps sans statut de commerçant vérifié sont retirées de l’App Store dans l’UE, et ce statut est exigé pour publier des mises à jour sur les storefronts de l’UE (Digital Services Act).

Vérifier : App Store Connect → Business → Compliance : le statut de commerçant est déclaré et vérifié.

Preuve : Capture du statut DSA vérifié.

Échec courant : L’app disparaît des storefronts européens jusqu’à la vérification.

App Store Connect Help — EU Digital Services Act trader requirements ↗ · revu le 2026-10-23

L’identifiant de bundle est définitif une fois un build envoyé. Le nom de l’app est unique et limité à 30 caractères (2.3.7). Plusieurs identifiants pour la même app sont considérés comme du spam (4.3).

Vérifier : Le bundle ID du projet Xcode correspond exactement à celui de la fiche App Store Connect.

Preuve : Bundle ID et nom de l’app notés dans le projet.

App Review Guidelines 2.3 — Accurate Metadata ↗ · revu le 2026-10-23

App Review doit pouvoir vous contacter, et l’app comme son URL d’assistance doivent offrir un moyen simple de vous joindre (1.5).

Vérifier : Ouvrez l’URL d’assistance depuis un téléphone : un formulaire ou une adresse de contact est visible sans compte.

Preuve : URL d’assistance et capture de la page.

Échec courant : Une URL d’assistance qui mène à une page vide ou à un domaine non configuré.

App Review Guidelines ↗ · revu le 2026-10-23

Au 23 octobre 2026, la page « Upcoming Requirements » d’Apple indique que les apps envoyées doivent être compilées avec Xcode 26 ou plus récent et un SDK 26 (iOS, iPadOS, tvOS, visionOS, watchOS) depuis le 28 avril 2026, et que les apps iOS/iPadOS doivent cibler iOS 13 ou plus récent depuis le 9 septembre 2026. Apple annonce des SDK 27 et une cible minimale iOS 15 à partir d’avril 2027. Vérifiez la page avant chaque envoi : ces valeurs changent chaque année.

Vérifier : Dans Xcode → À propos, notez la version ; dans les réglages du target, notez le SDK et la cible minimale ; comparez avec la page Upcoming Requirements le jour de l’envoi.

Preuve : Version d’Xcode, SDK et cible minimale du build envoyé.

Échec courant : L’envoi est refusé par App Store Connect avant même la revue.

Apple — Upcoming Requirements ↗ · revu le 2026-10-23

Le build est signé pour la distribution App Store (certificat Apple Distribution et profil correspondant). Chaque capability utilisée (notifications push, iCloud, Sign in with Apple, App Groups, achats intégrés…) est activée sur l’App ID, et aucune autre.

Vérifier : Product → Archive puis Distribute App → App Store Connect se termine sans erreur de signature ; comparez les entitlements de l’archive avec les capabilities de l’App ID.

Preuve : Build visible dans App Store Connect avec son numéro.

Échec courant : Notifications push qui fonctionnent en développement mais pas en production, faute d’entitlement de production.

Xcode — Distributing your app for beta testing and releases ↗ · revu le 2026-10-23

Le build soumis pointe vers les services de production, n’expose aucun menu de debug ni bascule d’environnement, et ne journalise ni mot de passe, ni jeton, ni donnée personnelle. Les numéros de version et de build sont incrémentés.

Vérifier : Installez le build TestFlight et vérifiez l’URL du serveur appelée (proxy ou journaux serveur) ; parcourez les réglages à la recherche d’options de debug.

Preuve : Numéro de build et capture des journaux serveur de production pendant le test.

Échec courant : Le testeur d’Apple tombe sur des données de test ou un serveur de staging éteint.

Depuis le 1er mai 2024, les apps nouvelles ou mises à jour doivent déclarer des raisons approuvées pour les API listées par Apple (« required reason APIs »), y compris celles utilisées par les SDK tiers. Beaucoup d’apps en utilisent sans le savoir (UserDefaults, date de fichier…).

Vérifier : Ouvrez PrivacyInfo.xcprivacy dans le projet et dans chaque SDK ; générez le rapport de confidentialité de l’archive (Organizer → Generate Privacy Report).

Preuve : Rapport de confidentialité généré depuis l’archive.

Échec courant : Envoi refusé ou email d’App Store Connect signalant des raisons manquantes.

Apple — Privacy manifest files ↗ · revu le 2026-10-23

Chaque build déclare si l’app utilise du chiffrement non exempté. Le HTTPS fourni par le système est en général exempté ; un chiffrement propriétaire peut exiger de la documentation. Renseigner ITSAppUsesNonExemptEncryption évite la question à chaque build.

Vérifier : Le build n’affiche pas « Missing Compliance » dans App Store Connect.

Preuve : Valeur de ITSAppUsesNonExemptEncryption dans Info.plist ou réponse enregistrée.

Apple — Complying with encryption export regulations ↗ · revu le 2026-10-23

Apple demande des versions finales : textes provisoires, pages vides, « bientôt disponible » et contenus temporaires doivent disparaître avant l’envoi (2.1(a)). Les builds incomplets sont refusés.

Vérifier : Parcourez chaque écran du build TestFlight en cherchant lorem ipsum, « TODO », boutons sans action et écrans vides.

Preuve : Liste des écrans parcourus avec le numéro de build.

Échec courant : Refus au titre de 2.1 pour un onglet « Bientôt disponible ».

App Review Guidelines 2.1 — App Completeness ↗ · revu le 2026-10-23

Apple refuse les builds qui plantent ou présentent des problèmes techniques évidents (2.1). Le simulateur ne remplace pas un appareil : mémoire, réseau, autorisations et performances diffèrent.

Vérifier : Installez le build via TestFlight sur au moins un appareil par famille prise en charge, sur la plus ancienne et la plus récente version d’OS supportées.

Preuve : Liste des appareils et versions d’OS testés (elle sert aussi dans les notes pour App Review).

Échec courant : Plantage au lancement sur l’appareil du testeur, refus 2.1.

App Review Help — Test on compatible devices ↗ · revu le 2026-10-23

Premier lancement, inscription ou connexion, tâche principale, achat et restauration s’il y en a, déconnexion : chaque parcours fonctionne sur le build soumis, y compris avec un compte neuf.

Vérifier : Supprimez l’app, réinstallez le build TestFlight et refaites chaque parcours avec un compte neuf.

Preuve : Courte vidéo ou liste datée des parcours testés.

Échec courant : Le compte de démonstration fonctionne, mais l’inscription d’un nouveau compte échoue.

App Review Guidelines 2.1 — App Completeness ↗ · revu le 2026-10-23

URL d’assistance, de politique de confidentialité, de marketing, conditions et liens internes : Apple attend des URL pleinement fonctionnelles (2.1(a)).

Vérifier : Ouvrez chaque lien depuis l’app et depuis la fiche App Store Connect, sur un réseau mobile.

Preuve : Liste des URL vérifiées avec la date.

Échec courant : Politique de confidentialité en 404 : refus 5.1.1.

App Review Guidelines 2.1 — App Completeness ↗ · revu le 2026-10-23

Un bug bloquant connu finit presque toujours par être trouvé par le testeur ou par les premiers utilisateurs. Résolvez-le ou retirez la fonctionnalité concernée du build.

Vérifier : Filtrez votre outil de suivi sur les défauts critiques ouverts pour cette version.

Preuve : Liste vide ou lien vers les défauts fermés avec leur build de correction.

L’app doit apporter des fonctionnalités, du contenu et une interface qui dépassent un site web reconditionné (4.2) et ne pas dupliquer une app existante ou vos propres apps (4.3).

Vérifier : Listez ce que l’app fait que votre site ne fait pas (fonctions de l’appareil, hors ligne, notifications utiles…).

Preuve : Cette liste, reprise dans les notes pour App Review si l’app ressemble à un site.

Échec courant : Refus 4.2 pour une app qui n’affiche qu’une WebView du site.

App Review Guidelines 4.2 — Minimum Functionality ↗ · revu le 2026-10-23

Les apps n’utilisent que des API publiques, fonctionnent sur l’OS actuellement distribué (2.5.1) et ne téléchargent ni n’exécutent de code qui ajoute ou modifie des fonctionnalités (2.5.2). Les modes d’arrière-plan ne servent qu’à leur usage prévu (2.5.4).

Vérifier : Revoyez les SDK et les modes d’arrière-plan déclarés ; cherchez tout chargement de code distant ou de module à l’exécution.

Preuve : Liste des SDK et modes d’arrière-plan avec leur justification.

App Review Guidelines 2.5 — Software Requirements ↗ · revu le 2026-10-23

Apple recommande que les apps iPhone fonctionnent sur iPad lorsque c’est possible (2.4.1), et les testeurs peuvent les ouvrir sur iPad. Une mise en page cassée y est un motif de refus fréquent.

Vérifier : Ouvrez le build sur un iPad (ou le simulateur iPad) et refaites les parcours critiques, en portrait et en paysage.

Preuve : Captures iPad des écrans principaux.

Échec courant : Boutons hors écran ou clavier qui masque le formulaire sur iPad.

App Review Guidelines ↗ · revu le 2026-10-23

Autonomie de l’app (avec ou sans iPhone), synchronisation, complications et notifications se comportent différemment sur une montre réelle, réseau et batterie compris.

Vérifier : Installez via TestFlight sur une Apple Watch, iPhone éloigné puis à proximité.

Preuve : Modèle de montre, version de watchOS et parcours testés.

App Review Help — Test on compatible devices ↗ · revu le 2026-10-23

Interaction par le regard et les gestes, fenêtres et espaces, confort et lisibilité : testez sur Apple Vision Pro lorsque c’est possible, sinon décrivez précisément les limites de vos tests.

Vérifier : Parcours critiques sur l’appareil ou, à défaut, sur le simulateur visionOS avec des tailles de fenêtre variées.

Preuve : Environnement de test et parcours couverts.

App Review Help — Test on compatible devices ↗ · revu le 2026-10-23

Sur Apple TV, tout passe par le focus et la télécommande : chaque élément actionnable doit être atteignable, et le bouton Retour doit se comporter comme attendu.

Vérifier : Parcourez l’app uniquement avec la télécommande Siri Remote, sans clavier.

Preuve : Parcours testés avec le modèle d’Apple TV.

App Review Help — Test on compatible devices ↗ · revu le 2026-10-23

Libellés VoiceOver sur les boutons, prise en charge des grandes tailles de texte et contrastes suffisants rendent l’app utilisable par plus de monde — et évitent des écrans inutilisables.

Vérifier : Activez VoiceOver et la plus grande taille de texte, puis refaites le parcours principal.

Preuve : Notes du test avec VoiceOver et texte agrandi.

Human Interface Guidelines — Accessibility ↗ · revu le 2026-10-23

Toutes les apps doivent fournir un lien vers leur politique de confidentialité dans les métadonnées et dans l’app, facile d’accès. Elle explique les données collectées, leur usage, le partage avec des tiers, la conservation et la suppression, et comment retirer son consentement (5.1.1(i)).

Vérifier : Trouvez le lien dans l’app en moins de trois touches ; relisez la politique face aux données réellement collectées.

Preuve : URL de la politique et capture de son emplacement dans l’app.

Échec courant : Refus 5.1.1 : politique absente de l’app ou qui ne décrit pas les SDK tiers.

App Review Guidelines 5.1.1 — Data Collection and Storage ↗ · revu le 2026-10-23

Les détails de confidentialité sont obligatoires pour soumettre une app ou une mise à jour. Ils couvrent aussi les pratiques des SDK tiers intégrés (analytics, publicité, crash, paiement).

Vérifier : Comparez chaque donnée déclarée avec ce que l’app et ses SDK envoient réellement (inventaire des SDK, appels réseau).

Preuve : Inventaire des SDK et capture de la section App Privacy.

Échec courant : Étiquette qui déclare « aucune donnée collectée » alors qu’un SDK d’analytics est présent.

Apple — App privacy details on the App Store ↗ · revu le 2026-10-23

Les textes de justification (purpose strings) décrivent clairement et complètement l’usage des données. Ne demandez que ce qui sert la fonction principale, préférez les sélecteurs système (photos, contacts), et ne bloquez pas l’app si la personne refuse (5.1.1(ii)-(iv), 5.1.2).

Vérifier : Réinstallez l’app, refusez chaque autorisation, et vérifiez que l’app reste utilisable et explique ce qui manque.

Preuve : Liste des clés NS…UsageDescription avec leur texte, et résultat du test de refus.

Échec courant : Texte vague (« Nous avons besoin de votre position ») : refus 5.1.1.

Apple — Requesting access to protected resources ↗ · revu le 2026-10-23

Toute captation de l’activité (caméra, micro, écran, saisies) exige un consentement explicite et une indication visuelle ou sonore claire pendant l’enregistrement (2.5.14).

Vérifier : Lancez chaque fonction d’enregistrement : un indicateur est visible tant qu’elle tourne.

Preuve : Capture de l’indicateur pendant l’enregistrement.

App Review Guidelines 2.5 — Software Requirements ↗ · revu le 2026-10-23

Suivre l’activité d’une personne à travers les apps et sites d’autres entreprises exige son autorisation explicite via App Tracking Transparency (5.1.2(i)). Aucune fonction ne peut être conditionnée à cette autorisation.

Vérifier : Refusez le suivi au premier lancement et vérifiez qu’aucun identifiant publicitaire ni événement de suivi ne part (outil réseau).

Preuve : Capture de la demande ATT et journal réseau après refus.

Apple — App Tracking Transparency ↗ · revu le 2026-10-23

Une app qui permet de créer un compte doit permettre de lancer sa suppression dans l’app, avec les données associées — une simple désactivation ne suffit pas (5.1.1(v)). Un lien direct vers une page web qui termine la suppression est accepté. Avec Sign in with Apple, révoquez les jetons via l’API REST.

Vérifier : Créez un compte de test, supprimez-le depuis l’app, puis vérifiez côté serveur que le compte et ses données ont disparu.

Preuve : Chemin dans l’app (capture) et preuve de suppression côté serveur.

Échec courant : Suppression qui exige un email au support : refus 5.1.1(v).

Apple — Offering account deletion in your app ↗ · revu le 2026-10-23

Si l’app n’a pas de fonctions importantes liées à un compte, elle doit être utilisable sans connexion (5.1.1(v)).

Vérifier : Listez ce que le compte apporte ; vérifiez que le reste est accessible sans connexion.

Preuve : Cette liste, résumée dans les notes pour App Review.

App Review Guidelines 5.1.1 — Data Collection and Storage ↗ · revu le 2026-10-23

Une app dont la connexion principale passe par un service tiers ou social doit aussi proposer une option équivalente qui limite la collecte au nom et à l’email, permet de masquer l’email et ne collecte pas d’interactions à des fins publicitaires sans consentement (4.8).

Vérifier : Sur l’écran de connexion, l’option équivalente est présente et fonctionne avec un compte neuf.

Preuve : Capture de l’écran de connexion.

Échec courant : Connexion Google seule : refus 4.8.

App Review Guidelines 4.8 — Login Services ↗ · revu le 2026-10-23

Les apps avec contenu généré par les utilisateurs doivent filtrer les contenus choquants, permettre de signaler un contenu avec une réponse rapide, bloquer les utilisateurs abusifs et publier un moyen de contact (1.2).

Vérifier : Avec deux comptes, publiez un contenu, signalez-le, bloquez l’auteur : chaque action fonctionne et arrive chez vous.

Preuve : Captures des actions Signaler et Bloquer, et procédure de traitement des signalements.

Échec courant : Refus 1.2 faute de mécanisme de signalement.

App Review Guidelines 1.2 — User-Generated Content ↗ · revu le 2026-10-23

Les apps de la catégorie Enfants n’intègrent ni analytics ni publicité tiers, et les liens sortants comme les achats sont placés derrière un contrôle parental (1.3, 5.1.4).

Vérifier : Inventaire des SDK : aucun SDK d’analytics ou de publicité tiers ; chaque lien et achat demande le contrôle parental.

Preuve : Inventaire des SDK et capture du contrôle parental.

App Review Guidelines 1.3 — Kids Category ↗ · revu le 2026-10-23

Santé avec allégations médicales, finance et prêts, crypto, jeux d’argent : l’app est publiée par l’entité qui fournit le service, et les autorisations (licence, homologation, partenariat) sont jointes dans App Review Information, pour chaque pays concerné. Les données de santé suivent des règles propres (5.1.3).

Vérifier : Listez les pays de distribution et le document qui couvre chacun ; vérifiez qu’ils sont joints avant l’envoi.

Preuve : Documents joints dans App Review Information.

Échec courant : Refus 5.1.1(ix) ou demande de documents qui bloque la revue.

App Review Help — Provide information for a complete review ↗ · revu le 2026-10-23

Débloquer des fonctions ou du contenu (abonnements, accès premium, version complète…) passe par l’achat intégré ; clés de licence, QR codes ou autres mécanismes maison sont interdits (3.1.1). Des exceptions existent selon le type d’app et le storefront : vérifiez 3.1.1 à 3.1.3 dans la version actuelle des règles pour vos storefronts.

Vérifier : Listez chaque contenu payant et la façon dont il est débloqué ; chaque cas hors achat intégré cite l’exception qui l’autorise.

Preuve : Cette liste avec la règle applicable.

Échec courant : Bouton « Payer sur notre site » non autorisé pour ce storefront : refus 3.1.1.

App Review Guidelines 3.1 — Payments ↗ · revu le 2026-10-23

Les achats intégrés sont complets, à jour, visibles et fonctionnels pour App Review ; ceux qui ne sont pas trouvables dans l’app sont expliqués dans les notes (2.1(b)). Les nouveaux produits sont soumis avec une version de l’app.

Vérifier : Achetez chaque produit avec un compte sandbox sur le build TestFlight, puis vérifiez l’accès accordé côté serveur.

Preuve : Liste des produits avec statut « Ready to Submit » et résultat de l’achat sandbox.

Échec courant : Produit en « Missing Metadata » : le testeur ne le trouve pas, refus 2.1.

App Review Help — Configure In-App Purchases for review ↗ · revu le 2026-10-23

Les achats restaurables (non consommables, abonnements) doivent pouvoir être restaurés, par exemple sur un nouvel appareil (3.1.1).

Vérifier : Achetez en sandbox, supprimez l’app, réinstallez, restaurez : l’accès revient.

Preuve : Capture du bouton Restaurer et résultat du test.

App Review Guidelines 3.1 — Payments ↗ · revu le 2026-10-23

Avant l’abonnement, l’app décrit clairement ce que la personne obtient pour le prix ; la période dure au moins sept jours et l’abonnement est disponible sur tous ses appareils (3.1.2). Liens vers les conditions et la politique de confidentialité accessibles.

Vérifier : Relisez l’écran d’abonnement comme un inconnu : prix, période, renouvellement et contenu sont lisibles sans faire défiler.

Preuve : Capture de l’écran d’abonnement.

Échec courant : Prix mentionné uniquement en petit sous le bouton : refus 3.1.2.

App Store Connect Help — Offer auto-renewable subscriptions ↗ · revu le 2026-10-23

Pour les abonnements auto-renouvelables, Apple demande un compte de démonstration dont l’abonnement a expiré, afin de pouvoir parcourir tout le parcours d’achat.

Vérifier : Connectez-vous avec ce compte sur le build soumis : l’écran d’abonnement s’affiche.

Preuve : Compte indiqué dans App Review Information (sans le recopier ailleurs).

App Review Help — Provide information for a complete review ↗ · revu le 2026-10-23

Les captures montrent l’app en cours d’utilisation, pas seulement un titre, un écran de connexion ou de démarrage (2.3.3), et restent adaptées à un classement 4+ (2.3.8). Elles respectent les spécifications de taille d’App Store Connect.

Vérifier : Chaque capture correspond à un écran réel du build soumis ; les tailles demandées par App Store Connect sont toutes fournies.

Preuve : Dossier des captures par taille d’appareil.

Échec courant : Captures d’une fonction absente du build : refus 2.3.

App Store Connect Help — Screenshot specifications ↗ · revu le 2026-10-23

Les métadonnées reflètent l’expérience réelle de l’app (2.3). Pas de marques de tiers, de noms d’apps populaires, de prix ou de termes sans rapport dans le nom ou les mots-clés (2.3.7). Les nouvelles fonctions sont décrites dans les notes pour App Review (2.3.1).

Vérifier : Relisez la description phrase par phrase : chaque fonction citée existe dans le build soumis.

Preuve : Texte de la fiche relu, avec la date.

Échec courant : Nom de concurrent dans les mots-clés : refus 2.3.7.

App Review Guidelines 2.3 — Accurate Metadata ↗ · revu le 2026-10-23

Apple utilise un nouveau système de classification (4+, 9+, 13+, 16+, 18+) ; les réponses aux questions mises à jour étaient attendues au 31 janvier 2026 pour ne pas bloquer les mises à jour. Répondez honnêtement, y compris sur le contenu généré par les utilisateurs, la messagerie et la publicité (2.3.6).

Vérifier : App Store Connect → Informations de l’app → Classification par âge : toutes les questions ont une réponse et correspondent à l’app.

Preuve : Capture du questionnaire rempli.

App Store Connect Help — Age ratings values and definitions ↗ · revu le 2026-10-23

Le texte « Nouveautés » et les notes pour App Review décrivent ce qui a changé et où trouver les nouveautés ; les descriptions génériques sont refusées (2.3.1(a)).

Vérifier : Chaque nouveauté citée renvoie à un écran précis du build.

Preuve : Texte des nouveautés et notes pour App Review.

App Review Guidelines 2.3 — Accurate Metadata ↗ · revu le 2026-10-23

TestFlight permet jusqu’à 100 testeurs internes (membres de l’équipe) et jusqu’à 10 000 testeurs externes ; le premier build destiné aux testeurs externes passe une revue. Un build reste testable 90 jours.

Vérifier : Au moins une personne hors du développement installe le build et réalise la tâche principale sans aide.

Preuve : Numéro de build TestFlight et retours des testeurs.

Apple — TestFlight ↗ · revu le 2026-10-23

Le testeur d’Apple peut utiliser un réseau différent du vôtre. Un premier lancement sans données, une connexion lente ou absente et un serveur en erreur doivent afficher un état compréhensible, pas un écran blanc ni un plantage.

Vérifier : Utilisez le Network Link Conditioner ou le mode avion pendant les parcours critiques.

Preuve : Captures des états hors ligne, vide et erreur.

App Review Help — Test on compatible devices ↗ · revu le 2026-10-23

Si l’app a des fonctions liées à un compte, fournissez un compte de démonstration actif (ou un mode démo approuvé par Apple). Les identifiants doivent fonctionner au moment de la revue ; un compte par type de rôle dans les notes ; un code d’authentification à fournir à l’avance. Ne communiquez jamais de vrais comptes clients.

Vérifier : La veille de l’envoi, connectez-vous avec ces identifiants sur le build soumis, depuis un appareil neuf.

Preuve : Case « Sign-in required » cochée et date du dernier test de connexion.

Échec courant : Mot de passe changé ou double authentification non anticipée : refus 2.1.

App Review Help — Provide information for a complete review ↗ · revu le 2026-10-23

Apple demande d’activer les services serveur pour qu’ils soient en ligne pendant la revue, et de lister les services externes dont l’app dépend (authentification, paiement, données, IA).

Vérifier : Pendant toute la période de revue, une surveillance de disponibilité alerte en cas de panne ; aucune maintenance n’est prévue.

Preuve : Historique de disponibilité sur la période de revue.

Échec courant : Serveur de démonstration arrêté pendant le week-end de revue : refus 2.1.

App Review Guidelines 2.1 — App Completeness ↗ · revu le 2026-10-23

Concept et modèle économique (nouvelle app) ou changements (mise à jour), fonctions non évidentes, achats intégrés difficiles à trouver, appareils testés, différences régionales, et vidéo sur appareil physique si un matériel est requis.

Vérifier : Une personne qui ne connaît pas l’app peut, avec ces seules notes, atteindre chaque fonction importante.

Preuve : Texte des notes pour App Review.

App Review Help — Provide information for a complete review ↗ · revu le 2026-10-23

Le build est sélectionné pour la version, toutes les sections obligatoires sont complètes, et aucun refus précédent n’attend de réponse ou de correction dans App Review. Une soumission prête ne garantit pas l’acceptation : la décision appartient à Apple.

Vérifier : App Store Connect n’affiche aucun champ manquant au moment d’ajouter la version à la soumission ; l’historique App Review ne contient aucun message ouvert.

Preuve : Capture de la soumission prête et de l’historique App Review.

Échec courant : Renvoyer le même build après un refus sans traiter le motif cité.

App Store Connect Help — Submit an app ↗ · revu le 2026-10-23

Un refus cite une règle et décrit un problème. Vous pouvez répondre au message, corriger et renvoyer, ou faire appel. Prévoyez qui lit le message, qui corrige et comment la correction est vérifiée.

Vérifier : Le nom de la personne responsable et le délai visé sont notés dans le projet.

Preuve : Procédure notée dans le projet.

App Review Help — Rejections ↗ · revu le 2026-10-23

Une publication manuelle vous laisse vérifier la version acceptée avant sa sortie. Pour une mise à jour, la publication progressive (« phased release ») limite l’exposition si un problème apparaît.

Vérifier : L’option choisie est notée, avec la personne qui déclenche la publication.

Preuve : Option sélectionnée dans App Store Connect.

App Store Connect Help — Release a version update in phases ↗ · revu le 2026-10-23

Une version publiée ne se retire pas comme un déploiement web. Gardez des réglages serveur ou des interrupteurs de fonction pour désactiver une fonction défaillante, et sachez demander une revue accélérée pour un correctif critique.

Vérifier : Identifiez une fonction risquée et vérifiez qu’elle peut être désactivée sans nouvelle version.

Preuve : Liste des interrupteurs disponibles et lien vers la demande de revue accélérée.

App Store Connect Help — Request an expedited app review ↗ · revu le 2026-10-23

Rapports de plantage (Xcode Organizer ou outil tiers), avis, messages au support et métriques d’App Store Connect sont consultés chaque jour pendant la première semaine.

Vérifier : Un rapport de plantage de test remonte jusqu’à l’outil choisi.

Preuve : Outil choisi et personne responsable.