9 100 620 soumissions d'applications en 2025 et 2 093 244 d'entre elles ont été rejetées 9 093 244 d'entre elles ont été rejetées, avec 387 087 ont été approuvés plus tard après une réjection, selon les données de transparence de l'App Store d'Apple. Cela équivaut à environ 23 % initialement rejetés, donc la soumission d'applications iOS n'est pas une étape d'upload cérémonial. Il s'agit d'un processus de mise en ligne à haute exigence où la signature, le comportement binaire, les métadonnées, la politique de magasin et l'accès du réviseur doivent tenir ensemble.
Apple dit également 90 % des soumissions sont examinées en moins de 24 heures sur sa page de revue d'AppUne revue rapide est utile, mais elle ne rend pas l'approbation automatique. Dans la pratique, les équipes qui expédient calmement traitent la soumission comme réseau de résilience aux refus: ils rendent la coquille native stable, préparent une version de build améliorée pour les revues, mettent en scène les changements avec soin et gardent un chemin sûr pour résoudre les problèmes de couches web sans transformer chaque bug d'urgence de copie ou de mise en forme en une nouvelle soumission de magasin.
Table des Matières
- Ce que la soumission d'application iOS implique vraiment
- Prérequis qui préviennent les échecs de signature
- Construire et signer votre application Capacitor pour la mise en ligne
- Chargement de Test en cours avec TestFlight et complétion des métadonnées de l'App Store
- Gestion de la revue de l'application et évitez les rejets courants
- Vérifications finales et mise à jour des mises à jour sans résoumission de tout
Ce que l'envoi d'une application iOS implique vraiment
Considérez un modèle de failure typique : une équipe termine une application Capacitor en retard le vendredi, l'archivage dans Xcode, l'envoi de la build, et suppose que la partie difficile est terminée. Lors de la revue, Apple constate que le compte de connexion échoue, un point de terminaison backend est indisponible ou une fonction décrite dans les métadonnées ne peut pas être atteinte. Le rejet peut arriver rapidement, mais la correction nécessite une nouvelle build, un nouvel envoi, un nouveau cycle de revue, et un plan de mise en production qui n'a jamais permis d'interruption.
Traitez l'envoi comme un système de résilience aux refuspas comme une liste de vérification d'importation. Le chemin complet commence avant Xcode :
- Inscrivez-vous au programme Apple Developer et assurez-vous que les personnes chargées de la signature et de App Store Connect disposent des accès appropriés.
- Créez et configurez l'identité de l'application, y compris l'ID de bundle, les capacités, les certificats et la configuration de provisionnement.
- Créez l'enregistrement App Store Connect avec l'identifiant de bundle correspondant.
- Construisez et signez l'archive de version de production dans Xcode ou à travers un flux de travail CI contrôlé.
- Envoyez le fichier binairepuis utilisez TestFlight pour tester l'exact artefact destiné à la distribution.
- Informations de métadonnées et informations de revue complètesSoumettre la version et répondre à la décision d'Apple.
Trois couches évaluées par Apple
Le package comporte trois couches connectées.
La couche binaire est l'application compilée, sa signature, ses autorisations, ses plugins natifs, ses déclarations de confidentialité, et son comportement en temps de exécution. La couche de métadonnées comprend les captures d'écran, la description, les mots-clés, les URL, les réponses d'âge de notation, les informations de confidentialité, et les informations de revue d'application. La couche de politique couvre le comportement de l'application, ce qu'elle vend, la façon dont elle gère les données utilisateur, et si son implémentation de magasin respecte les règles d'Apple. La couche de politique couvre comment l'application se comporte, ce qu'elle vend, comment elle gère les données utilisateur, et si son implémentation de magasin suit les règles d'Apple.
A une application Capacitor ajoute une complication spécifique. Le JavaScript et le CSS peuvent être cross-plateforme, mais le wrapper iOS a toujours une cible Xcode, des dépendances natives, des paramètres d'entitlement, des paramètres de signature et un ensemble d'actifs web intégrés. Une modification d'un plugin, d'un schéma de URL, d'une capacité de notification push ou d'une configuration native peut transformer une mise à jour web routine en une mise à jour native qui doit passer en revue.
Règle pratique : Traitez chaque soumission comme un artefact de mise à jour réproducible, et non comme le dossier le plus récent sur l'ordinateur d'un développeur.
La file d'attente de revue d'Apple affecte également la planification de la mise à jour. Apple autorise au plus deux soumissions en revue au même moment sur une plateformeune version d'application et un élément tel qu'un événement In-App, selon ses guides de soumission.
La mise en file d'attente de modifications critiques de mise à jour crée un risque évitable. Étalez la version de l'application en premier, complétez les informations de revue d'application avant la soumission, et gardez les modifications natives séparées des correctifs de la couche web dans la mesure du possible. Un correctif de la couche web peut souvent être expédié à travers des mises à jour de mise en ligne contrôlées, à condition qu'il ne modifie pas les capacités natives ou ne viole pas les règles d'Apple. Les modifications natives appartiennent toujours à la file d'attente de revue normale. Les équipes peuvent documenter la propriété, les contrôles de statut et les procédures de réponse avecla gestion de revue de l'App Store
, de sorte qu'une réjection produit un correctif contrôlé au lieu d'une reconstruction d'urgence.
Les échecs de signature commencent généralement par un dérive de configuration. L'ID de l'application dans App Store Connect diffère de l'ID de cible Xcode, une capacité existe dans le projet mais pas sur le portail du développeur, ou une machine CI a un certificat sans le profil de provisionnement qui l'autorise.
Établir le modèle de compte et de propriété
Confirmer que le compte Apple Developer est actif et que les personnes responsables des lancements peuvent accéder à la fois au portail du développeur et à App Store Connect. Les équipes séparent souvent les tâches, donc la personne qui gère les certificats n'est peut-être pas celle qui soumet les métadonnées. Enregistrez qui possède chaque action, surtout si une agence, un entrepreneur ou un fondateur de startup est impliqué.
Créer le Enregistrement de l'application App Store Connect avant l'envoi. Sélectionnez la plateforme correcte, la langue principale, le nom de l'application, l'ID de l'application et le SKU. L'ID de l'application doit correspondre exactement à l'identifiant utilisé par l'ID de cible Xcode. Un enregistrement créé avec l'identifiant incorrect ne peut pas être réparé en changeant un nom de fichier ultérieurement.
Vérifier les identifiants et les capacités
Dans le portail du développeur Apple, inspectez l'ID d'application associé à l'application. Activez uniquement les capacités dont l'application a besoin, comme les notifications push, les domaines associés, la connexion avec Apple ou le partage de la clé de chaîne. Ensuite, comparez ces paramètres avec la section Paramètres de signature et de capacités du Xcode.
Pour Capacitor, vérifiez l'identifiant dans capacitor.config ou capacitor.config.tsLa cible du projet iOS et le registre de l'application. Si vous avez modifié l'ID de l'application, exécutez la commande de synchronisation appropriée Capacitor et inspectez le projet natif au lieu de supposer que la configuration générée a mis à jour chaque cible.
Utilisez la signature automatique lorsque l'équipe souhaite que Xcode gère les relations de certificat et de profil de routine. La signature manuelle peut être appropriée pour des CI étroitement contrôlés, des cibles multiples ou des organisations avec une propriété stricte des identifiants, mais elle crée plus d'objets qui doivent rester alignés.
Exécutez un vol préalable de version de sortie
Avant l'archivage, vérifiez :
- L'accès à la comptabilité : La sélection d'équipe Apple est l'organisation prévue, et non une équipe personnelle ou héritée.
- L'identité du paquet : La cible Xcode, la Capacitor configuration, l'ID de l'application et le registre App Store Connect utilisent le même identifiant.
- Les capacités : Les autorisations correspondent aux services activés pour l'ID de l'application.
- La signature de distribution : L'identité de distribution sélectionnée est valide et disponible pour l'environnement de construction.
- Provisionnement : Le profil correspond au bon ID d'application, au certificat et à la méthode de distribution.
- Cibles : Les extensions, les services de notification et les autres cibles embarquées utilisent des paramètres de signature compatibles.
- Secrets : Le CI dispose des certificats et des profils requis sans les exposer dans le dépôt.
Une construction de développement réussie prouve que votre équipe peut exécuter l'application. Cela ne prouve pas que vous pouvez la distribuer.
Pour les équipes gérant plusieurs applications ou environnements, la propriété des certificats mérite son propre processus. Gardez un enregistrement de l'expiration, des propriétaires responsables, des étapes de renouvellement et où les profils sont installés. Gestion des certificats Capacitor est une référence utile pour structurer ce workflow sans se fier à la configuration locale d'un développeur.
Construire et signer votre application Capacitor pour la mise en production
L'archive de mise en production doit contenir les actifs web que vous avez l'intention de livrer. Dans les projets Capacitor, cela signifie construire l'interface utilisateur avant, synchroniser le projet natif, vérifier la cible iOS, et ne créer l'archive qu'après. L'archivage d'une ancienne www Un répertoire peut produire une application signée parfaitement valide avec des écrans obsolètes, des correctifs manquants ou une configuration incohérente.
Préparez le projet avant Xcode.
Une séquence fiable ressemble à ceci :
- Construirez l'application web avec la configuration de production.
- Exécutez.
npx cap sync iosAinsi, les dépendances natives et les actifs web sont alignés. - Ouvrez le projet de bureau dans Xcode, et non un fichier de projet obsolète.
- Sélectionnez le schéma d'application souhaité et un destinataire générique de distribution iOS.
- Confirmez la version de marketing et le numéro de build.
- Vérifiez la signature et les capacités pour l'application et chaque cible d'extension.
- Exécutez une build de version de production ou archivez.
La version affichée dans App Store Connect doit correspondre à la version configurée dans le cible Xcode. Le numéro de build doit augmenter pour chaque artefact téléchargé associé à cette version. Conservez ces valeurs dans le contrôle de source ou générez-les dans CI, car la modification manuelle de ces valeurs à travers plusieurs cibles est une façon facile de télécharger le mauvais artefact.
Si Xcode signale qu'il ne peut pas trouver un profil de provisionnement, confirmez d'abord l'équipe et l'ID de bundle. Si il indique que le certificat de signature est invalide, inspectez la clé de chaîne sur la machine effectuant l'archivage. Si un droit est rejeté, comparez le fichier avec les capacités activées pour l'ID d'application. .entitlements Si vous résolvez ces erreurs en basculant les options de signature de manière aléatoire, vous risquez de ne pas trouver la cause du problème.
Inspectez l'artifact après l'archivage.
Dans Xcode, choisissez Produit, puis Archive. Après traitement, ouvrez l'Organisateur et sélectionnez Distribuez l'application, suivi du chemin de distribution pour TestFlight et App Store. Xcode validera l'archive avant de l'envoyer, mais la validation n'est pas un substitut à la mise en œuvre de tests de l'installation.
Installez la version téléchargée à l'aide de TestFlight et exécutez les flux que Apple est susceptible d'inspecter :
- Lancement initial et d'abord
- Création de compte et connexion
- Réinitialisation du mot de passe ou accès par lien magique
- Achats et rétablissement de l'abonnement
- Permissions de caméra, microphone, localisation et notifications
- Lien profond et authentification externe
- Comportement hors ligne et récupération après une requête échouée
- Tout élément décrit dans les captures d'écran ou les métadonnées
Un application Capacitor peut passer la compilation tout en échouant à l'exécution en temps de production car l'URL du backend de production, le chemin des assets web, la chaîne de permission native ou la configuration du plugin diffèrent de la phase de développement. Testez sur un appareil ou un simulateur propre, et testez avec les informations de compte exactes que vous fournirez à App Review.
Les équipes sans un environnement de lancement Mac fiable peuvent utiliser l'infrastructure de build gérée ou CI. L'automatisation des builds Capacitor iOS avec GitHub Actions peut aider à formaliser la création de l'archive, la signature et la gestion des artefacts. Pour les organisations qui embauchent pour gérer ce processus internement, Automatiser les builds __CAPGO_KEEP_0__ iOS avec __CAPGO_KEEP_1__ Actions peut aider à formaliser la création de l'archive, la signature et la gestion des artefacts. Pour les organisations qui embauchent pour gérer ce processus internement, Recrutement d'ingénieurs iOS pour les startups Fournit des informations sur la recherche d'ingénieurs capables de gérer Swift, Xcode, la signature et les opérations de mise en production plutôt que uniquement l'implémentation frontend.
La vidéo ci-dessous est utile comme guide visuel de la partie Xcode du workflow.
Avant l'envoi, inspectez l'identité, la version, le numéro de build, les architectures incluses, les autorisations et les éléments intégrés de l'archive. Gardez l'archive associée à son commit, à sa build web, à sa configuration d'environnement et à ses notes de version. Lorsque la revue soulève une question, cette traçabilité vous permet de répondre précisément.
Téléchargement de Tests Avec TestFlight et Mise à Jour des Métadonnées de l'App Store
Le téléchargement du binaire déclenche un processus de mise en production contrôlée, et non une soumission terminée. L'organisateur Xcode peut envoyer une archive vers App Store Connect, tandis que Transporter convient aux équipes préférant un outil de livraison séparé. App Store Connect traite le téléchargement avant que le build ne soit visible dans TestFlight ou ne devienne disponible pour la sélection de version. Résolvez les retards de traitement et les avertissements de validation avant que la fenêtre de mise en production ne devienne urgente.
Utilisez TestFlight comme barrière de mise en production
Installez la build traitée à l'aide de TestFlight. Un lancement local dans Xcode peut manquer le comportement spécifique à la distribution, les droits et les différences de configuration. Les testeurs internes peuvent confirmer les flux de base rapidement. Les testeurs externes aident à exposer les problèmes auxquels les personnes en dehors de l'équipe App Store Connect peuvent se heurter. Gardez les groupes utiles : un groupe de produit peut valider le comportement des fonctionnalités, tandis qu'un groupe de mise à jour vérifie les mises à jour, l'authentification, les permissions et les chemins prédisposés à la panne.
Les notes de la version bêta doivent indiquer ce qui a changé et où les testeurs doivent regarder. Utilisez la même preuve pour se préparer Information sur la Revue de l'Application. Fournissez un compte de démonstration fonctionnel lorsque la connexion est requise, expliquez les étapes de configuration et identifiez les fonctionnalités qui ne sont pas évidentes à partir de la première page.
Terminez la page produit comme un paquet
Les métadonnées font des promesses que le binaire doit tenir.
Préparez le nom de l'application, le sous-titre si applicable, la description, les mots-clés, les captures d'écran, la catégorie, les réponses d'âge-ratage, les détails de confidentialité, l'URL de support et l'URL de marketing. Testez chaque URL en dehors du réseau de développement. Une exigence VPN interne, une erreur de certificat ou un accès de nettoyage cassé peuvent affaiblir une soumission sinon stable.
Les captures d'écran doivent correspondre à l'interface actuelle et à la fonctionnalité disponible. Supprimez la copie de remplacement, les étiquettes de débogage, les états vides non terminés et le contenu spécifique à l'environnement. Pour plusieurs magasins de vente ou langues, passez en revue chaque version localisée plutôt que de supposer que les chaînes traduites sont suffisantes. Le Guide des métadonnées de l'App Store pour les développeurs fournit un checklist pratique, mais les champs complets ne décrivent pas le flux de produit par eux-mêmes. Les examinateurs ont encore besoin de parvenir à la valeur affichée sur la page produit.
Soumettre des versions délibérément
Traitez les soumissions de version et les articles promotionnels comme des décisions de publication séparées. Soumettez la version critique pour la mise à jour de l'application en premier lorsque les contrôles de disponibilité de l'application fixent la disponibilité. Si un événement In-App est lié à cette version, préparez ses actifs et dates aux côtés du plan de lancement, puis soumettez-l’uniquement lorsque l'événement peut fonctionner avec la build examinée. Cela empêche un article de marketing de devenir la raison pour laquelle un package de version attend, tout en maintenant les travaux de lancement liés traceables.
Après que App Store Connect a traité la build, sélectionnez-la pour la version, répondez aux questions de conformité d'exportation et de droits de contenu, attachez des notes de revue et soumettez. Enregistrez le numéro de build soumis et l'exacte capture d'écran de métadonnées. Si Apple demande quel flux, compte ou version de backend l'examinateur a rencontré, ce enregistrement soutient une réponse précise.
Pour les Capacitor équipes, maintenez les corrections de la couche web séparées des modifications de la version native. Une mise à jour en direct contrôlée peut résoudre les défauts JavaScript ou d'actifs éligibles sans envoyer chaque petite correction web à travers la file d'attente native. Les code, les permissions, les plugins et la configuration native nécessitent toujours le chemin de construction et de revue normal. Cette séparation transforme la soumission en un système de résilience face aux rejets : testez soigneusement le binaire revu, puis réservez les réinscriptions urgentes pour les modifications qui nécessitent l'approbation native.
Manipuler la Revue d'Application et Éviter les Rejets Fréquents
Les données de rejet suggèrent une conclusion pratique : les équipes devraient consacrer moins de temps à deviner les préférences obscures des réviseurs et plus de temps à prouver que l'application est complète, fonctionnelle et accessible. L'analyse de 2025 d'Apple a enregistré 1 354 418 cas de rejet liés à la performanceet les lignes directrices de la Revue d'Application d'Apple exigent des versions finales avec des métadonnées complètes, des URL fonctionnelles, des services backend en direct, un accès de démonstration lorsqu'il est nécessaire et des notes détaillées pour les fonctionnalités non évidentes. Rendez le build soumis résilient
Un réviseur peut rencontrer l'application sans le contexte de votre équipe. Si la première page nécessite un compte, fournissez des identifiants utilisables. Si une souscription est cachée derrière un chemin de navigation particulier, documentez-le. Si une fonctionnalité de matériel nécessite une configuration, expliquez les étapes. Si le backend a des fenêtres de maintenance, planifiez la soumission autour d'une période où les flux critiques sont disponibles.
Les lignes directrices de la Revue d'Application d'Apple
Les problèmes de performance sont particulièrement dangereux car ils peuvent ne se manifester que dans des conditions réelles. Testez la mise en ligne froide, les réseaux lents, les requêtes interrompues, les comptes importants, le refus de permission et le retour en arrière en mode d'arrière-plan. Une erreur de la couche web à l'intérieur d'un Capacitor shell peut ressembler à un défaut d'application native pour le réviseur, capturez donc les erreurs de la couche frontend et les rapports de crash natifs ensemble.
Tirez parti des règles de magasin comme d'entrées de version
Les modifications de 2025 d'Apple ont affecté les applications de magasin US et ont modifié les règles impliquant les boutons, les liens externes et les appels à l'action pour les méthodes de paiement alternatives. Apple identifie les zones affectées comme étant les lignes directrices 3.1.1, 3.1.1(a), 3.1.3 et 3.1.3(a) dans son annonce sur ces changements de lignes directrices. Un flux de monétisation qui passe les hypothèses d'un magasin peut nécessiter un traitement différent ailleurs.
Cela ne signifie pas que vous devez cacher un chemin d'achat de la revue. Cela signifie que vous devez mapper les magasins ciblés, le flux de paiement, les boutons, les liens et la copie explicative avant la soumission. Le réviseur doit voir le même comportement que votre analyse de politique s'attend.
| Motif de rejet | Action préventive | Besoin de resoumission |
|---|---|---|
| Flux d'application incomplet | Supprimez les placeholders, terminez l'inscription et testez chaque fonctionnalité annoncée | D'habitude, si le comportement binaire est incomplet |
| Problèmes de connexion ou serveur indisponible | Fournir un accès à un démon fonctionnel et maintenir les services de production en ligne pendant la revue | Oui, lorsque l'échec se trouve à l'intérieur du code binaire ou du contrat de service |
| Problèmes de performances et de stabilité | Tester les lancements froids, les interruptions de réseau, les permissions et les flux longs en cours | Généralement, surtout lorsque des modifications natives ou intégrées code sont apportées |
| Fonctionnalités non évidentes | Ajouter des notes de revue d'application concises avec des étapes de navigation exactes | Non toujours, si le problème ne concerne que le manque de contexte et que la construction fonctionne déjà |
| URLs brisées ou métadonnées incomplètes | Valider les liens de confidentialité, de support, de marketing et de fonctionnalités à partir d'un environnement propre | Oui, si l'URL est intégrée à l'application ou que les métadonnées ne peuvent pas être corrigées indépendamment |
| Politique de vente et de lien externe incohérents | Vérifiez l'implémentation spécifique du point de vente par rapport aux sections actuelles de la ligne directrice | Généralement, lorsqu'il faut modifier les boutons, les liens ou le comportement d'achat natif |
Séparez les correctifs natifs des correctifs de la couche web
Pour les Capacitor équipes, un système de résilience à la rejet devrait classer le correctif avant de le reconstruire. Les modifications apportées à Swift code, aux plugins, aux autorisations, aux permissions, à la configuration native, aux SDKs embarqués ou au comportement fondamental de l'application doivent être soumises à la file d'attente de révision de l'App Store. Le JavaScript, le CSS, le texte et les actifs web peuvent parfois être livrés à travers un mécanisme d'actualisation en direct gouverné, à condition que l'actualisation reste dans les règles d'Apple et ne transforme pas l'application en quelque chose de matériellement différent du produit examiné.
Capgo est une option pour livrer des ensembles web signés vers des canaux ciblés, avec des contrôles de lancement et de retrait. Cela peut réduire les resoumissions urgentes pour un étiquetage brisé, un problème de disposition ou un garde-web de la couche web, tandis que les modifications natives suivent toujours la voie de révision ordinaire. Il ne s'agit pas d'un contournement de la conformité à la politique. La coquille native soumise et sa fonctionnalité déclarée doivent toujours être complètes et révisables.
Vérifications et mises à jour de livraison sans resoumission de tout
Un boucle de livraison fiable se termine par la vérification, et non l'optimisme. Avant la soumission, confirmez la version et le numéro de buildLa distribution, la signature, les entités, l'installation TestFlight, le test de la mise en ligne sur un appareil vierge, les métadonnées, les URL de confidentialité et de support, les informations de connexion du réviseur, les flux d'achat et la disponibilité du serveur backend. Enregistrez le commit, l'archive, la configuration et les notes de revue ensemble.
Après l'approbation, surveillez les rapports de crash, les erreurs du frontend, les échecs de connexion et les tickets de support. Après la réjection, lisez attentivement le message du Centre de résolution, reproduisez l'exacte erreur, et répondez avec des étapes de navigation concrètes ou soumettez une mise à jour corrigée. Si la réjection semble incorrecte, utilisez les canaux de communication et d'appel d'Apple plutôt que de supposer un travail-around silencieux.
Un workflow d'actualisation en direct peut raccourcir la voie pour les corrections de la couche web éligibles. Les mises à jour OTA de l'App Store avec Capgo décrit le modèl’opérationnel : publiez des bundles signés dans des canaux contrôlés, distribuez à un public sélectionné, surveillez l'adoption et les échecs, et conservez la protection de retrait. Gardez les mises en production étroites, testez les mises à jour à travers un canal de test, et exigez une soumission native chaque fois que la modification affecte la surface native examinée.
La cadence durable est simple : Soumettez les modifications natives avec intention, testez chaque flux promis, et livrez les améliorations de la couche web éligibles à travers un système de mise à jour contrôlée.Ce qui transforme la soumission d'applications iOS en un feu d'artifice récurrent en un processus de mise à jour que l'équipe peut gérer.
Capgo aide les Capacitor à livrer des mises à jour de JavaScript, CSS, copie, configuration et actifs signés à travers des canaux ciblés avec un suivi de déploiement et une protection de rollback, tandis que les modifications natives continuent par l'App Review. Visitez Capgo Pour voir comment vous pouvez ajouter cette voie de mise à jour résiliente aux rejets à votre flux de travail de lancement iOS.
