Apple veut mettre un terme aux apps qui se mettent à jour en dehors de l'App Store
Mickaël Bazoge | | 08:41 | 16Les développeurs qui exploitent des SDK tiers leur permettant de mettre à jour leurs applications en dehors de l’App Store (une pratique dite du « hot code push ») sont prévenus : Apple entend y mettre un terme. C’est le cas par exemple des applications qui utilisent Rollout, un outil qui a cette faculté de pouvoir « pousser » des mises à jour et les installer sans passer par les fourches caudines de l’App Store. Un système qui a ses avantages, notamment quand il faut pousser un correctif rapidement — l’App Store met parfois un temps certain avant d’appuyer sur le bouton vert, bien qu’il existe des procédures spéciales pour accélérer le processus.
Dans une discussion sur le forum Developer d’Apple relayée par 9to5Mac, un développeur a expliqué qu’il devait purger son app du code du SDK « hot code push » avant qu’une mise à jour de son logiciel ne soit approuvée. Un courriel d’Apple explique que ce type de code était en infraction avec plusieurs articles de sa guideline et de son accord de licence.
« Le code [du SDK], combiné avec une ressource distante, peut faciliter des changements significatifs au comportement de votre application par rapport à l’app initialement vérifiée pour l’App Store », précise encore le constructeur. Il est maintenant fort probable qu’à terme, toutes les applications intégrant ce genre de SDK seront concernés. Du côté de Rollout, on temporise : dans un court message, le service indique qu’il regarde le problème, et qu’il en dira plus dès que possible.
Facebook
Twitter
RSS
16 Commentaires Signaler un abus dans les commentaires
Forcement y en qui vont chialer "apple c est fermé par ci, apple les dictateurs par là"!
C'est vrai.
Ça a un avantage : les apps sont un peu mieux contrôlées et vérifiées, moins de risques de télécharger de la merde.
Ça a un désavantage : c'est hyper super méga-chiant de dealer avec l'AppStore et ses lutins. J'ai quitté le développement iOS pour cette raison principale.
@ eastsider
et ton message plein de dédain et vide de contre-arguments prouve à quel point on a raison de le penser...
manquerait plus qu'on pense par nous-même, heureusement qu'apple est là.
Sauf erreur c'est le cas de l'appli HSBC.
Je ne vois pas l'intérêt d'un tel SDK depuis que les délais de validation de l'AppStore tournent aux alentours de 2 jours maintenant.
@Benjo'
Si tu as un bug important en production, deux jours ça reste long.
Ça permet également d'itérer plus rapidement sur le fonctionnement de certaines fonctionnalités.
Enfin, l'utilisateur n'a plus besoin de passer par l'App Store pour mettre à jour son app, ce qui assure que tout le monde utilise une version à jour.
@patchoulol
C'est une fausse excuse car il existe depuis longtemps une validation accélérée pour les cas exceptionnels.
@Benjo'
> Je ne vois pas l'intérêt d'un tel SDK depuis que les délais de validation de
> l'AppStore tournent aux alentours de 2 jours maintenant.
Je ne vois pas comment un délai de validation d l'AppStore réduit à 2j peux vraiment faire un contrôle sérieux sur les risques de sécurité potentiels d'une App.
dans le cas des jeux qui téléchargent les niveaux un peu plus tard, ça se passe comment ? ça vient aussi par le store ?
@jb18v
Ça c'est une possibilité supportée directement par Apple, et oui les niveaux supplémentaires sont donnés à Apple lors de la validation il me semble. Aucun problème de ce côté là.
Ce dont parle l'article c'est plutôt des applications qui changent leur "logique" sans repasser par la case validation. Ceux qui faisaient ça devaient se douter qu'ils étaient dans une zone grise tout en se disant que ça valait le coup.
@iGeek07
J'avais compris mais ça m'a fait penser au cas des jeux :)
Effectivement si une appli vendue comme calendrier se transforme ensuite en client de téléchargement ou autre truc qui ferait tiquer Apple, je comprends 😅
Ça montre toute la complexité du modèle choisi par Apple. Beaucoup d'apps téléchargent du contenu depuis Internet, qu'il s'agisse de niveaux pour un jeu, de vidéos, de texte, ou simplement d'une page web. Tout cela ne modifie pas le code de l'app mais influencent l'usage que les gens en ont.
Or Apple ne se pose pas seulement en rempart contre d'éventuelles infections virales mais aussi contre la pornographie et d'autres types de contenu. Et pour autant, ils ne refusent pas les navigateurs capables d'afficher ces contenus, et ils font preuve de tolérance à l'égard des apps de journaux par exemple. Mais où est vraiment la ligne ? Est-ce qu'une app qui charge une webapp dans une webview ne change pas aussi son comportement ?
Finalement, cette ligne reste floue, sujette à changements en fonction des polémiques sur tel ou tel cas médiatisé. Et surtout, elle est loin d'être superposable à celles de la loi ou de la morale. Au final, elle délimite avant tout les près gardés (financiers) d'Apple qui ne souhaite pas voir certaines apps exister dans le Store.
@PiRMeZuR
Ce que vous dites a du sens, mais ce dont il est sujet dans l'article est principalement au niveau de la "sécurité" : ne pas permettre à une application de changer son code.
Pour ce qui est des pages web, Apple fait de gros efforts pour limiter les dégâts que peut faire du code téléchargé qui s'exécute dans le navigateur ou une web view.
En changeant le code de l'application sans repasser par la validation on peut se mettre à utiliser des frameworks privés par exemple.
Fire Emblem Heroes , le jeu de Nintendo fait pareil non? Quand on avance dans l'aventure on voit parfois un message du genre "de nouvelles données sont disponibles, taille: 150mo (ou moins ou plus) télécharger maintenant ?" Du coup ce contenu téléchargé ne passe pas par l'app store? Je me trompe?
@franfran94800
Il y a une différence entre télécharger des contenus, niveaux, textures, décors, et télécharger un coeur applicatif, des morceaux importants de code qui va s'exécuter hors d'une validation d'Apple.
Le premier peut éventuellement poser un problème de limite d'âge. Le second peut causer des dommages beaucoup plus importants.
Il y a également une grande différence entre du code JavaScript qui tourne dans une WebView contrôlée par Apple, ou du code lua qui s'exécute dans une application vérifiée par Apple et ne peut aller plus loin que l'application de base, et télécharger du code natif qui peut aller toucher à des choses que l'application se base ne touchait pas.
Bref. Je comprends la position d'Apple. Ce n'est pas là qu'il y a un problème avec l'AppStore.
Ah, cela m'étonnait de voir fleurir ce genre d'outils depuis quelques semaines sans qu'Apple ne réagisse.