Checklist de soumission App Store (2026) : tout ce qu’Apple vérifie avant de valider votre app

Pour soumettre une app sur l’App Store et la faire accepter en 2026, il vous faut une fiche App Store Connect complète, un build stable avec un manifeste de confidentialité exact, des URL de confidentialité et d’assistance qui mènent à de vraies pages, des conditions d’abonnement claires si vous vendez quelque chose, et des captures aux tailles exigées. La plupart des refus relèvent de quatre règles : 2.1 (plantages et app incomplète), 2.3 (métadonnées inexactes), 4.3 (spam) et 5.1.1 (collecte de données). Voici la checklist que Develak applique avant chaque soumission de ses 34 apps iPhone, iPad et Mac.

Points clés

• Toute app exige une URL de confidentialité et une URL d’assistance avec de vrais moyens de contact (règle 1.5).
• Le manifeste de confidentialité déclare les API « à motif obligatoire » de votre code et de vos SDK ; vos réponses « Confidentialité de l’app » doivent refléter la réalité.
• Si l’on peut créer un compte dans l’app, on doit pouvoir le supprimer depuis l’app (5.1.1(v)).
• Un abonnement exige prix, durée, conditions de renouvellement, liens vers les conditions et la politique de confidentialité, et un bouton « Restaurer les achats ».
• Captures obligatoires : iPhone 6,9 pouces, et iPad 13 pouces si l’app tourne sur iPad.
• Donnez à App Review un accès de démo et répondez au nouveau questionnaire d’âge (4+, 9+, 13+, 16+, 18+).

Avant de commencer : compte, contrats et outils

• Adhésion à l’Apple Developer Program (99 USD par an ou l’équivalent local). Pour publier au nom de votre société, inscrivez-vous en tant qu’organisation, avec un numéro D-U-N-S.
• Contrats, fiscalité et banque à jour dans App Store Connect : sans contrat pour les apps payantes, ni prix ni achat intégré.
• Statut de professionnel dans l’UE. Le règlement sur les services numériques (DSA) impose de déclarer si vous agissez en tant que professionnel (« trader ») ; depuis février 2025, les apps sans cette déclaration ne sont plus distribuées dans l’Union européenne.
• Une fiche d’app avec un identifiant de bundle enregistré, un nom (30 caractères maximum), une langue principale et un SKU.
• Des outils à jour. Apple relève chaque printemps la version minimale du SDK ; en 2026, les builds doivent être compilés avec Xcode 26 et le SDK iOS 26 ou ultérieur.

URL obligatoires et métadonnées

App Store Connect demande trois URL. Deux sont obligatoires, et App Review les ouvre.

• URL de politique de confidentialité, obligatoire pour toutes les apps, même celles qui ne collectent rien (règle 5.1.1(i)). Accessible aussi depuis l’app, elle précise ce que vous collectez, pourquoi, qui y a accès (fournisseurs de SDK compris), combien de temps et comment en demander la suppression.
• URL d’assistance, obligatoire. La règle 1.5 exige un moyen simple de vous contacter : une adresse e-mail valide ou un formulaire, pas une page vide ni une simple page d’accueil.
• URL marketing, facultative : la page produit de votre site.

Confidentialité : étiquettes App Store et manifeste

Trois sources doivent concorder : vos réponses dans App Store Connect, le manifeste inclus dans le build et ce que fait réellement le code.

Les informations « Confidentialité de l’app »

Ces « étiquettes nutritionnelles » déclarent chaque type de données collecté par l’app ou ses SDK (santé, localisation, identifiants, usage, diagnostics…), s’il est associé à l’identité de l’utilisateur et s’il sert au suivi publicitaire, lequel impose aussi la fenêtre App Tracking Transparency (5.1.2). « Données non collectées » n’est valable que si c’est vrai pour chaque SDK, outils d’analyse et de plantage compris.

Le manifeste de confidentialité (PrivacyInfo.xcprivacy)

Cette liste de propriétés, intégrée à l’app et à chaque SDK, déclare les domaines de suivi, les données collectées et les API « à motif obligatoire » (required reason APIs) : UserDefaults, dates des fichiers, durée depuis le démarrage, espace disque et claviers actifs. Depuis mai 2024, un build qui en utilise une sans motif approuvé reçoit le message ITMS-91053: Missing API declaration. L’entrée la plus courante :

<key>NSPrivacyAccessedAPITypes</key>
<array>
  <dict>
    <key>NSPrivacyAccessedAPIType</key>
    <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
    <key>NSPrivacyAccessedAPITypeReasons</key>
    <array>
      <string>CA92.1</string>
    </array>
  </dict>
</array>

Le motif CA92.1 couvre les données que seule votre app lit et écrit. Les SDK tiers listés par Apple doivent embarquer leur propre manifeste signé : mettez-les à jour avant d’archiver.

Les textes des demandes d’autorisation

Chaque demande d’autorisation exige dans Info.plist un texte qui justifie précisément l’accès (5.1.1). « Cette app a besoin de votre micro » appelle un refus ; « Le micro sert à mesurer le niveau sonore. Le son est analysé sur votre iPhone et n’est jamais enregistré. » convient. Les apps de santé ont des règles supplémentaires (5.1.3) : les données HealthKit ne peuvent pas servir à la publicité, et l’app ne doit pas écrire de données inexactes dans Santé.

Comptes, accès de démonstration et suppression

• N’imposez pas d’inscription sans nécessité (5.1.1(v)). Beaucoup de nos apps n’ont aucun compte : les données restent sur l’appareil et se synchronisent via l’iCloud de l’utilisateur.
• Permettez la suppression du compte dans l’app dès qu’on peut en créer un. Une désactivation ne suffit pas, et « écrivez-nous » n’est admis que dans les secteurs très réglementés. Avec « Se connecter avec Apple », révoquez les jetons à la suppression.
• Doublez toute connexion via un service tiers d’une option respectueuse de la vie privée, comme « Se connecter avec Apple » (règle 4.8).
• Fournissez un accès de démonstration à App Review : un compte valable toute la durée de la vérification, serveur en marche, ou un mode démo complet.
• Rédigez des notes pour l’examinateur. Si une fonction exige ce qu’il n’a pas (un circuit, une montre mécanique, un capteur Bluetooth), expliquez comment la tester, vidéo d’écran à l’appui.

Abonnements et achats intégrés

Les contenus et fonctions numériques se vendent par achat intégré (3.1.1), et les abonnements à renouvellement automatique obéissent à des règles d’information précises (3.1.2). Vérifiez que :

• Le paywall affiche le nom de l’abonnement, sa durée, le prix par période, ce qu’il inclut et les conditions de l’essai gratuit.
• Le paywall renvoie vers vos conditions d’utilisation (CLUF) et votre politique de confidentialité ; dans les métadonnées, les conditions vont dans le champ Contrat de licence ou la description.
• Un bouton Restaurer les achats est visible (la règle 3.1.1 exige un mécanisme de restauration).
• Chaque produit a un nom localisé, une description et une capture pour App Review ; les premiers achats intégrés sont soumis avec une version de l’app.

Avec StoreKit 2 et SwiftUI, l’essentiel est fourni :

SubscriptionStoreView(groupID: "YOUR_GROUP_ID") {
    PaywallHeader()
}
.storeButton(.visible, for: .restorePurchases)
.subscriptionStorePolicyDestination(url: termsURL, for: .termsOfService)
.subscriptionStorePolicyDestination(url: privacyURL, for: .privacyPolicy)

Chacune de nos descriptions se termine d’ailleurs par la mention standard de renouvellement (reconduction automatique sauf résiliation au moins 24 heures avant la fin de la période) et les liens vers les conditions et la politique de confidentialité : l’examinateur a la réponse avant de poser la question.

Captures d’écran et fiche App Store

• iPhone : les captures 6,9 pouces sont obligatoires (1320 × 2868 ou 1290 × 2796 pixels en portrait) ; les tailles inférieures en sont dérivées.
• iPad : si l’app tourne sur iPad, les captures 13 pouces sont aussi obligatoires (2064 × 2752 ou 2048 × 2732 pixels).
• Mac : captures au format 16:10, de 1280 × 800 à 2880 × 1800 pixels.
• Jusqu’à 10 captures par taille et par langue, plus trois aperçus vidéo de 15 à 30 secondes.
• Montrez l’app en situation (2.3.3), pas un écran de lancement ou de connexion, ni une fonction absente du build.

Les captures sont aussi votre meilleur levier de conversion : notre service d’optimisation App Store (ASO) couvre mots-clés, textes de la fiche et captures localisées.

Classification par âge et conformité à l’exportation

Classification par âge. Apple a revu ses classifications en 2025 : l’échelle est désormais 4+, 9+, 13+, 16+ et 18+ (à la place de 12+ et 17+), et le questionnaire couvre désormais les contrôles parentaux intégrés, la messagerie, le contenu créé par les utilisateurs et les sujets médicaux ou de bien-être. Les apps existantes devaient y répondre avant le 31 janvier 2026 pour continuer à publier leurs mises à jour. Répondez avec précision : une classification trop basse est un motif de refus.

Conformité à l’exportation. Si votre app n’utilise qu’un chiffrement exempté (HTTPS via URLSession, cryptographie standard d’Apple), déclarez-le une fois dans Info.plist et la question disparaît des envois suivants :

<key>ITSAppUsesNonExemptEncryption</key>
<false/>

TestFlight : testez le build qu’Apple va examiner

• Test interne : jusqu’à 100 membres de votre équipe, dès que le build est traité.
• Test externe : jusqu’à 10 000 testeurs sur invitation ou lien public, après une courte vérification bêta. Les builds expirent au bout de 90 jours.
• Reproduisez le parcours de l’examinateur : installation neuve, autorisations refusées, hors ligne, compte de démo, achat et restauration en sandbox, et la plus ancienne version d’iOS prise en charge (iOS 17 pour la plupart de nos apps).
• Testez aussi une app iPhone sur iPad : elle peut y tourner en mode compatibilité, l’examinateur peut l’y essayer, et un plantage reste un refus 2.1.

Les motifs de refus les plus fréquents

Un mot sur la 4.3, puisque nous publions un large catalogue : un portefeuille d’apps n’est pas du spam quand chacune résout un problème différent. Un journal de crises d’épilepsie, un carnet de plongée et un gestionnaire de cave à vin partagent une architecture, pas une raison d’être. Ce qui déclenche la 4.3, c’est la même app sous plusieurs noms, ou un modèle simplement repeint.

Que faire après un refus ?

Un refus est un message, pas un verdict. Apple indique qu’en moyenne 90 % des soumissions sont examinées en moins de 24 heures : bien géré, un refus coûte un jour ou deux.

1. Lisez le message dans App Store Connect (la messagerie App Review, longtemps appelée Centre de résolution) et notez le numéro de la règle.
2. Si l’examinateur a manqué quelque chose, répondez dans le fil avec des étapes claires et une vidéo d’écran. Un problème de métadonnées ne demande pas de nouveau build.
3. Si le problème est réel, corrigez, incrémentez le numéro de build, envoyez et résumez la correction.
4. Si le désaccord persiste, faites appel auprès de l’App Review Board, faits à l’appui. Pour un correctif critique ou un événement daté, demandez un examen accéléré.
5. Pour une app déjà publiée, un correctif n’est en général pas bloqué par un problème sans rapport, sauf d’ordre juridique : traitez-le dans la version suivante.

Comment Develak gère la soumission App Store

Nous avons publié 34 apps sur l’App Store depuis mars 2025, pour iPhone, iPad et Mac, dans jusqu’à 44 langues. Chaque soumission suit cette checklist : manifeste et réponses « Confidentialité de l’app » relus ensemble, textes d’autorisation écrits pour des humains, conditions d’abonnement complètes, notes et accès de démo pour App Review, captures dans toutes les tailles et toutes les langues.

Pour nos clients, nous configurons App Store Connect, rédigeons métadonnées et notes de vérification, préparons les captures localisées, menons les tests TestFlight et suivons les échanges avec App Review. Nul ne peut garantir une validation, puisque seule Apple décide, mais cette méthode élimine les refus évitables. Découvrez notre offre de développement d’application iOS et notre optimisation App Store (ASO), ou parlez-nous de votre app.

Questions fréquentes