App Store : Apple supprime les anciennes applications, les développeurs grognent

App Store : Apple supprime les anciennes applications, les développeurs grognent

Le printemps ? Osef

Avatar de l'auteur
Vincent Hermann

Publié dans

Société numérique

03/05/2022 10 minutes
34

App Store : Apple supprime les anciennes applications, les développeurs grognent

L’entreprise s’est lancée dans un radical ménage de printemps. Les développeurs en sont parfois pour leurs frais, face à des règles fortes et souvent appliquées de manière aveugle. Apple a fini par s’en expliquer, offrant du temps pour s’adapter. Mais le temps n’est pas la principale contrainte.

Les grandes entreprises possédant des boutiques y règnent presque en maîtres. Elles en fixent les règles et sont censées garantir à la fois la sécurité des utilisateurs et un terrain de jeu équitable pour les développeurs.

La bonne tenue d’une boutique est complexe, mais les récompenses sont à l’avenant. Le nombre d’applications attire les clients, qui en échange achètent les appareils permettant d’en profiter, augmentant l’attraction de la plateforme et donc plus de développeurs. Un cercle vertueux qu’ont réussi à mettre en place Apple et Google surtout. On se rappelle les déboires de Microsoft dans ce domaine, avec un Windows Phone finalement abandonné, alors qu’il disposait de qualités certaines.

Il existe cependant une différence entre l’App Store d’Apple et le Play Store de Google : les règles sont non seulement nombreuses, mais également plus strictes chez le premier. On ne peut en particulier pas y laisser une application sans aucune nouveauté pendant des années.

Apple s’est donc lancée la semaine dernière dans un grand ménage de printemps sur sa boutique, des applications disparaissant du jour au lendemain. Point commun : elles n’avaient reçu aucune mise à jour depuis plusieurs années. Comme on va le voir, l’écart peut être très variable.

Des développeurs sommés de proposer de nouvelles versions

Que des règles imposent de rafraîchir de temps en temps un vieux code pourrait sembler naturel. Après tout, Apple a beau mettre régulièrement à l’honneur des applications dans sa boutique ou pendant ses conférences, l’entreprise est avant tout intéressée par l’image qu’elle renvoie en toute circonstance.

On trouve facilement sur Twitter des messages de développeurs dans l’incompréhension après réception d’une « App Improvement Notice ». Dans celle-ci, Apple résume la situation : le code de l’application n’a pas bougé depuis plusieurs années, il faut le mettre à jour. Mais « Comment ? », demandent certains, et surtout « Pourquoi ? ».

La mesure semble affecter particulièrement les auteurs de jeux. Le 23 avril, Robert Kabwe, créateur du jeu indépendant Motivoto, indiquait sur Twitter qu’Apple prévoyait de supprimer son jeu si aucune mise à jour n’était faite rapidement. Raison invoquée : la dernière remontait à plus de deux ans. Kabwe a 30 jours pour remédier à la situation.

Simon Barker, un autre développeur, lui répond : « J’ai reçu un email ce matin indiquant la même chose pour une de mes applications. Elle n’a eu aucun rapport de plantage, a toujours des téléchargements après cinq ans, n’a pas besoin d’une v2 et Apple décide qu’il faut s’en aller. À cause des changements entre les versions de Swift, je n’ai pas le temps d’envoyer une évolution significative ».

Même chose chez Kosta Eleftheriou : « Apple a également retiré une version de mon FlickType Keyboard spécifiquement organisée pour la communauté malvoyante, parce que je ne l’avais pas mise à jour en deux ans. Pendant ce temps, des jeux comme Pocket God n’ont pas été mis à jour par leurs développeurs depuis 7 ans ». Dans un autre tweet, il fait remarquer que même certaines applications d’Apple sont plus anciennes que la sienne, comme iTunes Movie Trailers, dont la dernière version a plus de quatre ans. Citons aussi AirPort Utility et Beats Pill+.

Toujours sur Twitter, Emilia Lazer-Walker peste elle aussi, plusieurs de ses jeux étant en passe d’être supprimés. Comme elle l’explique cependant, « les jeux peuvent exister en tant qu’objets finis ! ». En d’autres termes, un jeu dont le développement est considéré comme terminé n’a pas de raison d’être mis à jour, particulièrement quand ce sont des titres gratuits. « Microsoft fait l’effort de vous laisser exécuter des applications Win95 vieilles de 30 ans sur des appareils Windows on ARM. C’est une décision politique, pas technique ».

Dura lex, sed lex

Devant une situation plus tendue sans doute qu’imaginé, Apple est sortie de son habituelle réserve. Dans un message publié vendredi soir, l’entreprise rappelle qu’en 2016, un effort particulier avait été fait pour promouvoir les applications de qualité. Un processus constant de révision, nommé App Store Improvements, était alors mis en place pour vérifier que les applications restaient dans les clous. On imagine le plaisir d’Apple à le préciser : le processus a été créé « à la demande des développeurs ».

Pour résumer, il s’agissait d’écarter de l’App Store les applications qui ne fonctionnaient plus comme elles le devaient, ne suivaient plus les règles de révision ou étaient obsolètes. En six ans, ce ne sont pas moins de 2,8 millions d’applications qui ont été ainsi supprimées.

« Dans le cadre du processus App Store Improvements, les développeurs d’applications n’ayant pas été mises à jour au cours des trois dernières années et ne parvenant pas à atteindre un palier minimal de téléchargements – signifiant que l’application n’a pas été du tout téléchargée ou extrêmement peu sur les 12 derniers mois – reçoivent un email les notifiant que leur application a été identifiée pour un possible retrait de l’App Store », explique Apple.

Mais la firme a beau se tenir droite dans ses bottes et rappeler que le processus était initialement une idée de la communauté des développeurs tiers, elle tente quand même l’apaisement. Elle rappelle que l’on peut faire appel de cette décision. En outre, le temps laissé pour apporter les modifications nécessaires passe de 30 à 90 jours.

Point important, les applications qui disparaissent de cette manière de l’App Store ne sont pas supprimées des appareils où elles sont installées. Une fois qu’elles ont été téléchargées, qu’elles soient gratuites ou payantes, l’utilisateur en possède une licence d’utilisation. Les personnes concernées pourront les retélécharger en cas de besoin.

Les développeurs veulent plus d’informations

Les développeurs concernés insistent tous sur un point : il est idiot de réclamer une mise à jour dans le simple but de mettre à jour. Avec le temps, ils passent à d’autres applications ou projets. Intimer l’ordre d’apporter des changements au bout de plusieurs années est donc complexe, surtout en ne laissant (initialement) qu’un mois. Plusieurs années représentent une éternité en informatique, les environnements de développement, les langages et technologies évoluent vite.

Robert Kabwe, dans une autre série de tweets, a ainsi indiqué qu’une personne de chez Apple l’avait contacté après son message initial. Il a pu échanger et a manifestement profité de l’occasion pour faire quelques suggestions : « Supprimer des jeux ne devrait être fait que pour de bonnes raisons, qui ont besoin d’être communiquées clairement, spécifiquement et longtemps à l’avance ».

Il prend pour exemple la grande migration des applications vers le 64 bits, quand Apple a abandonné le 32 bits, d’abord sur iOS puis macOS. La grande « purge » avait des raisons techniques claires, avait été annoncée longtemps à l’avance et « s’était appliquée équitablement à tous les développeurs ».

Ses recommandations à Apple ne s’arrêtent pas là. Il aimerait par exemple des dates de retrait cohérentes entre applications. Une bonne idée : la possibilité de revenir à la version précédente de l’application. Cette capacité serait sans doute complexe à mettre en place, notamment pour les applications servant de clients pour des services actifs, par exemple un jeu joué exclusivement en ligne. Il apprécierait en outre de pouvoir viser des appareils spécifiques et plus simplement des versions d’iOS. Il juge ces dernières trop vagues, notamment parce qu’elles sont compatibles avec de nombreux appareils. Pouvoir cibler des appareils précis permettrait selon lui de garantir une expérience cohérente.

Surtout, il rappelle que forcer des développeurs à mettre à jour leurs applications plusieurs années après la dernière version provoque une cascade d’autres obligations. Si la personne concernée n’a plus publié sur l’App Store, elle va devoir recompiler la nouvelle version avec le dernier Xcode, dont la version 13 réclame macOS Big Sur. Ce dernier ayant fait l’impasse sur d’anciens Mac, il faudra peut-être racheter du matériel plus récent.

En outre, les applications sont le plus souvent constituées de plusieurs briques, y compris les jeux. Si l’on prend le dernier Xcode sur Big Sur, il faudra par exemple une version récente d’Unity. Pour chaque montée en version d’une brique, les développeurs doivent vérifier les fonctions dépréciées, les API supprimées, les incompatibilités en tout genre et, globalement, que le jeu fonctionne encore bien dans tous les scénarios.

Un grand ménage en préparation chez Google aussi

Que l’on se « rassure » : Apple n’est pas la seule entreprise à vouloir faire du ménage. Google prépare également de son côté une opération coup de poing, qui devrait entrainer encore plus de conséquences sur le Play Store, où les règles étaient jusqu’à présent moins strictes.

Comme annoncé sur l’un de ses blogs le 6 avril, Google compte imposer aux développeurs une nouvelle aussi simple que radicale : toute application sur la boutique doit viser un niveau d’API Android sorti au cours des deux dernières années. Selon Google, il s’agit de mettre tout le monde à la page sur les mesures de sécurité qui, il est vrai, se sont renforcées au cours des dernières années.

Actuellement, la règle doit entrer en vigueur le 1er novembre. Elle viendra compléter l’actuelle sur les nouvelles applications et mises à jour, qui exigent un niveau d’API n’excédant pas un an.

Selon l’entreprise, la « vaste majorité » des 2,87 millions d’applications sur le Play Store est déjà compatible avec cette future obligation. Google promet d’avertir les développeurs à l’avance et de les aider avec les ressources nécessaires.

Même si Google prévient six mois avant l’application de cette règle, il est probable que de nombreuses applications quittent le Play Store. Il s’agira d’un roulement permanent, donc d’une purge étalée dans le temps. Sur Android toutefois, le problème est moindre pour les développeurs, qui peuvent se tourner vers d’autres boutiques ou même proposer les APK sur leurs propres sites.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Des développeurs sommés de proposer de nouvelles versions

Dura lex, sed lex

Les développeurs veulent plus d’informations

Un grand ménage en préparation chez Google aussi

Fermer

Commentaires (34)


:mdr2:


Ah, les marchés captifs, ça me fera toujours rigoler.


Au sujet de Google, si je comprends bien, le Play Store n’aura plus que des applications nécessitant un niveau d’API récent.



Là, je vois bien l’Europe se pencher là dessus, car bonjour l’obsolescence programmé des terminaux qui ne sont plus maintenus à jour : il deviendra impossible d’y installer la moindre application via le Play Store, tout en tuant une bonne partie du reconditionné pour smartphone.



Même s’il y a des alternatives (store alternatif, installation en direct des APK) c’est un très mauvais signal qui est envoyé pour la durée de vie de nos appareils.


Cela n’entre pas dans la définition de l’obsolescence programmé. Cela complique un peu l’installation des applications mais n’empêche pas leur bon fonctionnement (sauf ben sûr les applications qui vont demander des versions récentes).



Pour que cela puisse être considéré comme de l’obsolescence programmé, il faudrait que l’appareil deviennent totalement inutilisable, ce qui n’est pas le cas ici. Mais aussi prouver que cela est fait intentionnellement pour forcer l’utilisateur à en racheter un et c’est plus compliqué.



En revanche on pourrait se plaindre du monopole de Play store et de la trop grande dépendance du système vis à vis de cette boutique.


RedShader

Cela n’entre pas dans la définition de l’obsolescence programmé. Cela complique un peu l’installation des applications mais n’empêche pas leur bon fonctionnement (sauf ben sûr les applications qui vont demander des versions récentes).



Pour que cela puisse être considéré comme de l’obsolescence programmé, il faudrait que l’appareil deviennent totalement inutilisable, ce qui n’est pas le cas ici. Mais aussi prouver que cela est fait intentionnellement pour forcer l’utilisateur à en racheter un et c’est plus compliqué.



En revanche on pourrait se plaindre du monopole de Play store et de la trop grande dépendance du système vis à vis de cette boutique.


C’est effectivement la définition “initiale”. Elle est beaucoup plus étendue aujourd’hui, et ne plus pouvoir jouir pleinement de son téléphone est considérée comme de l’obsolescence programmée.



Il suffit de prendre le cas d’Apple qui s’est justement pris des attaques (réglées à l’amiable pour éviter le procès !) à ce sujet suite aux ralentissements des iPhone 6 et 7 à cause d’une mise à jour par exemple.



Si installer des applications sera toujours possible, cela signifie aussi installer depuis des sources non sûr, avec tous les soucis que cela peut provoquer.



Si le public de NextINpact pourra très certainement installer des applications (nous sommes un public d’avertis), cela ne sera pas le cas pour beaucoup, qui ne connaissent même pas l’existence de moyens alternatifs. Ne pouvant plus installer d’applications, ils seront donc incités à changer de téléphone.



En bref, si ce n’est pas une obsolescence programmée absolue, cela n’en représente pas moins un frein énorme pour beaucoup.



Là où l’histoire se complique, c’est que le vendeur du terminal n’est pas forcément l’éditeur d’Android. Mais Google vend aussi des terminaux donc peut éventuellement se voir attaquer pour obsolescence à cause de cela.



Par contre, un nième abus de position dominante reste lui tout à fait possible.


Je n’avais pas compris ça pour le play store. Pour moi ils s’agissaient du compatibilité montante des applications, les développeurs pouvant conserver une appli descendante pour les utilisateurs. Je me trompe ?


wanou2

Je n’avais pas compris ça pour le play store. Pour moi ils s’agissaient du compatibilité montante des applications, les développeurs pouvant conserver une appli descendante pour les utilisateurs. Je me trompe ?


Sur le Play Store, les applications doivent être compilées contre une version récente du SDK (v31 actuellement au niveau du paramètre compileSdkVersion du build.gradle), mais peuvent être distribuées et installées sur des systèmes plus anciens (paramètre minSdkVersion du build.gradle. Je déploie sur du SDK 21 actuellement, c’est-à-dire Android 5.0).




  • Le compileSdkVersion définit le niveau de fonctionnalité du SDK auquel l’application peut faire appel.

  • Le targetSdkVersion définit le niveau du SDK contre lequel l’application doit être testée (souvent égal au compileSdkVersion).

  • Le minSdkVersion définit le niveau minimum du système Android en capacité d’accepter de faire fonctionner l’application (peut-être sans quelques fonctionnalités avancées).



Souvent, le système Android permet de faire tourner de nouvelles applications sur d’anciens systèmes via des couches de ‘compatibilité’ qui apportent les nouvelles fonctionnalités sur les anciens systèmes.



Voir https://developer.android.com/studio/build



Les développeurs concernés insistent tous sur un point : il est idiot de réclamer une mise à jour dans le simple but de mettre à jour.




Incrémenter une version “à blanc”, ça marche ? :francais:



fdorin a dit:


Là, je vois bien l’Europe se pencher là dessus, car bonjour l’obsolescence programmé des terminaux qui ne sont plus maintenus à jour : il deviendra impossible d’y installer la moindre application via le Play Store, tout en tuant une bonne partie du reconditionné pour smartphone.



Même s’il y a des alternatives (store alternatif, installation en direct des APK) c’est un très mauvais signal qui est envoyé pour la durée de vie de nos appareils.




Gros +1




Si la personne concernée n’a plus publié sur l’App Store, elle va devoir recompiler la nouvelle version avec le dernier Xcode, dont la version 13 réclame macOS Big Sur. Ce dernier ayant fait l’impasse sur d’anciens Mac, il faudra peut-être racheter du matériel plus récent.




:mdr: :mdr: :mdr: :mdr:


Pa simple comme histoire.
Je comprends très bien l’envie d’Apple de virer les applications qui ne sont plus mise à jour depuis des années.
Mais je comprends également le point de vue de certains développeurs, comme pour les jeux dont je ne vois pas bien l’intérêt de proposer une MAJ.
Ce qui me dérange le plus, c’est par exemple sur mon iPad mini 6 que j’ai depuis 6 mois, encore plein d’applications ne sont pas mise à jour pour supporter le nouveau format de l’écran 😏


Et donc dans ce cas l’approche d’Apple est peut être légitime ? Les nouvelles versions c’est pas seulement corriger les bugs mais aussi optimiser les applications pour les nouveaux devices



Mais « Comment ? », demandent certains, et surtout « Pourquoi ? ».




C’est bien pour cela que j’ai lâché le développement d’application pour une très grande plateforme. Du jours au lendemain ils poussent les clients à installer une nouvelle version alors que de l’autre côté zéro documentation et naturellement plus l’application est complexe, plus la mise à jours est complexe.




fdorin a dit:


Là, je vois bien l’Europe se pencher là dessus, car bonjour l’obsolescence programmé des terminaux qui ne sont plus maintenus à jour : il deviendra impossible d’y installer la moindre application via le Play Store, tout en tuant une bonne partie du reconditionné pour smartphone.




Surtout que les mecs n’hésitent pas de l’autre côté à te pomper 30% de tes revenus.


Et le pire, c’est qu’il n’y a même pas besoin d’aller chez les GAFAM pour constater le comportement sadique des plateformes.
On a vu le marketplace de Firefox OS, qui regorgeait d’applis HTML5 riches et bien foutues, fermé du jour au lendemain, alors que pour mozilla, ce n’était qu’un simple serveur web à entretenir, et que ces programmes auraient pu être reconduits sur d’autres plateformes.
On ne parlera pas mon plus de github devenu du jour au lendemain la propriété de notre cher grand ami microsoft, alors que nombre de devs libres faisaient précisément confiance à la neutralité de l’outil.
Comme disait l’autre : trust no one !


N’importe quoi. GitHub n’a jamais été « neutre ». GitHub a toujours été une entreprise agissant dans pour propre intérêt, à savoir maximiser son profit. Et depuis qu’ils se sont fait racheter, c’est devenu une entreprise agissant dans son propre intérêt, à savoir maximiser son profit.



En gros rien n’a changé. Et j’ai pas de problème avec GitHub, mais c’est et ça a toujours été une entreprise, pas une sorte de représentant du « camp du bien » passé sous le contrôle du « malin » Microsoft. La vie est beaucoup plus ennuyeuse que ça, ça n’a toujours été que « comment faire de l’argent ».



Rien de mal à ça, ça peut même amener les entreprises à faire de bonnes choses, et leurs employés à défendre de vraies idéologies… mais ce n’est qu’un effet secondaire, pas une fin en soi.


jpaul

N’importe quoi. GitHub n’a jamais été « neutre ». GitHub a toujours été une entreprise agissant dans pour propre intérêt, à savoir maximiser son profit. Et depuis qu’ils se sont fait racheter, c’est devenu une entreprise agissant dans son propre intérêt, à savoir maximiser son profit.



En gros rien n’a changé. Et j’ai pas de problème avec GitHub, mais c’est et ça a toujours été une entreprise, pas une sorte de représentant du « camp du bien » passé sous le contrôle du « malin » Microsoft. La vie est beaucoup plus ennuyeuse que ça, ça n’a toujours été que « comment faire de l’argent ».



Rien de mal à ça, ça peut même amener les entreprises à faire de bonnes choses, et leurs employés à défendre de vraies idéologies… mais ce n’est qu’un effet secondaire, pas une fin en soi.


Si rien n’avait changé, gitlab n’aurait pas le succès qu’on lui connaît aujourd’hui…
Beaucoup de devs libres comptaient sur github pour rester neutre vis-à-vis des GAFAM, et se sont sentis trahis par les choix de la société.
Maintenant qu’une entreprise fasse du fric est tout-à-fait normal, je suis le premier à en convenir. C’est presque hors-sujet de jouer sur ce créneau.
Mais on est dans le même type de trahison des devs, qui croient leur logiciel relativement à l’abri des géants US, et qui se retrouvent finalement avec un magnifique couteau planté dans le dos du jour au lendemain, sans que personne ne les ait prévenu, et sans qu’ils aient eu le temps de choisir et de déménager pour ceux qui ne supportent pas les joies de la firme de Redmond.
Au final, le rachat de github n’a pas modifié les habitudes des prostitués naturels à microsoft. Pour les autres en revanche, il les a juste obligé à aller voir ailleurs si l’herbe n’était pas plus verte…


hansi

Si rien n’avait changé, gitlab n’aurait pas le succès qu’on lui connaît aujourd’hui…
Beaucoup de devs libres comptaient sur github pour rester neutre vis-à-vis des GAFAM, et se sont sentis trahis par les choix de la société.
Maintenant qu’une entreprise fasse du fric est tout-à-fait normal, je suis le premier à en convenir. C’est presque hors-sujet de jouer sur ce créneau.
Mais on est dans le même type de trahison des devs, qui croient leur logiciel relativement à l’abri des géants US, et qui se retrouvent finalement avec un magnifique couteau planté dans le dos du jour au lendemain, sans que personne ne les ait prévenu, et sans qu’ils aient eu le temps de choisir et de déménager pour ceux qui ne supportent pas les joies de la firme de Redmond.
Au final, le rachat de github n’a pas modifié les habitudes des prostitués naturels à microsoft. Pour les autres en revanche, il les a juste obligé à aller voir ailleurs si l’herbe n’était pas plus verte…


A 2 doigts de découvrir le capitalisme et que si tu payes pas pour un service c’est que peut être t’es juste le produit. Toutes les boites de la planète n’ont qu’une seule règle faire du cash par tous les moyens, il n’y a pas de gentil ou de méchantes entreprises. Celles qui gagnent de l’argent survivent les autres meurent. Ne jamais faire confiance à une entreprise en dehors du contrat que tu signes comme client, tous le reste c’est du vent.



Avec l’apple Store, Apple est sur une corde raide envers les accusations d’abus de position dominante. Je pense qu’un jour la guillotine va tomber


C’est pas le souvenir que je conserve du magasin d’application de Firefox os « applis riches et bien fouttues ».



N’empeche que nous voyons les limites d’un système fermé. Devs et utilisateurs sont à la merci d’un changement de politique. Ça me conforte dans l’idée de passer le plus possible par le web.



hansi a dit:


On ne parlera pas mon plus de github devenu du jour au lendemain la propriété de notre cher grand ami microsoft, alors que nombre de devs libres faisaient précisément confiance à la neutralité de l’outil.




Cela change quoi que la plateforme ai été racheté par MS ?



woodcutter a dit:


Pa simple comme histoire. Je comprends très bien l’envie d’Apple de virer les applications qui ne sont plus mise à jour depuis des années. Mais je comprends également le point de vue de certains développeurs, comme pour les jeux dont je ne vois pas bien l’intérêt de proposer une MAJ. Ce qui me dérange le plus, c’est par exemple sur mon iPad mini 6 que j’ai depuis 6 mois, encore plein d’applications ne sont pas mise à jour pour supporter le nouveau format de l’écran 😏




Et tu as entièrement raison ! La position d’Apple est totalement justifiable. Ainsi que celle des devs … on semble être coincés …



Sauf qu’en fait non. Apple s’est mise seule dans cette situation en forçant l’utilisation de l’App Store comme point d’entrée de toute appli iOS. Tout ce qu’Apple est - légitimement - forcée de faire (faire le ménage dans les vieilles applis, céder aux demandes de censures officielles …) ne poserai absolument aucun soucis si les applications pouvaient être distribuées autrement.



C’est absolument normal qu’un distributeur arrête de son propre chef la distribution d’un produit. Mais ça devient un problème si il interdit au producteur de distribuer son produit par d’autres moyens. Il est là le problème d’Apple, il est pas dans le fait qu’il faut bien qu’ils fassent du ménage.



hansi a dit:


Mais on est dans le même type de trahison des devs, qui croient leur logiciel relativement à l’abri des géants US, […]




Parce que avant d’appartenir à Microsoft, GitHub n’était pas un géant US ? GitHub est depuis longtemps une des machines à cash les plus rentables de la Sillicon Valley. Toutes les startups les plus rentables de la SV sont sur GitHub depuis au moins une décennie.



GitHub fait depuis très longtemps partie des rares géants à avoir tellement de cash à ne plus savoir qu’en faire qu’ils paient des gens pour maintenir leur offre gratuite et sont allés jusqu’à carrément financer le développement d’Atom et d’Electron, deux softs que quasi aucune entreprise au monde sinon les GAFAMs n’auraient pu fournir gratuitement.



Faut bien comprendre que le nerf de la guerre de la Sillicon Valley, toutes entreprises confondues, c’est de se mettre les devs dans les poches à n’importe quel prix. Et le marché de GitHub ça a toujours été ça : fournir sa came gratos à tous les devs du monde pour qu’ils poussent leur entreprise à passer sur les plans payants (extrêmement onéreux). Y’a jamais eu la moindre bonté d’âme là dedans. Juste un calcul froid de « que faut il donner gratuitement pour que les devs poussent leur boîte à nous filer 9$/mois/employé ».



Il se trouve que le monde de l’open source a profité à plein de ce deal et tant mieux pour lui. Mais c’était pas un dû aux libristes. Les actionnaires de GitHub n’ont jamais juré croix de bois croix de fer que si on leur proposait quelques jolis milliards ils diraient non. Ils auraient d’ailleurs été bien cons de le faire.


Donc une simple application de boussole, calculatrice,… bien basique a besoin de nouveauté et de maj ??


Oui si le processus d’installation et les hook ont changés de nom / procédure.


Que l’application soit simple ne l’empêche pas de mettre à jour certains éléments notamment lié à la sécurité ou la vie privée.



A mesure que l’OS évolue, les droits sont de plus en plus confinés. Un appel d’API peut devenir obsolète et déprécié car moins sécurisé que la couche actuelle, et donc nécessite de mettre à jour cet élément. L’appli aura toujours le même fonctionnement, ce sera transparent pour l’utilisateur, mais sur le plan sécurité, vie privée et sens des choses bien faite, ça change tout :yes:



PS: ceci est exemple non exhaustif, d’autres éléments peuvent être considérés, c’est juste un exemple parmi d’autre.



Si la personne concernée n’a plus publié sur l’App Store, elle va devoir recompiler la nouvelle version avec le dernier Xcode, dont la version 13 réclame macOS Big Sur. Ce dernier ayant fait l’impasse sur d’anciens Mac, il faudra peut-être racheter du matériel plus récent.




La fameuse stratégie “ping pong” d’Apple. Ce développeur achètera un nouveau Mac, mettra à jour Xcode, actualisera son application.



Xcode n’activera pas les anciennes versions d’iOS, donc le propriétaire d’un vieil iPhone verra qu’il y a une mise à jour qu’il ne peut plus installer, il jugera son iPhone obsolète et achètera un nouvel iPhone…



Ce nouvel iPhone ne sera pas compatible avec les applications dont les développeurs n’ont pas publié de mise à jour.


Question de novice : une application/un jeu ne risque pas de présenter des failles de sécurité s’il reste sans mise à jour durant plusieurs années ? N’y a-t-il pas un “minimum nécessaire” à fournir en mise à jour ? (A noter que je pars par ailleurs du principe que iOS est mis à jour en dernier version.)
Merci !


Une appli qui ne fait pas de réseau et tourne en espace utilisateur dans une sandbox, que veux-tu qu’il lui arrive comme faille de sécurité ?


En fait les problèmes de sécurité sont présents ou non. Avec le temps on les découvre, du coup une appli ancienne a des chances d’avoir une dépendance (un bout de code tierce qu’elle utilise) avec des vulnérabilités connues.
En supposant qu’elle ne fait appel à aucun code tiers (elle appelle seulement des fonctions système) alors dans ce cas le risque n’augmente pas vraiment avec le temps. Si le développeur fait une mise à jour sous la contrainte d’Apple il y a peu de chances que cette mise à jour corrige une faille de sécurité. Sinon on pourrait espérer qu’il y aurait déjà eu une mise à jour.



Il y a aussi un dernier aspect : l’usage de plus de fonctions de sécurité. Par exemple une appli compilée pour Windows 95 n’aura pas forcément tous les mécanismes de sécurité de Windows 10 activés. Changer de compilateur peut améliorer la sécurité.
Je pense en particulier à ASLR ( https://www.mandiant.com/resources/six-facts-about-address-space-layout-randomization-on-windows ) ou à des chose comme tout ce qui tourne autour de la protection de la pile ( https://en.m.wikipedia.org/wiki/Buffer_overflow_protection )


xlp

En fait les problèmes de sécurité sont présents ou non. Avec le temps on les découvre, du coup une appli ancienne a des chances d’avoir une dépendance (un bout de code tierce qu’elle utilise) avec des vulnérabilités connues.
En supposant qu’elle ne fait appel à aucun code tiers (elle appelle seulement des fonctions système) alors dans ce cas le risque n’augmente pas vraiment avec le temps. Si le développeur fait une mise à jour sous la contrainte d’Apple il y a peu de chances que cette mise à jour corrige une faille de sécurité. Sinon on pourrait espérer qu’il y aurait déjà eu une mise à jour.



Il y a aussi un dernier aspect : l’usage de plus de fonctions de sécurité. Par exemple une appli compilée pour Windows 95 n’aura pas forcément tous les mécanismes de sécurité de Windows 10 activés. Changer de compilateur peut améliorer la sécurité.
Je pense en particulier à ASLR ( https://www.mandiant.com/resources/six-facts-about-address-space-layout-randomization-on-windows ) ou à des chose comme tout ce qui tourne autour de la protection de la pile ( https://en.m.wikipedia.org/wiki/Buffer_overflow_protection )


Merci beaucoup ton explication très claire.


N.AS

Merci beaucoup ton explication très claire.


Super j’avais peur que ça soit un peu trop technique !


J’ai du mal a comprendre ces développeurs qui justifient l’arrêt des mises a jour sur un logiciel toujours vendu, ça va a l’encontre des bonnes pratiques en qualité et cybersécurité. Ça parle d’objet finis, mais il n’y a rien de tel dans le cycle de vie d’un logiciel: une fois la maintenance terminée, on passe directement a la mise au rebut. Eventuellement a l’archivage, ce qui implique dans tous les cas un retrait de l’app store.


Toutes les application ne sont pas payantes et pour avoir bossé sur ce type de plateforme pendant des années bien souvent le travail consiste à engranger la thune sans filer aucun outil / documentation au développeurs.



Concrètement : tu te lève un matin, tu installe la nouvelle version et ensuite tu installe ton application, cela ne fonctionne pas. Pourquoi ? Le processus d’installation à changer. Tu dois donc étudier l’installation d’une autre application native du CMS. Tu corrige l’installation et la tu vois que beaucoup de méthodes ont changés et tu te retrouve avec une page blanche. Une véritable horreur.



choukky a dit:


Incrémenter une version “à blanc”, ça marche ? :francais:




Oui cela suffit pour proposer une mise-à-jour. C’est une solution pour les applications qui peuvent encore être compilées facilement en respectant les nouvelles règles mises en place par les stores.



Le problème arrive quand tu dois refactorer ton code pour t’aligner avec les nouvelles exigences des stores. Tu peux avoir à mettre à jour tes dépendences parce qu’un bug survient lorsqu’on le compile en targetant un SDK plus récent d’Android, si cette nouvelle version n’est pas compatibke au niveau de l’API, tu peux avoir à faire pas mal de modifications pour mettre à jour cette dépendance-là. Et comme indiqué dans l’article, pour un projet iOS, cela peut nécessiter de mettre à jour Xcode et t’amener à acheter un nouvel ordinateur si la version requise de Xcode n’est plus compatible avec la dernière version de l’OS supporté par ton hardware…



Du coup, même pour faire un simple incrément sur ton numéro de version, tu peux galérer et que ça ne vaille pas la peine de faire tous ces efforts.



hansi a dit:



“prostitués naturels à microsoft”




T’as voulu passer les entretiens et les RH n’ont jamais répondu à ton CV ? Ou un jour quelqu’un de chez MS a rigolé en meeting lorsque tu parlais ? Ou bien une femme te plaisait et elle est partie se marier avec un commercial de chez MS ?



Ton niveau de connerie n’égale que ton ressentiment envers MS, et dieu sait que t’en raconte un sacré paquet. Que tu sois un fana d’un parti politique, on peut comprendre, mais sur ce sujet ça devient maladif. C’est un sujet Apple et de moindre niveau sur Androïd, où MS n’a aucun rôle dans cette affaire, et tu trouves le moyen de déverser ton fiel.



T’as la même posture idéologique de ces vieux profs à la fac pour qui Wikipédia est une immense source de connerie et que tu ne dois surtout pas lire parce que n’importe qui peut modifier le contenu.
MS n’est pas parfait, mais jeter tout le travail de centaines de milliers de personnes depuis des décennies… Vraiment ?


J’ai créé et je crée des applis sur le Store Android.
Je ne mets jamais à jour mes applis une fois finalisées.
Pas que ça à faire et qui paie pour mon temps ?
On m’a payé à un instant T pour réaliser une APP, c’est fait, basta, je ne dois plus rien. Ou alors, il faut que le client accepte de payer une maintenance. Ce n’est pas le cas, c’est même rarement le cas pour les petites applis (ou je ne sais pas y faire, c’est possible aussi :non: )