Parcours techniquesMis à jour le 22 octobre 202613 min de lecture

Préparer techniquement une app iOS avant App Review : la checklist complète

Versions Xcode et iOS minimales, autorisations, manifeste de confidentialité, chiffrement, tests sur iPhone : tout préparer avant l'envoi en revue.

Sources Apple vérifiées le 22 octobre 2026 · relu par Équipe Briksell

Sommaire

Réponse courte

Avant d'envoyer ton app à l'équipe de revue d'Apple (App Review), dix points techniques évitent la plupart des refus et des blocages :

  1. Construire l'app avec les versions minimales d'outils exigées par Apple.
  2. Avoir un identifiant d'app et des numéros de version et de build cohérents.
  3. Écrire un texte d'explication clair pour chaque autorisation demandée (caméra, position…).
  4. Fournir un manifeste de confidentialité pour l'app et pour les outils tiers concernés.
  5. Répondre aux questions de chiffrement (conformité à l'export).
  6. Tester sur de vrais appareils, y compris l'iPad si ton app peut s'y installer.
  7. N'utiliser que des fonctions publiques d'iOS, sans fonction cachée (section 2.5.19).
  8. Laisser le serveur allumé et fournir un compte de démonstration.
  9. Tester les achats intégrés dans l'environnement de test d'Apple.
  10. Vérifier que tous les liens fonctionnent, dont la politique de confidentialité et le support.

Ce guide est valable quelle que soit la technologie ; les réglages propres à Expo (React Native) sont signalés à chaque étape.

Qui est concerné, et les exceptions

Toutes les apps iOS, nouvelles ou mises à jour

Les exigences d'outils et de confidentialité s'appliquent à chaque envoi. Une mise à jour d'une app ancienne doit donc, elle aussi, respecter les versions minimales en vigueur.

Ce qui dépend de ton app

  • Le manifeste de confidentialité des outils tiers ne concerne que les apps qui intègrent un des outils listés par Apple.
  • La suppression de compte ne concerne que les apps qui permettent de créer un compte.
  • Le test des achats intégrés ne concerne que les apps qui en proposent.

Ce que ce guide ne couvre pas

Les étiquettes de confidentialité de la fiche sont traitées dans Étiquettes de confidentialité App Store. L'ordre global des étapes est dans Comment publier une application iOS sur l'App Store.

Procédure pas à pas

1. Vérifier les versions minimales d'outils

Apple fixe des versions minimales pour tout envoi vers App Store Connect. À la date de vérification :

Depuis ou à partir deExigence
28 avril 2026Construire avec Xcode 26 ou plus récent et le SDK iOS 26
9 septembre 2026Les apps iOS doivent cibler iOS 13 ou plus récent
Avril 2027 (annoncé)Construire avec le SDK iOS 27 et cibler iOS 15 ou plus récent

Le « SDK », c'est la boîte à outils d'Apple fournie avec Xcode. Avec Expo, les builds sont faits sur les serveurs d'EAS Build : vérifie dans la documentation d'Expo quelle version de Xcode est utilisée pour ton projet.

2. Régler l'identifiant, la version et le numéro de build

À chaque envoi, App Store Connect utilise l'identifiant de l'app (bundle ID) et le numéro de version pour rattacher le build à la bonne fiche, et le numéro de build pour le distinguer des autres. Concrètement :

  • le bundle ID doit être exactement celui de ta fiche App Store Connect ;
  • chaque nouvel envoi doit avoir un numéro de build différent ;
  • une version ne peut avoir qu'un seul build sélectionné, mais tu peux en changer jusqu'à l'envoi en revue.

Avec Expo, le bundle ID se règle dans la configuration de l'app (ios.bundleIdentifier), et l'envoi peut se faire avec EAS Submit, qui fonctionne sans Mac d'après la documentation d'Expo : voir Publier une app sur l'App Store sans Mac.

3. Écrire un texte clair pour chaque autorisation

Quand ton app demande l'accès à la caméra, à la position, au micro ou aux photos, iOS affiche un message avec ton texte d'explication (« purpose string »). La section 5.1.1(ii) demande que ce texte décrive clairement et complètement l'usage des données. Apple précise :

  • à éviter : « Pour utiliser la position. » ou « Vos données serviront à améliorer votre expérience. » ;
  • à faire : une phrase concrète, avec un exemple, par exemple « L'app utilise ta position pour te proposer l'itinéraire jusqu'à ta destination. » ;
  • un texte différent pour chaque autorisation.

Ne demande que les accès utiles à la fonction principale (section 5.1.1(iii)), et propose une alternative si l'utilisateur refuse, comme saisir une adresse à la main au lieu de partager sa position (section 5.1.1(iv)).

Avec Expo, ces textes se règlent dans la configuration de l'app, sous ios.infoPlist (par exemple la clé NSCameraUsageDescription).

4. Ajouter le manifeste de confidentialité

Le manifeste de confidentialité est un fichier nommé PrivacyInfo.xcprivacy. Il décrit les données collectées par l'app ou par un outil tiers (SDK), et les raisons d'utiliser certaines fonctions d'iOS qu'Apple juge sensibles (les « required reason APIs »). Apple l'exige, avec ces raisons, depuis le 1er mai 2024.

  • Apple publie une liste d'outils tiers courants (par exemple Firebase, Alamofire, Capacitor, Cordova) pour lesquels le manifeste est obligatoire dans une nouvelle app, ou dans une mise à jour qui ajoute l'un de ces outils. Une signature de l'outil est aussi exigée quand il est intégré sous forme binaire.
  • Les étiquettes App Privacy de ta fiche doivent, elles aussi, couvrir les données collectées par les outils tiers : Apple présente les manifestes comme un moyen de les rendre plus exactes.

Avec Expo, le manifeste se déclare dans la configuration app.json, sous expo.ios.privacyManifests. La documentation d'Expo prévient qu'Apple ne lit pas toujours correctement les manifestes de certaines dépendances : il peut falloir recopier leurs raisons dans le manifeste de l'app.

Le détail est dans Manifeste de confidentialité iOS et SDK tiers, et la cohérence avec la fiche dans Étiquettes de confidentialité App Store.

5. Répondre aux questions de chiffrement

Si ton app utilise du chiffrement, même celui fourni par iOS, App Store Connect te pose des questions de conformité à l'export (règles américaines, et règles françaises pour certaines apps distribuées en France). Tant que tu n'y as pas répondu, le build reste au statut Missing Compliance et ne peut pas être envoyé en revue.

Pour ne pas répondre à chaque envoi, Apple conseille de déclarer ta réponse dans le fichier de configuration de l'app (Info.plist, clé ITSAppUsesNonExemptEncryption). Avec Expo, c'est le réglage ios.config.usesNonExemptEncryption.

Attention : la bonne réponse dépend de ton app (simple HTTPS, chiffrement propre, etc.) et Apple précise qu'elle engage ta responsabilité. Ce guide ne tranche pas ton cas : suis le questionnaire d'App Store Connect et la documentation d'Apple sur le chiffrement.

6. Tester sur de vrais appareils

Apple teste les apps installées sur de vrais appareils, avec de vrais réseaux. Les points à contrôler :

  • Aucun plantage sur la dernière version d'iOS : la section 2.1 refuse les apps qui plantent ou ont des problèmes techniques évidents.
  • Compatibilité iPad : une app conçue pour iPhone peut s'installer sur iPad en mode compatibilité, même si tu n'as pas coché l'iPad. Teste-la.
  • Réseau IPv6 seul : l'app doit fonctionner sur un réseau uniquement IPv6 (section 2.5.5).
  • TestFlight : distribue le build à des testeurs (jusqu'à 100 internes et 10 000 externes) pour couvrir plusieurs modèles d'iPhone. Chaque build reste testable 90 jours, et le premier build envoyé à des testeurs externes passe par une review bêta d'Apple. Voir TestFlight : tester ton app sur iPhone.

Le simulateur sert à contrôler les bases, mais Apple déconseille d'envoyer sans test sur appareil réel.

7. N'utiliser que des fonctions publiques, sans rien cacher

  • L'app ne peut utiliser que les fonctions publiques d'iOS et doit fonctionner sur la version d'iOS actuelle (section 2.5.1).
  • Elle ne peut pas télécharger ni exécuter du code qui ajoute ou modifie ses fonctions (section 2.5.2).
  • Aucune fonction cachée, inactive ou non documentée (section 2.5.19) : tout ce que fait l'app doit être visible pour l'utilisateur et l'équipe de revue.

Prudence : les mises à jour à distance du code JavaScript (par exemple EAS Update avec Expo) restent soumises à la section 2.5.2 et au contrat de licence de l'Apple Developer Program. Par précaution, ne t'en sers pas pour ajouter ou changer des fonctions sans passer par une nouvelle revue : envoie un nouveau build.

8. Préparer le serveur, le compte de démo et la suppression de compte

  • Serveur allumé pendant toute la revue (section 2.1).
  • Compte de démonstration valide le jour de l'envoi ; un compte par type d'utilisateur si l'app en a plusieurs ; un code d'authentification fourni à l'avance s'il en faut un ; un abonnement expiré si l'app vend des abonnements.
  • Suppression de compte depuis l'app si elle permet d'en créer un (section 5.1.1(v)). Si tu utilises Sign in with Apple, Apple indique qu'il faut révoquer les jetons de l'utilisateur via son API lors de la suppression. Voir Suppression de compte obligatoire.
  • Connexion par un service tiers (Google, Facebook…) : prévois l'option équivalente demandée par la section 4.8 (nom et e-mail seulement, e-mail masquable, pas de pistage publicitaire), sauf exception prévue par la règle. Sign in with Apple remplit ces critères : voir Sign in with Apple.
  • Ton propre compte Apple Developer : si ton app a été créée avec un service de génération d'apps, la section 4.2.6 exige qu'elle soit soumise par le fournisseur du contenu, donc par toi, depuis ton compte (s'inscrire à l'Apple Developer Program).

9. Tester les achats intégrés comme le fera Apple

L'équipe de revue teste les achats dans la Sandbox, le même environnement de test que toi. Vérifie que :

  • l'accord Paid Apps est actif (sinon, les achats payants ne fonctionnent pas en revue) ;
  • l'app récupère les produits via StoreKit avant de les afficher ;
  • si ton serveur valide les achats, il gère aussi les transactions de la Sandbox, puisque la revue s'y déroule ;
  • un bouton Restaurer les achats est présent (section 3.1.1) ;
  • les produits au statut Ready for Review sont ajoutés à la soumission.

La configuration complète est dans Abonnements et achats intégrés Apple.

10. Vérifier tous les liens

Tous les liens de l'app doivent fonctionner. Un lien vers le support avec des coordonnées à jour et un lien vers la politique de confidentialité sont exigés pour toutes les apps (sections 1.5, 2.1 et 5.1.1(i)). La politique doit être accessible dans l'app et dans App Store Connect.

Erreurs fréquentes

Envoyer un build construit avec une ancienne version de Xcode

Il ne respecte pas l'exigence minimale qu'Apple impose à tout envoi vers App Store Connect. Vérifie les versions minimales du moment avant de construire.

Un build bloqué en Missing Compliance

Tu as oublié les questions de chiffrement. Réponds-y dans App Store Connect ou déclare la réponse dans la configuration de l'app.

Des textes d'autorisation génériques

« Cette app a besoin de la caméra » ne suffit pas. Explique à quoi elle sert concrètement.

Un outil tiers sans manifeste de confidentialité

Pour les outils de la liste d'Apple, le manifeste est obligatoire dans une nouvelle app. Mets à jour l'outil vers une version qui en contient un.

Une app testée seulement sur simulateur

Les plantages liés à un vrai appareil, au réseau ou à l'iPad ne se voient pas sur simulateur.

Le serveur de test éteint ou le compte de démo expiré

L'équipe de revue ne peut pas tester l'app et la refuse au titre de la section 2.1. Pour savoir combien de temps attendre ensuite, voir Combien de temps dure la validation App Store. Les autres causes de refus sont dans Pourquoi Apple refuse une application.

Vérification

Coche chaque point avant l'envoi en revue. La liste est enregistrée seulement dans ton navigateur.

Ta checklist0/11

Tes cases sont gardées dans ce navigateur. Cocher une case ne prouve rien à Apple : vérifie chaque point pour de vrai.

Sources Apple et date de vérification

Vérifié le 22 octobre 2026 sur les pages officielles :

FAQ

Faut-il un Mac pour préparer et envoyer une app iOS ?

Avec Xcode, oui, car c'est une app Mac. Avec Expo, la documentation d'Expo indique qu'EAS Submit fonctionne sur macOS, Linux et Windows. Un iPhone reste indispensable pour tester. Voir la FAQ : publier sur l'App Store sans Mac.

Quelle version minimale d'iOS dois-je cibler ?

Depuis le 9 septembre 2026, au moins iOS 13 pour être accepté à l'envoi ; Apple annonce iOS 15 minimum à partir d'avril 2027. Tu peux cibler plus récent selon les fonctions que tu utilises.

Le simulateur suffit-il pour tester ?

Non. Apple teste sur de vrais appareils et recommande de tester sur chaque type d'appareil où l'app peut s'installer, pas seulement en simulation.

Mon app utilise seulement HTTPS : dois-je déclarer du chiffrement ?

App Store Connect te pose la question à chaque nouvelle version. La réponse dépend de ton app et de la réglementation : suis le questionnaire d'Apple. Ce point n'est pas tranché ici (voir la note de l'étape 5).

Le manifeste de confidentialité remplace-t-il les étiquettes App Privacy ?

Non. Le manifeste est un fichier dans l'app ; les étiquettes App Privacy sont des réponses dans App Store Connect, affichées sur ta fiche. Les manifestes de tes outils tiers t'aident à savoir quoi déclarer, mais tu dois quand même remplir les étiquettes. Le détail est dans Manifeste de confidentialité iOS et SDK tiers.

Passer à l'action

La préparation technique est la partie la plus facile à oublier quand on n'est pas développeur. Avec Briksell, l'IA écrit le code de ton app React Native / Expo et, pour les abonnés, App Store Readiness contrôle ce code sur les règles Apple qui concernent ton app, puis le fait corriger par l'agent. Ce n'est pas une validation : seule Apple décide. Deux limites à connaître : HealthKit, l'audio en arrière-plan et les notifications push demandent un build natif (ils ne marchent pas dans l'aperçu), et l'envoi sur TestFlight ou l'App Store depuis Briksell arrive bientôt. En attendant, tu exportes le code et tu l'envoies avec EAS Build et EAS Submit, depuis ton propre compte Apple Developer. Créer mon app.

Sources officielles

À lire ensuite

← Tous les guides « Parcours techniques »Tous les thèmes