Guidelines App Store : pas de Face ID pour les enfants, dons entre particuliers, avertissement aux autorités…

Stéphane Moussie |

Apple a prévenu les développeurs qu’elle avait actualisé les règles de validation de l’App Store, mais elle ne précise malheureusement toujours pas quels sont les changements. Il faut donc comparer méthodiquement la nouvelle version avec l’ancienne, consultable sur Archive.org — le très pratique Guidelines History n’a pas encore été mis à jour avec les nouvelles règles.

App Store sur iOS 11

Il y a comme souvent des reformulations et des précisions, mais aussi des changements plus significatifs. L’article 4.7 « Third-Party Software » a été renommé « HTML5 Games, Bots, etc. », et Apple ajoute que les apps qui contiennent ou utilisent du code provenant d’une source externe sont autorisées tant que « la distribution de code n’est pas la finalité principale de l’application ».

Dans la règle 2.3.1, qui concerne la fidélité des descriptions des apps, Cupertino ajoute qu’il ne faut pas présenter une app en mentionnant un service ou un contenu qu’elle n’inclut pas. Et de prendre l’exemple précis des antivirus iOS. On s’attend donc à un gros coup de balais des faux logiciels de sécurité sur iOS.

Apple a ajouté un nouvel article 2.5.13 concernant Face ID :

Les apps utilisant la reconnaissance faciale pour l’authentification de compte doivent utiliser LocalAuthentication (et non ARKit ou une autre technologie de reconnaissance faciale), et doivent utiliser une autre méthode d’authentification pour les utilisateurs de moins de 13 ans.

Afin de respecter des textes de loi, les applications destinées aux enfants ont le droit de demander l’âge de l’utilisateur. C’est sûrement à partir de cette information que les développeurs devront désactiver Face ID pour les utilisateurs de moins de 13 ans dans leurs apps. Cette restriction s’applique uniquement à Face ID, Touch ID n’est pas concerné.

Autre ajout, la règle 3.2.1 (vii) :

Les apps peuvent permettre aux particuliers d’envoyer des dons d’argent aux autres particuliers sans passer par le système d’achat in-app, à condition que (a) le don soit un choix complètement optionnel pour le donateur, (b) 100 % de l’argent aille au donataire. Cependant, un don qui est connecté ou associé à n’importe quel moment avec l’obtention de contenu ou de services doit utiliser le système d’achat in-app.

Ce nouvel article s’inscrit probablement dans le cadre de l'arrivée du paiement de personne à personne d'Apple Pay aux États-Unis et/ou du bras de fer entre Apple et de gros éditeurs chinois. Ceux-ci permettent à leurs utilisateurs de les rétribuer grâce à des « pourboires », évitant ainsi la commission d’Apple. L’article semble aller à leur encontre : seuls les dons de particulier à particulier sont autorisés, et les dons permettant d’accéder à du contenu en plus sont explicitement interdits.

La règle 4.4 concernant les extensions a été revue. Auparavant, seuls les claviers de tierce partie n’avaient pas le droit d’inclure du matériel marketing, de la publicité ou des achats in-app. Dorénavant, ce sont toutes les extensions (autocollants, extensions Safari…) qui n’ont pas le droit d’inclure ces éléments.

Or, les autocollants Super Mario Run ne sont-ils pas du marketing pour le jeu de Nintendo ? On ne s’attend pas à ce qu’Apple fasse une application aussi stricte de la nouvelle règle, mais elle mériterait peut-être une réécriture pour éviter de mauvaises interprétations.

Dans la partie juridique (grand 5), Apple a ajouté que « dans des cas extrêmes, comme les apps qui encouragent le trafic humain et/ou l’exploitation des enfants, les autorités compétentes seront informées. » Les éditeurs de ce type d’apps sont prévenus.

Enfin, mentionnons que le controversé article 4.2.6 qui avait été instauré après la WWDC n’a pas été modifié. Utilisé par Apple pour retirer des apps « pas particulièrement utiles », cet article indique précisément que « les apps créées par des services vendant des modèles tout prêts ou qui se proposent de les générer eux-mêmes sont rejetées ». Cette nouvelle règle est critiquée par les services en question, ainsi que par leurs utilisateurs, qui sont donc interdits d’App Store.

avatar JimmyDrn | 

Je voudrais revenir sur l'écran super Retina de l'iPhone x car manque de précision.
On sait que là valeurs de luminosité est de 600 candelas, Samsung fais du 1000... (différence en plein soleil?)
On ne sait pas la fréquence de rafraîchissement (tjrs bloqué à 60 hz ?...bof non?)
Il gère le HDR 10 et le dolby vision, Samsung se contente du HDR 10 seulement...
Un article dédié svp!!
Merci

avatar niicoo76 | 

@jimmy92250

?

avatar DG33 | 

@jimmy92250

Dès la livraison d'unités de test et la levée des clauses de confidentialité un laboratoire spécialisé présentera le classement mondial des écrans de smartphones.
(Et des Youtubeurs les passeront au mixeur, les jetteront par terre, les mettront au micro-ondes, le perceront, les brûleront, les mitrailleront etc pour notre plus grand(e) plaisir stupéfaction désolation)

avatar JimmyDrn | 

@DG33

Coool! Je suis pressé! Mais bon ce qui m'inquiétait le plus c'était le taux de rafraîchissement à 60hz, mais pour un petit écran je ne pense pas que cela soit gênant... de plus la technologie embarquée est tout à fait capable, si il a été bridés c'est sûrement software pour éviter de tiré sur les ressource du GPU et l'autonomie.
En tout cas cet écran s'annonce parfait hormis peut être la luminosité à 600 candelas... toujours le même problème l'été, avec le soleil on ne voit rien! Il aurait pu monter à 1000 comme Samsung au moins. Mais de toute façon cela reste insuffisant, en regardant les spécifications d'écran extérieur pro j'ai pu me rendre compte que pour une lecture facile en plein soleil faut monter minimum à 7000 candelas ?
Donc on ne verra jamais bien au soleil ?

avatar C1rc3@0rc | 

«Les apps utilisant la reconnaissance faciale pour l’authentification de compte doivent utiliser LocalAuthentication (et non ARKit ou une autre technologie de reconnaissance faciale), et doivent utiliser une autre méthode d’authentification pour les utilisateurs de moins de 13 ans.»

Le Fake ID ne concerne que l'iPhone 10, une machine a plus de $1000, ça ne marche (pas?) que pour une seule personne. Donc on a une machine qui va etre ultra marginale, et considerer que des possesseur d'iPhone 10 de moins de 13, c'est meme plus parler d'une niche ultra restreinte, c'est parler d'une données qui sera invisible et sans impact.
Bon apres, le Fake ID se généralisera peut etre en plus des Touch ID et code d’identification dans les 3 a 4 ans a venir, donc Apple prend les devant, mais pour l’année a venir, j'imagine pas qu'un developpeur ait la moindre intention de developper quoi que ce soit de specifique pour l'iPhone 10...

avatar charliedeux | 

15/09/2017 - 01:03
Autant je ne trouve pas FaceID révolutionnaire pour un sous (ne change en aucun cas l'usage qu'on fait du smartphone), autant faut garder la tête sur les épaules: tu ne mets pas une machine à 1100euros dans mains d'un gosse de 12ans pour qu'il joue à pokémon. L'iPhone X c'est pas la dernière nintendo DS donc je ne voit pas en quoi cela sera important, d'autant plus que la restriction est légale.

avatar charliedeux | 

.

avatar MLV | 

Les apps qui prennent en charge Touch ID prendront en charge automatiquement Face ID ou faudra recoder et sortir une nouvelle maj ? Si c'est ça, RDV en 2020 pour la BNP...

avatar badsean | 

@MLV

Il me semble avoir lu que c'était la même API donc normalement pas de nécessité de recoder...
J'espère avoir bien compris car étant utilisateur de l'app de BNP, ça m'embêterait de revenir en arrière ( sur une fonction qui est apparu il y a seulement quelques mois^^ ).

avatar C1rc3@0rc | 

C'est ecrit dans l'article:

«Les apps utilisant la reconnaissance faciale pour l’authentification de compte doivent utiliser LocalAuthentication (et non ARKit ou une autre technologie de reconnaissance faciale), et doivent utiliser une autre méthode d’authentification pour les utilisateurs de moins de 13 ans.»

Le texte est clair, si le developpeur doit donner le choix de l'authentification c'est que le developpeur doit donc coder spécifiquement l'app pour l'authentification visuelle, mais ne doit le faire qu'avec l'API LocalAuthentication qui garantie a l'utilisateur que ni le developpeur, ni Apple n'enregistreront les donnees biometrique de sa tete et qu'elles ne quitteront pas le smartphone (enfin c'est ce que promet Apple)...

Apres, Apple peut decider que LocalAuthentication devienne un service qui donne le choix du mode d'authentification a l'utilisateur et le dev n'est que comme info que l'authentification a ete faite, sans savoir quel moyen a ete utilisé... Le jour ou ce sera le cas, la clause en question n'aura plus lieu d'etre.

avatar Remundo3869 | 

@C1rc3@0rc

Justement il a été expliqué pendant la présentation ou pendant les démos, je ne me souviens plus de quand exactement. Que le développeur n'a rien à faire si il supporte déjà TouchId.

L'API LocalAuthenticator se charge d'appeler Touch ID ou Face ID selon l'appareil.

La question de l'âge sera sûrement gérée en fonction de l'âge de l'identifiant Apple. Apres pour rentrer dans les clous certaines applis qui possèdent l'information de l'âge de l'utilisateur devront peut être gérer le cas spécifique où il faut désactiver la fonction pour les moins de 13 ans.

avatar iPop | 

Moi c'est la dernière restriction à propos des modèles que je n'ai pas vraiment comprise.

avatar vlsf1 | 

"Les apps utilisant la reconnaissance faciale pour l’authentification de compte doivent utiliser LocalAuthentication (et non ARKit ou une autre technologie de reconnaissance faciale), et doivent utiliser une autre méthode d’authentification pour les utilisateurs de moins de 13 ans"

Le LocalAuthentication, je pense que c'est pour que les applications qui utilisent Touch ID (comme celles des bangues pour le login par exemple) basculent automatiquement sur Face ID.

Jusqu'à l'iPhone 8, LocalAuthentication c'est Touch ID, sur l'iPhone X, c'est Face ID.

CONNEXION UTILISATEUR