Rivalité Google-Apple : comment un bouton sur un téléphone a changé le monde
13/10/2021
Google change son fusil d’épaule : les applications sur iPhone et iPad seront maintenant créées avec des composants Apple. Aucun changement à signaler pour les utilisateurs. Google obtient de son côté un grand succès, même si l’entreprise donne un coup de main à la concurrence.
Le fonctionnement des applications Google sur iPhone et iPad devrait se rapprocher de celui des applis Apple.
Cette nouvelle ne s’apparente en elle-même pas à une grande sensation, mais elle signifie pourtant beaucoup. Derrière cette décision d’« Apple-iser » les applications Google se trouve beaucoup de travail, de politique, de jalousie et de concurrence économique.
Pour Google, le passage du développement propre aux composants Apple joue certes en faveur de la concurrence, mais s’avérait nécessaire et est profitable pour le moteur de recherche.
Les coulisses de l’architecture des applications
Chaque application a un framework. Dans la construction de maison, ce dernier serait l’échafaudage sur lequel se bâtit l’interface utilisateur que vous voyez et utilisez. Il existe des frameworks pour back-ends et front-ends. Dans cet article, seuls les front-ends, c’est-à-dire les interfaces utilisateur et tout ce que la clientèle peut voir, sont importants. Pour simplifier, on parlera par la suite simplement de « framework ».
Le choix et les spécificités du framework sont des décisions qui reposent sur les goûts des managers, et non ceux des programmeurs.
Les applis sur votre smartphone sont créées à l’aide d’un framework.
Les deux sont intégrés à un kit de développement logiciel (SDK). Celui de Google s’appelle Android Studio et celui d’Apple Xcode. Les deux SDK ont été inventés par leur fabricant respectif et sont en constante évolution. Dans la construction de maison, ils représenteraient la caisse à outils, qui contient tous les objets nécessaires pour ériger un bâtiment.
À l’aide du SDK Apple, vous pouvez créer des applications Android. UIKit et Xcode fonctionnent en effet avec le langage de programmation Swift, également utilisable pour les applications Android. Android se base certes sur Java, mais prend aussi en charge à peu près tous les langages de programmation disponibles sur le marché.
En bref, il est aussi possible, avec des compétences en programmation sur Android, de créer des applications iOS, et vice-versa. Cependant, cette possibilité ne représente un intérêt que dans peu de cas. La raison s’avère ici moins technologique que politique.
La politique influence la programmation
Les SDK sont gratuits et libres d’accès. Les langages de programmation sont open source et également libres d’accès. C'est ce que promet l'âge d’or des applications ;un unique programme compatible avec tout. D’un point de vue technologique, la voie au développement et à l’utilisation d’applications natives par tous et pour tous serait ouverte.
Le problème est que ni Google ni Apple n’ont vraiment intérêt à ce que ça ait lieu.
Évidemment, les deux entreprises parlent d’ouverture à coup de termes comme « intuitif ». Cela ne concerne néanmoins que le cas dans lequel un programmeur Android programme avec Android Studio pour Android. Tout le reste n’est que détour. Un regard sur Flutter pour iOS Developer explique son fonctionnement. Les termes ne sont pas les mêmes, les choses fonctionnent différemment et de manière générale, le programmeur doit tout réapprendre le langage de programmation.
Swift is a powerful and intuitive programming language for iOS, iPadOS, macOS, tvOS, and watchOS.
En réalité, ce n’est plus « intuitif » ou « facile » d’accès. Il est extrêmement compliqué de franchir le pas dans la pratique. En fait, il paraît plus simple pour un programmeur de juste installer deux SDK et de pratiquement écrire l’application deux fois. Pour cela, il faut un temps et des ressources que seuls les grands studios de programmation possèdent. En réalité, ces derniers, petits ou grands, se trouvent tous face à un dilemme :
- Ils choisissent une plateforme (iOS ou Android) et promettent de s’occuper de l’autre par la suite.
- Le studio se base sur un framework hybride. Il n’est pas forcément nécessaire d’utiliser un framework natif. Ionic constitue un exemple de framework hybride. Flutter peut aussi l’être, mais ne peut pas se passer de Xcode.
- Le studio développe l’application en double. Cette décision peut même coûter plus cher qu’avec une approche hybride.
The Apple Swift compiler has had the ability to compile code for the Android platform for a few years now, but it hasn’t made many friends in the developer community owing to its complexity.
C'est là que le management et l’efficacité opérationnelle se rencontrent. Les programmeurs construisent certes quelque chose d’open source, mais dont l’implémentation véritable dans la vie réelle s’avère, en dehors d’un cadre bien défini, excessivement compliquée. Pourrait-on faire plus simple ? Oui. Va-t-on le faire ? Non. La raison : les composants pour les propres plateformes doivent continuer à être développés. Cela demande des ressources, du temps et du travail. Des ressources qui ne doivent pas être à disposition de la concurrence.
Voilà un exemple un peu moins abstrait : si Apple voulait optimiser le passage de Swift sur Android, l’entreprise de Cupertino effectuerait le travail pour son grand rival Google. Apple gaspillerait ses ressources pour le développement de Google. La marque à la pomme n’en tirerait rien, contrairement peut-être au monde de la programmation. De toute façon, Apple ne veut pas travailler pour la concurrence et possède un véritable talent pour créer et tenir des secteurs spécifiques.
Google Maps sur iOS : historiquement parlant, du bricolage
La montée en puissance de l’iPhone et la marche triomphante simultanée d’Android n’ont pas seulement donné naissance à une situation de concurrence, mais aussi à un besoin, celui d’avoir YouTube, Google Maps et peut-être Google Photos sur iPhone.
Google en avait très peu envie : l’entreprise aurait en effet donné une raison aux utilisateurs Apple de rester sur Apple. Finalement, la pression publique était trop grande. Les applications Google ont ainsi peu à peu trouvé leur place sur les plateformes Apple, et réciproquement. Apple propose sur Google Play Store une poignée d’applications, mais ne cherche aucunement à transférer iCloud sur Android.
Pour quoi faire ? Ceux qui souhaitent bénéficier d’iCloud doivent utiliser un iPhone.
Ceux qui désirent utiliser Google Drive peuvent en revanche le faire depuis presque chaque smartphone.
Dans les deux cas, on a affaire à une décision politique de chaque fabricant. Une seule chose à dire sur ces deux décisions : c’est de bonne guerre. Les entreprises ne sont pas tenues à l’ouverture : ce serait peut-être plus correct, mais personne ne peut forcer Apple à l’être, de la même manière que Google n’est pas obligé d’être présent sur les plateformes Apple. D’un point de vue juridique, la seule chose à éviter dans la programmation de logiciels est un monopole trop évident. Tant qu'aucun monopole ne peut être prouvé, tout va bien.
En 2012, Google a pris la décision de transférer la première application sur iOS (Google Maps). Durant la conception des applications Google pour l’écosystème Apple, l’équipe et son Development Leader Jeff Verkoeyen ont remarqué qu’il manquait à Apple des éléments absolument nécessaires pour les applications Google. L’équipe a alors construit ces éléments après coup : des corps étrangers, ou Material Components dans le jargon technique. Ils sont évidemment open source. Google et Apple évitent ainsi les accusations de monopole.
En d’autres termes, la première version de Google Maps sur iOS d’Apple était du bricolage. L’application comporte des bibliothèques, des éléments de conception et des fonctions propres à Apple, mélangés à ceux fournis par Google.
Cela est resté tel quel durant neuf ans.
Material Components : en mode maintenance depuis juillet
Cela a néanmoins changé en juillet 2021. Les Material Components pour iOS (les corps étrangers) ont été mis en mode maintenance par Google. Cela signifie qu’ils ne connaîtront pas d’autres développements jusqu’à nouvel ordre, mais seront simplement maintenus en l’état. Des réparations seront entreprises en cas de bug et les failles de sécurité seront comblées. Sinon, les Material Components sont destinés à mourir dignement.
Google fait du même coup un grand pas politique en avant. En effet, au lieu de changer leurs propres composants, Jeff Verkoeyen et son équipe s’appuieront à l’avenir entièrement sur les composants d’Apple. Il le confirme dans un Thread Twitter.
But as we continued on the pursuit of cross-platform pixel parity, our iOS components were slowly drifting further and further from Apple platform fundamentals because those fundaments were also evolving year over year.
Jeff Verkoeyen décrit une situation dans laquelle le développement d’un logiciel non partagé était inévitable. Les Material Components continueront d’évoluer et vont dans une direction. Les composants Apple essentiels connaissent une évolution constante et prennent une autre direction. Le fossé à combler entre les Material Components ne cesse de s’agrandir.
Début 2021, l’équipe de Jeff Verkoeyen s’est demandé : ce fossé doit-il vraiment être comblé ?
Un coup d’œil sur les capacités du SDK Apple et ses composants montrent qu’Apple pourrait aussi y parvenir. Il était venu le temps de poser quelques questions désagréables. Est-ce qu’un simple interrupteur dans une application nécessite vraiment son propre composant issu d’une librairie externe ?
La réponse fut catégorique : non. La plupart des Material Components ne sont plus nécessaires : Apple livre depuis ses propres composants essentiels. Les quelques composants qui doivent encore être ajoutés obtiendront grâce au mode maintenance plus d’attention que tous les autres composants. Cela promet un développement plus rapide et efficace des applications Google sous iOS.
Il est fort probable que vous, utilisateur, ne remarquez pas cette modification. Et ce, bien que des éléments simples dans les applications Google soient désormais réalisés avec le « UINavigationController » propre à Apple au lieu du Material Component « App bar ».
App bars become UINavigationControllers. Standard controls just need light branded touches. Lists can align with modern UITableView and list-based collection view APIs. Menus are just UIMenus.
Bien sûr, ces composants Apple dans les applications de Google ne ressembleront pas à ce qu’Apple a créé. Google va apporter son identité de marque.
Bilan : l’argent domine la politique
La décision de Google de travailler avec les composants Apple constitue une arme à double tranchant. Elle montre aussi que la raison peut l’emporter. Le passage des composants Google aux équivalents d’Apple permet à Google d’économiser de l’argent, mais fournit en même temps des informations, des connaissances et peut-être même du code pour améliorer des choses qu’Apple avait jusqu’à présent toujours refusé d’améliorer.Ou alors, Apple n’était pas conscient de pouvoir l’améliorer.
Du côté des fonctions, la décision est logique. Le fait que quelque chose était bien ou indispensable il y a dix ans ne signifie pas qu’il l’est encore aujourd’hui. Si Apple peut livrer des composants qui remplissent la même fonction que ceux de Google, il est logique de laisser mourir les propres développements.
Google obtient un grand succès avec ce changement. Les services fournis par les applications du géant des moteurs de recherche sont chers à tous les utilisateurs. Mais la critique selon laquelle les applications sur iPhone ne fonctionnent pas aussi bien que sous Android ou les applications Apple pas aussi bien sous iOS est justifiée, de même que le changement est probablement aussi caduc.
Le géant des moteurs de recherche économise de l’argent, du temps et se rend populaire aux yeux des utilisateurs. Un coup de maître.
Mais l’équipe de Jeff Verkoeyen a dû faire preuve de courage. Admettre que dix ans de travail n’ont servi à rien n’est pas une mince affaire. D’un côté, des postes dans l’équipe vont disparaître ; de l’autre, Jeff Verkoeyen et cie admettent que le biais des coûts irrécupérable est surmontable, ou même qu’il devrait être surmonté. Le fait d’avoir mis beaucoup d’argent et de temps dans un projet ne signifie pas que ce dernier sera rentable.
Pour les utilisateurs, cela signifie peut-être juste un interrupteur dans l’application. Si l’on en revient à la métaphore de la construction de maison, ce changement représenterait le matériau d’isolation dans le mur. Mais pour Google et Apple, le monde a un peu changé.
Journaliste. Auteur. Hackers. Je suis un conteur d'histoires à la recherche de limites, de secrets et de tabous. Je documente le monde noir sur blanc. Non pas parce que je peux, mais parce que je ne peux pas m'en empêcher.
