Ligne directrice Apple 4.2 : Apple rejettera-t-il une application de site Web ? Comment réussir l'examen

Apple peut rejeter une application basée sur un site Web, et la « fonctionnalité minimale » est la raison la plus courante. La ligne directrice 4.2 en est la règle. Une application de site Web n’est pas automatiquement refusée, mais une application qui n’ajoute rien au-delà d’un site Web dans un cadre court un réel risque.

Ce guide explique ce que disent les lignes directrices, ce que les évaluateurs ont tendance à rechercher et comment préparer une soumission. Personne en dehors d’Apple ne peut promettre une approbation, et cet article ne le fait pas. Ce que vous pouvez faire, c'est supprimer les motifs de rejet évitables.

Ce que dit réellement la ligne directrice 4.2

Les directives d'examen des applications indiquent au point 4.2, Fonctionnalité minimale :

Votre application doit inclure des fonctionnalités, du contenu et une interface utilisateur qui l'élèvent au-delà d'un site Web reconditionné. Si votre application n'est pas particulièrement utile, unique ou « semblable à une application », elle n'a pas sa place sur l'App Store.

Les mots qui comptent sont « site Web reconditionné ». La règle n’interdit pas les applications construites autour du contenu Web. Il interdit les applications qui n’offrent rien qu’un site Web ne propose déjà.

Des directives connexes apparaissent également dans les critiques d'applications de sites Web :

• 4.2.2: Hormis les catalogues, les applications ne doivent pas être principalement des supports marketing, des publicités, des coupures Web, des agrégateurs de contenu ou une collection de liens.
• 4.2.3: L'application doit fonctionner seule sans nécessiter l'installation d'une autre application, et elle doit divulguer et inviter tout téléchargement volumineux nécessaire au premier lancement.
• 2.1 (exhaustivité de l'application) : Les soumissions doivent être des versions finales avec des URL fonctionnelles, sans contenu d'espace réservé et les détails du compte de démonstration si l'application dispose d'un identifiant.
• 4.2.6: Les applications créées à partir d'un modèle commercialisé ou d'un service de génération d'applications sont rejetées, sauf si elles sont soumises directement par le fournisseur du contenu de l'application.

Lisez toujours vous-même le texte actuel, car Apple met à jour les directives. La source officielle est le Directives d'examen de l'App Store.

Apple va-t-il rejeter une application de site Web ?

Cela dépend de ce que fait l'application soumise. En pratique, les évaluateurs réagissent à quelques modèles :

• L'application ouvre une seule URL et semble identique au site Web mobile, y compris la navigation de type Web.
• Il affiche uniquement un mur de connexion sans contenu consultable, de sorte que le réviseur ne peut pas voir ce que fait l'application.
• Il se casse ou affiche des erreurs sans connexion.
• Ses liens sautent constamment au navigateur.
• Cela ressemble à une brochure marketing pour une entreprise sans fonction propre.

Une application qui regroupe un service réel, tel qu'un magasin, un système de réservation, un espace membre ou une bibliothèque de contenu, et le présente avec une navigation de type application, se trouve dans une position différente. Vous pouvez toujours être rejeté, puisque la révision est un jugement, mais vous avez quelque chose à souligner.

Pourquoi une application générée par un service a besoin de votre propre compte

La ligne directrice 4.2.6 indique que les applications créées avec un service de génération d'applications sont rejetées à moins qu'elles ne soient soumises directement par le fournisseur du contenu de l'application. Pour un propriétaire de site Web, la lecture pratique est la suivante : publiez sous votre propre compte de développeur Apple, en votre propre nom ou celui de votre entreprise, et assurez-vous que l'application représente votre propre contenu.

C'est également ainsi que fonctionne SiteTo.App. Les builds sont signés avec le compte Apple Developer que vous connectez et la build est livrée à TestFlight dans votre compte App Store Connect. Vous êtes propriétaire de l'annonce et vous la soumettez. Voir le Guide du compte développeur Apple pour la configuration. Ne confiez pas votre contenu à un fournisseur qui soumet le même shell pour de nombreux clients sous son propre compte.

Qu'est-ce qui fait qu'une application de site Web ressemble à une application

Le but n’est pas d’ajouter des fonctionnalités pour le plaisir. Il s’agit d’améliorer l’usage du mobile. Les ajouts forts et honnêtes incluent :

• Navigation native. Une barre d'onglets ou un menu qui correspond à la façon dont les internautes se déplacent sur votre site sur un téléphone, plutôt qu'un en-tête de bureau compressé dans un petit écran.
• Notifications poussées. Messages auxquels les utilisateurs choisissent, tels que les mises à jour de commandes, les rappels de réservation ou le nouveau contenu. Dans SiteTo.App, ceux-ci sont configurés via Firebase ; voir le Guide Firebase.
• Liens profonds. Liens provenant de notifications ou d'e-mails qui ouvrent l'écran de droite dans l'application.
• Une expérience de lancement conçue. Une icône, un écran de démarrage et un état de chargement et d'erreur clair.
• Transferts natifs. Partage, téléchargements de fichiers, accès à la caméra ou téléchargements qui fonctionnent correctement sur l'appareil.

N'ajoutez pas de gadget tel qu'une bascule de lampe de poche. Il ne répond pas à la ligne directrice 4.2 et les évaluateurs y voient clair.

Une liste de contrôle préalable à la soumission

Réalisez ceci avant de télécharger :

1. Testez tout le voyage sur un vrai iPhone. Installez via TestFlight, pas seulement un simulateur. Ouvrez l'application à froid, connectez-vous, parcourez plusieurs niveaux en profondeur et utilisez le geste de retour.
2. Testez sans connexion. Activez le mode avion et ouvrez l'application. Vous devriez voir un message clair, pas une page blanche.
3. Vérifiez chaque lien externe. Décidez volontairement quels liens restent à l'intérieur de l'application et lesquels ouvrent le navigateur.
4. Résoudre les problèmes de mise en page du site Web. Les problèmes de réponse, les petites cibles tactiles et les fenêtres contextuelles réservées au bureau sont évidents dans une application.
5. Supprimez le contenu de l'espace réservé. La ligne directrice 2.1 attend un produit fini avec un support fonctionnel et des URL de confidentialité.
6. Fournissez les informations d’identification de démonstration. Si une connexion est requise, incluez un compte qui continue de fonctionner tout au long de l'examen.
7. Rendre les réponses en matière de confidentialité précises. Ils doivent décrire l'ensemble de l'expérience, y compris les outils d'analyse Web et de paiement chargés dans l'application.
8. Écrivez des captures d'écran honnêtes et une description. Montrez la vraie application et ne revendiquez pas les fonctionnalités qui lui manquent.
9. Utilisez les notes de révision. Expliquez ce que fait l'application, où se trouvent les fonctionnalités natives et les exigences de région ou de compte.

Vous pouvez comparer votre site à plusieurs d'entre eux avec le liste de contrôle de préparation, et notre guide de publication couvre les marches environnantes du magasin.

Comment rédiger des notes de révision qui aident

Les évaluateurs voient de nombreuses soumissions. Une note courte et spécifique les aide à trouver rapidement la valeur. Couverture:

• À quoi sert l'application, en une ou deux phrases.
• Comment se connecter, avec des identifiants de démonstration fonctionnels.
• Où trouver les fonctionnalités natives, par exemple "Les notifications peuvent être activées depuis l'onglet compte".
• Tout ce qui est inhabituel, comme une fonctionnalité nécessitant une région ou un matériel particulier.

Gardez-le factuel. Évitez les arguments sur les lignes directrices lors de la première soumission. Gardez cela pour une réponse si vous êtes rejeté.

Si Apple rejette l'application

Un rejet est une conversation, pas un verdict final. Apple explique les directives qu'il a appliquées dans le Centre de résolution.

1. Lisez attentivement le message. Notez le numéro de ligne directrice et tous les écrans ou comportements spécifiques mentionnés.
2. Résolvez le problème réel. Si la raison est une fonctionnalité minimale, améliorez ce que fait l'application au lieu de reformuler la description.
3. Répondez précisément. Décrivez ce qui a changé et où l'examinateur peut le voir.
4. Soumettez à nouveau une nouvelle version si nécessaire. Une modification du binaire nécessite un nouveau téléchargement.
5. Appel uniquement avec un cas. Si vous pensez que le rejet est une erreur, utilisez la procédure d'appel de l'App Review et citez les faits.

Étant donné qu'une application basée sur un site Web charge votre site, de nombreux correctifs se produisent sur le site Web lui-même et apparaissent dans l'application sans nouvelle version du magasin. Les modifications de configuration natives nécessitent toujours une nouvelle version.

Questions courantes

Une application de site Web doit-elle fonctionner hors ligne ?

Pas en règle générale, mais cela devrait échouer sans problème. Un écran vide sans connexion semble inachevé, ce qui affecte la façon dont les évaluateurs voient l'application.

Une PWA est-elle traitée différemment de tout autre site Web ?

Une PWA dans une application iOS est toujours du contenu Web dans un shell natif, donc la même directive s'applique. Voir comment publier une PWA sur l'App Store et Google Play.

Puis-je soumettre la même application pour plusieurs marques ?

La ligne directrice 4.2.6 restreint les applications créées à partir d’un modèle ou d’un service de génération et soumises au nom de clients. Chaque entreprise doit publier sous son propre compte.

Dois-je payer pour un convertisseur pour être approuvé ?

Aucun outil ne décide du résultat. Apple évalue l'application soumise. Payer pour une construction ne change rien à cela, donc le prix est distinct de l'approbation. Voir prix.

Prochaines étapes

Commencez par tester votre site en tant qu'application. Prévisualisez votre site Web dans SiteTo.App, essayez-le sur votre téléphone et notez ce qui ressemble à un site Web plutôt qu'à une application. Corrigez ces points, puis suivez les créer et publier un guide.