Sommaire
L'essentiel en 30 secondes
- Apple vérifie chaque application avant publication, et le développeur est responsable de tout ce qu'elle contient, y compris les outils tiers.
- Une application soumise doit être finale et complète : pas de texte provisoire, pas de site vide.
- Pour débloquer des fonctions payantes dans l'application, Apple impose en principe l'achat intégré.
- Une application qui n'est pas « utile, unique ou comparable à une vraie application » n'a pas sa place sur l'App Store.
Beaucoup de projets d'application s'arrêtent à l'étape du refus d'Apple. Ces refus ne sont pas arbitraires : les règles sont publiées. Les connaître avant de concevoir évite de refaire du travail.
Avant de soumettre
D'après les consignes d'Apple :
- Tester sur les appareils compatibles pour éliminer plantages et bugs.
- Donner un accès complet à l'équipe de vérification : compte de démonstration ou mode démo complet, avec les services en ligne actifs.
- Expliquer dans les notes les fonctions peu évidentes et les achats intégrés.
Les règles qui reviennent le plus
Performance
- Application complète (2.1) : la soumission doit être la version finale, avec toutes les informations et des adresses fonctionnelles. « Les textes provisoires, sites vides et autres contenus temporaires » doivent avoir disparu.
- Versions de test (2.2) : les démos et bêtas n'ont pas leur place sur l'App Store ; Apple oriente vers TestFlight.
- Informations exactes (2.3) : captures d'écran, descriptions et aperçus doivent refléter l'expérience réelle.
Business
- Achat intégré (3.1.1) : pour débloquer des fonctions dans l'application (abonnements, contenus premium), il faut utiliser l'achat intégré, pas un mécanisme maison.
- Abonnements (3.1.2) : ils doivent apporter une valeur continue.
Conception
- Fonctionnalités minimales (4.2) : « si votre application n'est pas particulièrement utile, unique ou "dans l'esprit d'une application", elle n'a pas sa place sur l'App Store ». Apple écarte les applications qui ne sont que du matériel marketing, une capture de site web ou une collection de liens.
- Copies et spam (4.3) : pas de multiples applications presque identiques.
- Connexion tierce (4.8) : si vous proposez une connexion via un service tiers, une option équivalente protégeant les données doit exister, sauf exception.
Légal
- Politique de confidentialité (5.1.1) : un lien dans la fiche App Store Connect et dans l'application, facilement accessible.
- Consentement avant de collecter des données, et collecte minimale ; un suivi publicitaire demande l'autorisation de l'utilisateur.
- Suppression de compte : toute application qui permet de créer un compte doit permettre de le supprimer depuis l'application.
(Nous avons lu les consignes jusqu'à la section 5.2 ; les passages suivants n'ont pas été vérifiés ici.)
Diagnostic · 30 min
Réserver mon diagnosticOù en est votre présence digitale ? On vous le dit en 30 minutes.
Ce que cela change dans un projet d'application
- Cadrer l'utilité d'abord. Si votre application est « votre site dans une enveloppe », elle risque le refus (règle 4.2). Une application web adaptée au mobile peut alors suffire : lisez application mobile ou site web (PWA).
- Prévoir la politique de confidentialité et la suppression de compte dès la conception.
- Prévoir un compte de démonstration pour la vérification.
- Décider tôt du mode de paiement : achat intégré ou paiement hors application, selon la nature de ce qui est vendu (les biens et services consommés en dehors de l'application obéissent à d'autres règles, voir 3.1.3).
- Les comptes développeur sont à votre nom, pas à celui du prestataire.
Dans l'offre applications sur mesure, nous cadrons ces points avant d'écrire du code, et nous publions l'application à votre nom. Si vous hésitez sur la nature du projet, le diagnostic gratuit tranche.
Source : Apple, App Review Guidelines, consultées le 21 octobre 2026 (jusqu'à la section 5.2). Les règles évoluent : référez-vous au texte d'Apple.
