Microsoft ouvre Windows 10 aux développeurs iOS et Android
Microsoft veut augmenter le nombre d’applications disponibles sur Windows 10 et l’éditeur a sorti le grand jeu pour atteindre cet objectif. À l’occasion de la conférence Build 2015 qui se déroulait aujourd'hui même à San Francisco, l’entreprise a présenté quatre nouveaux moyens pour porter une application au dernier système d’exploitation.
Windows 10 doit être installé sur un milliard d’appareils d’ici deux à trois ans, tel est l’objectif avancé par Microsoft. Pour atteindre cet objectif ambitieux, l’entreprise veut convaincre les développeurs de tous les horizons. Un ensemble d’outils sera ainsi proposé pour convertir les anciennes applications Windows, quelle que soit la technologie utilisée (Win32, .NET et d’autres encore). Cette conversion fonctionne même pour les plus gros logiciels, et Adobe a pu la tester avec succès.
Une autre solution, déjà présentée par l’éditeur, est dédiée aux webmasters qui peuvent entourer leurs sites d’un peu de code natif et proposer une application dans la boutique de Microsoft. Mais l’annonce la plus importante — et annoncée par la rumeur plus tôt dans la journée — et aussi la plus ambitieuse concerne les applications mobiles existantes. Les développeurs devraient pouvoir convertir très simplement leurs applications iOS et Android pour les transformer en applications pour Windows 10.
Dans un cas, comme dans l’autre, le pari est toujours le même. Les développeurs sont censés pouvoir garder l’écrasante majorité de leur code en Objective-C, Java ou C++ et obtenir en quelques clics une application convertie pour Windows 10. Microsoft a invité King, le créateur de Candy Crush, pour tester cette fonction et apparemment, le jeu a pu être adapté à partir de la version iOS en modifiant uniquement un faible pourcentage du code.
Restera, naturellement, l’épineuse question des interfaces : que l’on puisse, très rapidement, convertir un projet iOS et le proposer sur Windows 10 est une bonne chose pour le développeur, mais cela ne veut pas dire que l’application créée sera adaptée au système de Microsoft. D’autant que l’éditeur entend précisément demander le moins de travail possible aux créateurs d’applications : ils n’auront pas besoin de gérer les fonctions spécifiques de Windows 10, comme le système de tuiles. Mais naturellement, ils pourront le faire.
En clair, rien n’est gagné pour Microsoft qui devra non seulement convaincre les développeurs de l’intérêt de porter leurs apps, mais aussi les utilisateurs de l’intérêt d’avoir des apps portées sans un développement spécifique. Ajoutons que les choses sont encore plus complexes côté Android, où de plus en plus de fonctions nécessitent les services de Google. Le créateur de Windows 10 devrait proposer des équivalents, mais les applications ne seront pas toutes compatibles à 100 %.
Microsoft n’est pas le premier à essayer cette stratégie. BlackBerry avait déjà tenté d’attirer les développeurs Android pour remplir sa propre boutique d’applications. Comme on le sait, le succès n’a pas été vraiment au rendez-vous. L’éditeur mise beaucoup sur cette idée en tout cas, comme en témoigne son nouveau navigateur — le projet Spartan, qui s’appellera finalement Microsoft Edge — compatible avec les extensions de Chrome et Firefox.
INPI = Institut National de la Propriété Industrielle
https://fr.wikipedia.org/wiki/Institut_national_de_la_propri%C3%A9t%C3%A9_industrielle
J'espère qu'Apple va enfin fournir le gros travail d'optimisation qui manque à OS X et iOS, comme ils ont pu le faire avec Snow Leopard.
En attendant, la stratégie de Microsoft est prometteuse sur le papier mais les ventes anémiques des Lumia et Surface rendent pas forcément le portage d'apps – même facilité – attractif pour un développeur.
Je suis un peu étonné aussi du non support de Swift alors qu'Apple mise beaucoup dessus pour prendre la suite de l'objective-C
Gérer un langage assez complet com Swift, avec aucune implémentation libre, c'est long.
C'est une bonne chose que MS se réveille.
Et comme Apple me saoule de plus en plus, notamment avec sa dernière mouture d'OSX que j'ai mise aux orties, j'attends la suite avec impatience.
"sa dernière mouture d'OSX que j'ai mise aux orties"
Miam ! Un bon assortiment pour la soupe aux orties :)
J'attends de voir tourner tout ça en conditions réelles pour me faire un avis définitif. Après tout, les mecs de MS ne sont pas des manches et leur nouveau CEO donne l'impression d'avoir une vraie vision, donc j'imagine qu'ils ont déjà pensé depuis longtemps à tous les arguments qu'on pourra sortir ici.
Néanmoins, ça a le mérite de mette une différence marquée entre l'approche de MS et celle d'Apple sur les OS de bureau. Apple n'a jamais transigé sur la qualité des applis OS X, même si tout n'est pas parfait, au moins ils n'ont jamais cédé à la facilité en permettant le portage d'une appli iOS sur OS X en 2 clics, alors qu'ils pourraient le faire autrement plus facilement que ce qu'a fait MS ici.
On a vu avec la dernière appli Photos qu'ils travaillent néanmoins sur un nouveau framework pour rendre plus facile la transition iOS -> OS X pour les dev, mais ils sont clairs sur le fait qu'une appli Mac est différente d'une appli iOS au point de vue ergonomie (et pour une très bonne raison : un OS est fait pour le clavier/souris, l'autre pour le tactile).
À l'opposé, MS semble prêt à sacrifier toutes ses guidelines de design et d'ergonomie au profit de la facilité et du nombre d'applis sur son Store. Ça pourra certainement faire illusion pour les jeux type Candy Crush et autres, mais ça sera une autre paire de manches quand ils auront des applis iOS avec des barres de navigation, des tab bar et du flat design et couleurs pétantes de partout, à côté d'applis à menu "hamburger" venues d'Android et adaptées au material design...
Bref, pour moi c'est clair, je reste chez Apple. On peut discuter longuement de la qualité de leur matériel et de leur logiciel, mais si il y a un truc sur lequel ils rigolent pas trop, c'est le respect des guidelines et de l'expérience utilisateur, et c'est ce que je préfère dans cette boîte. Rien n'est parfait, mais au moins ils poussent les développeurs à en faire le plus possible pour assurer une cohérence avec le système.
J’espère que cette approche ne rencontrera aucun succès.
Sinon, à terme, on verra se créer la fameuse fragmentation dont Apple se vante d’avoir réussi jusque là à protéger les développeurs iOS : on aura d’un côté le parc d’appareils sous iOS avec la toute dernière version des API, et de l’autre le parc des engins sous Windows avec une version plus ancienne des API iOS. Pire, si le succès est vraiment au rendez-vous, on pourrait voir Microsoft proposer ses propres ajouts à ces API, disponibles uniquement pour la version Windows bien sûr.
C’est toujours dangereux, pour un éditeur d’OS, de se faire déposséder du contrôle de ses API.
Heureusement, Microsoft part de très loin et Apple avec Swift vient de limiter pas mal l’intérêt de cette solution pour les développeurs iOS, du coup ce danger semble encore faible.
Mais on a vu à quelle vitesse les choses peuvent changer dans le monde des systèmes mobiles…
Des librairies C (comme la glibc, c'est à dire celle du projet GNU) ajoutent des extensions qui ne font pas partie du standard tout en restant compatible avec celui-ci. Mais, ça ne pose pas de problème, généralement les programmeurs font sans les extensions ou les utilisent à travers une couche d'abstraction.
On peut aussi citer le cas de JavaScript, avec les polyfills qui font qu'il n'y a pas de problème important d'API.
De mémoire, Institut National de la Propriété Industrielle. . .
Pages