À compter d’iOS 17, macOS Sonoma, tvOS 17 et watchOS 10, une nouvelle règle entre en piste pour les développeurs tiers. Certaines API deviennent en effet qualifiées de « Required Reason ». Lors du processus de révision de l’App Store, il faudra en justifier l’utilisation.
Sur son site, l’entreprise donne la raison de ce changement : « Pour éviter l'utilisation abusive de certaines API qui peuvent être utilisées pour collecter des données sur les appareils des utilisateurs par le biais du fingerprinting, vous devrez déclarer les raisons de l'utilisation de ces API dans le manifeste de confidentialité de votre application. Cela permettra de s'assurer que les applications n'utilisent ces API que dans le but pour lequel elles ont été conçues ».
Les développeurs doivent ainsi se préparer à recevoir des emails, certaines API courantes étant qualifiées de « Required Reason », comme UserDefaults. Selon certains développeurs ayant discuté avec 9to5mac, cette API est souvent utilisée pour stocker les préférences des utilisateurs. Il pourrait donc y avoir plus de rejets lors du processus de révision.
Commentaires (8)
#1
En gros, ca empêchera de mettre à jour ou déclarer une nouvelle app sur le store qui utilise ses APIs sans le justifier dans 1 an, c’est bien ça ?
Comme à chaque fois (avec Google Play par exemple), ça met un temps fou à voir les bénéfices de ce genre de changements 😞
#2
Enfin !
Nous n’aurons pas de retour de l’iNpact d’un tel changement, mais c’est bien que cela bouge.
Nos politiques ne sont pas capables d’avances sur ces points.
#3
En fait il faut regarder la cause des causes.
Apple ne le fait pas pour le fun ou la noblesse d’un esprit partageur et emprunt de just…. bref..
S’il le font c’est pour se couvrir. Ça leur évite un engagement de leur responsabilité en cas de casse. Ça leur évite donc de perfectionner le système globalement (ex: meilleur ban d’une app). Le système étant devenu pachydermique il est difficile de le modifier sans qu’il y a ait de la grogne ou de la casse.
C’est une vision court-termiste.
#3.1
Est-ce que tu peux préciser en quoi c’est une vision court termiste ?
Je ne vois pas en quoi le fait de demander a des dev de justifier l’utilisation des résultats (et donc d’api) est une vision court termiste, d’autant plus du point de vue européen avec le RGPD.
Il en va de même du point de vue sécurité des informations, dans le cas où un “bug” est découvert, ça permet aussi de connaitre l’étendue des dégats, et de prévenir spécifiquement les utilisateurs concernés.
Ce qui correspond plutôt à une vision long termes à mon sens.
Après, que ce soit pour des problématiques juridiques dans tel ou tel Etat, c’est autre chose.
Mais, en revanche, vu que le type RGPD à fait des émules un peut partotu dans le monde, c’est assez logique qu’Apple (et dans quelques mois/années Google) y aille.
Encore des devs qui pensent que tout change autour d’eux mais qu’ils sont le centre du monde ?
Que soit sur iOS ou n’importe quel système (Unix, Linux, Windows, …) des patchs managements peuvent régulièrement changer le comportement du système envers des appli.
C’est pas nouveau, j’y étais déjà confronté y’a 15 ans sur des systèmes Linux Entreprise (RHEL et SLES) en production.
Que les dev juniors pensent que le maintient du code ça sert à rien parce que leur code est parfait et que ça les fasses chier de devoir s’y replonger tous les 3 mois parce qu’ “ils ont autre chose à faire” c’est pas nouveau mais c’est pas la réalité des choses.
Je vois trop de devs penser qu’ils sont les maitres du monde et qu’on ne peut pas les comprendre parce que nous ne sommes que des gueux et qu’ils ont la toute puissance de la connaissance du code.
Le must c’est les “dev full stack”, y’ a 15 ans, c’était juste des devs qui pissent du code (qu’ils soient bon ou pas).
Et ils se retrouver comme des nuls lors de la mise en prod “ah bah ça marche pas, pourtant en Dev ou stagging ça marche”. Le plus drole c’est quand les gueux dans mon genre leur disent où est leur boulette sans avoir vu le code
[mylife]
J’ai arrêté de dev (petits devs pour de la gestion de prod) y’a un paquet d’année, et en prime je faisais également de l’admin Sys et SGBD (oui, job bien complet c’était fun, pas d’ennuie pendant quelques années).
[/mylife]
#3.2
Bin rien n’empêche de déclarer ce qu’on veut. Il ne faut pas 5 minutes pour que l’on trouve la bonne phrase qui passe bien. Donc on s’appuie sur les déclarations de X et donc engageant sa responsabilité (plus ou moins). Ce qui couvre Apple. “Désolé Mr le juge le gars avait promis… , pas ma faute”.
Le principe d’Apple ce de ne rien faire sans y être obligé soit par la loi, soit par le scandale. Et même la c’est discutable.
Ex le programme d’affiliation pour le “right to repair”. Un certain Louis Rossman (de YouTube) électronicien de métier collectionne une bonne tripoté de vidéos sur le sujet.
En fait il faut se mettre dans les pompes des dirigeants Apple (ou autre Gafam). La magnitude des amendes est plus grosse que pour les autres. Ceci explique cela.
#4
Dans le principe je trouve bien de justifier l’utilisation de fonctionnalités qui peuvent poser souci sur le respect de la vie privée, mais dans les faits je crains que ça soit aussi flou que “l’intérêt légitime” des cookies banners dont la question se pose au niveau du curseur de l’intérêt de qui (le RGPD lui est clair sur ce point).
#5
Lors de la sortie de… Mac OSX Lion (j’étais encore sous SL avec mon Hackintosh), j’avais eu une discussion disons… un peu animée avec un développeur pro, lui disant que selon moi l’app store est une prison dont les barreaux vont peu à peu se resserrer de plus en plus autour du cou des représentants de son espèce…
C’est ce qui s’appelle créer un environnement de plus en plus captif, et ça a toujours été la politique maison.
Résultat : le dev en question a démissionné après un burn out (il faut dire que son appli dépends étroitement d’une appli système, qui par définition change (…évolue ? mouais…) tout le temps, à chaque tout petit changement de version de l’OS.
Et donc le gars devait mouliner dans la choucroute jusqu’à épuisement pour s’adapter aux changements constants de la chose, il y avait donc pratiquement une nouvelle version de son appli à chaque mise à jour, même mineure, de l’OS.
Ajoutez en plus les nouvelles règles de plus en plus contraignantes de l’app store… n’en jetez plus, rideau, turn over. Le fait est que le vendeur de ce logiciel, depuis cette conversation, a changé de dev à peu près autant de fois qu’il a changé de chemise.
Je le sais parce qu’il y en a toujours qu’un(e) qui répond dans le forum, mais que cette personne a changé tellement de fois que j’ai perdu le compte.
#6
L’exemple que je t’ai donné plus haut, c’est une boite qui dépends à 1000% du Finder, le gestionnaire de fichiers du mac, autrement dit le centre névralgique de macOS, qui par définition change tout le temps, mais sans jamais (ou rarement, et jamais en avance) annoncer la couleur…
Le Finder est un blob chiffré (eh oui, l’application elle-même est chiffrée, elle fait même l’affront de ne quasi-jamais avoir à se déchiffrer en mémoire) dont personne d’autre qu’Apple ne peut vraiment savoir ce qu’il fait en sous-marin.
Mais ce n’est pas le vrai problème pour l’utilisateur final que je suis. Le vrai problème, pour un dev, c’est de dépendre d’un tel amas de code indéchiffrable et d’une firme capricieuse qui peut tout bouleverser du jour au lendemain…