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 évitables relèvent d’une poignée de règles : 2.1 (plantages et app incomplète), 2.3 (métadonnées inexactes), 3.1 (achats intégrés), 4.2 et 4.3 (fonctionnalité minimale et spam) et 5.1.1 (collecte de données). Voici la checklist que Develak applique avant chaque soumission de ses plus de 30 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 (ou 6,5 pouces à défaut), 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+).

Le parcours de soumission en un coup d’œil

Soumettre une app se fait en quatre étapes : compiler et envoyer le build depuis Xcode, laisser App Store Connect le traiter et le tester dans TestFlight, compléter la fiche de l’app (URL, confidentialité, captures, classification par âge, notes pour l’examinateur), puis la soumettre à App Review. Si l’app est validée, vous choisissez quand elle sort ; si elle est refusée, le message cite une règle, et vous corrigez les métadonnées ou envoyez un nouveau build. Chaque section ci-dessous couvre une partie de ce parcours.

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 le 17 février 2025, les apps sans cette déclaration sont retirées de l’App Store 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 : depuis le 28 avril 2026, les builds doivent être compilés avec Xcode 26 et le SDK iOS 26 ou ultérieur (voir les exigences à venir d’Apple). Garder vos apps publiées sur un SDK récent fait partie de notre offre de maintenance d’application iOS.

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) des App Review Guidelines). 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. La règle 5.1.2(i) cite désormais explicitement l’IA tierce : si des données personnelles sont envoyées à un service d’IA externe, vous devez l’indiquer clairement et obtenir une autorisation explicite au préalable.

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. Notre guide du manifeste de confidentialité iOS détaille chaque catégorie d’API et ses motifs.

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. Paywall, essais gratuits et refus les plus courants : tout est détaillé dans notre guide pour faire valider vos abonnements App Store.

Captures d’écran et fiche App Store

• iPhone : les captures 6,9 pouces sont obligatoires (1320 × 2868, 1290 × 2796 ou 1260 × 2736 pixels en portrait). À défaut, des captures 6,5 pouces (1284 × 2778 ou 1242 × 2688 pixels) sont acceptées. Les écrans plus petits utilisent des versions réduites.
• 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, en 1280 × 800, 1440 × 900, 2560 × 1600 ou 2880 × 1800 pixels.
• De 1 à 10 captures par taille et par langue (PNG ou JPEG, sans transparence), plus jusqu’à 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 spécifications d’Apple listent toutes les tailles acceptées, et notre guide des tailles de captures App Store indique celles qu’il faut réellement fournir. 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 intégrés à l’app, les fonctions comme la messagerie ou le contenu créé par les utilisateurs, les sujets médicaux ou de bien-être et les thèmes violents. 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, une fois le build validé par l’examen bêta de TestFlight. 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.

Groupes, liens publics, retours des testeurs et expiration des builds : voir notre guide TestFlight.

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. Apple a précisé les deux volets de la 4.3, exemples à l’appui, lors de la mise à jour des règles de juin 2026 ; notre guide sur les refus pour les règles 4.2 et 4.3 explique comment y répondre.

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 mise à jour corrective, Apple peut vous proposer de valider la soumission en cours et de régler les autres problèmes relevés dans la version suivante, sauf s’ils touchent à des questions juridiques ou de sécurité.

Comment Develak gère la soumission App Store

Nous avons publié plus de 30 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