La guerre des outils de développement
Apple et Google redoublent d'efforts pour que les développeurs utilisent leurs outils maison pour concevoir des applications. Après tout, ce n'est pas pour rien si les deux groupes « invitent » en Californie les développeurs du monde entier pendant une semaine. L'un des objectifs de ces conférences est de les aider à utiliser au mieux les technologies « officielles » afin de leur permettre de concevoir de meilleurs apps.
Xcode et Android Studio ont beaucoup de points en commun. On se gardera bien de les comparer précisément, on pointera juste que ce sont deux environnements de développement ultra-complets et gratuits - mais rappelons qu'Apple et Google font payer la publication d'une app sur l'App Store et Google Play.
Récemment, App Figures a publié une étude dans laquelle elle analyse entre autres les outils de développement utilisés sur les deux plateformes (lire : L'App Store moins fourni, le Play Store toujours plus garni). La chose la plus surprenante, c'est que Google est en avance sur Apple dans sa quête d'imposer son environnement de développement. En 2017, 90 % des apps sur Android étaient réalisés avec Android Studio. Un chiffre en progression de 17 point par rapport à l'année précédente. Sur iOS, Xcode n'est utilisé que dans 76 % des cas. Mais là aussi, il s'agit d'un chiffre en progression de 8 points par rapport à 2016.
Comment expliquer une telle différence ? Il y a peut-être le mode de distribution à prendre en compte. Android Studio est multi-plateforme alors que Xcode est utilisable uniquement sur macOS. Cette exclusivité a d'ailleurs été lors de la dernière décennie l'une des meilleures raisons données aux développeurs mobiles pour passer sur Mac. Apple a écoulé plusieurs centaines de milliers de machines grâce à cela. Petit bémol concernant Android toutefois, cette large adoption est quelque peu gâchée par le fait que le parc de terminaux en circulation utilise de vieilles versions d'Android.
Mais pourquoi après tout vouloir pousser les développeurs à utiliser à ce point Android Studio ou Xcode ? Les raisons sont multiples. Ces dernières années, nous avons assisté à une guerre de mouvements entre Android et iOS. Apple et Google n'ont eu de cesse de présenter de nouveaux frameworks et API pour enrichir leurs systèmes d'exploitation respectifs. Pour s'assurer que les développeurs exploitent au plus vite ces nouveautés et de la meilleure des façons, il est essentiel d'utiliser les outils proposés par les deux groupes californiens. Normalement, vous devez aussi aboutir à de meilleures performances et à des apps plus économes. Mais le facteur humain entre également en compte dans ces aspects bien entendu.
En faisant du sur-mesure sur chaque plateforme, les développeurs ont tout en mains en théorie pour faire de meilleures apps. Mais cela nécessite la maîtrise de plusieurs langages de programmation et de plusieurs environnements de développement, ainsi que de connaitre les spécificités de chaque plateforme… De loin, que ce soit pour les petites ou grosses structures, le choix du natif n'a pas que des avantages, notamment d'un point de vue économique. On peut aussi avoir l'impression d'être emprisonné dans une plateforme. Comme le montre cet article du Digital Guide de 1and1, chaque manière de faire a ses avantages et inconvénients.
Parmi les outils de développement non natifs, il y en a deux qui tirent leur épingle du jeu. Il s'agit de Cordova et d'Unity. Le premier permet de réaliser des apps pour différentes plateformes en utilisant les langages de programmation du web, alors que le second est spécialisé dans la création de jeux. Avoir des applications identiques d'une plateforme à l'autre est sans doute l'une des choses qui doit effrayer le plus Apple. Elle perd son argument de différentiation par rapport à la concurrence. Par exemple, ces derniers mois elle pousse très fort la réalité augmentée. Le management d'Apple croit pouvoir faire la différence sur ce créneau.
Un dernier exemple pour illustrer l'importance de ces enjeux. Apple devrait en toute logique présenter le projet Marzipan à la WWDC, dont l'un des grands mérites à ce que l'on dit sera de pouvoir adapter très facilement une app iPad sur Mac. Imaginez le problème pour Apple si la plupart de sa communauté de développeurs utilisait des outils incompatibles avec Marzipan…
Cordova : le seul moyen d’avoir une app moche et non sécurisée. Injection JS les doigts dans le nez dans la plupart des apps. (Via Analytics ou autres)
@FloMo
«Cordova : le seul moyen d’avoir une app moche et non sécurisée. Injection JS les doigts dans le nez dans la plupart des apps. (Via Analytics ou autres)»
Ce n'est helas pas le seul moyen.
Si 'l'outil de developpement peut influer sur "l'esthetique" de l'application, c'est surtout une question de conception et de competence dans la matiere qui releve pleinement du developpeur.
La securité, c'est aussi avant tout un probleme de competence et de temps.
Pour autant le probleme securitaire et d'optimisation a bien une relation indirecte avec l'outil de developpement. Utiliser un outil multiplateforme, voire un generateur d'application releve d'une motivation et d'un niveau de competence particulier. Normalement le gars utilisant un generateur d'application n'a pas les competences ni la motivation necessaires pour aller en profondeur dans les arcanes de fonctionnement natif...
Je dirai meme que souvent il n'est pas question de programmation ou meme developpement mais de paramétrage d'un generateur...
Mais je reviens sur le plus gros probleme: l'ergonomie et la fonctionnalité.
L'esthetique peut ameliorer une experience ou la degrader tout comme elle peut influencer les ventes. L'optimisation et les bug sont aussi des elements importants, mais paradoxalement - hors de cas extremes - l'utilisateur a une tolérance étonnamment forte…
Ce qui fait qu'un utilisateur adopte et conserve une application c'est sa fonctionnalité et son ergonomie. Si la fonction est adequate avec le besoin et que l'ergonomie la rend aisée, l'application sera un succes.
Et la c'est une question uniquement de competence dans la phase de conception, qui demande des connaissances en ergonomie et des capacités d'analyse poussées.
Au-dela de l'incomptence il y a un autre facteur: le temps.
Apple compterait 15 millions de dev iOS, peut etre plus aujourd'hui. Ils produisent des applications a moins de $5. Apple sort un nouvel os chaque annee. Il faut produire tres vite...
dommage que le support de cocos2D soit arrêté ;(
j'aimais bien ce framework
du coup passage a swift et spriteKit, bon ca va c'est pas trop compliqué
Apple devrait obliger les devs à utiliser ses outils.
Parce qu'avec les apps multiplateformes on se retrouve avec des apps qui sont moches et qui on des performances déplorables.
Y a qu'à voir les jeux qui sont plus moche aujourd'hui (tout en consommant plus) que les jeux du début.
@fousfous
Depuis les débuts des apps iPhone la grande majorité des jeux sont faits avec des outils cross-platform. Il faut chercher la cause de cette baisse de qualité esthétique ailleurs (si tant est qu’elle existe...).
@patchoulol
Pas au début de l'iPhone, c'était des jeux exclusivement développé pour l'iPhone.
@fousfous
Non. Je pense par exemple à Cocos2D qui était largement présent déjà en 2010. SpriteKit, l’équivalent chez Apple, n’est sorti qu’avec iOS 7.
De toute façon, les jeux sont vraiment des apps à part car ils présentent des expériences immersives et n’utilisent donc quasiment jamais les frameworks d’UI des autres apps. Donc il n’y a vraiment aucun lien entre le fait d’utiliser un framework cross platform et le fait que ton jeu soit réussi graphiquement. Au contraire, le fait que ton jeu soit cross platform permet d’allouer plus de ressources de développement dessus.
@fousfous
Je suis entièrement d’accord avec toi
@fousfous
Si elles sont bien codées non... Cordova est un compilateur. Si le code html est propre, l’application le sera.
@fousfous
> Apple devrait obliger les devs à utiliser ses outils.
Vous avez oublier de dire qu'ils sont fainéants, je suis déçu, d'habitude vous n'oubliez jamais de le rappeler.
Apple ne peut pas les obliger : ce ne sont pas ses employés, ni même ses fournisseurs.
Ce qu'elle peut faire c'est ne valider que les apps développés avec ses outils.
Cela ravirait probablement la Commission Européenne et irait alors rejoindre les éléments de preuve d'abus de monopole et concurrence deloyale dans son dossier contre Apple...
Au passage, vous avez une conception étrange de la méritocratie technologique : pour que la meilleure gagne, il faut l'imposer de force !?
@byte_order
Les gens ont tendance à choisir la merde tant que tout le monde l'utilise.
Regarde Facebook par exemple, que ce soit un niveau du service que de l'app.
Si les gens choisissaient le meilleur Windows n'aurait jamais pu percer aussi.
> Les gens ont tendance à choisir la merde tant que tout le monde l'utilise.
P'tet parce que la compatibilité, l'interopérabilité, c'est pas un argument de "merde" mais un point important pour les gens, finalement ?
Un truc vraiment meilleur sur assez de tableau, il ne s'impose pas de force, il s'impose de facto. C'est ainsi depuis... depuis toujours.
Mais faut juste arrêter de généraliser une qualité pour qualifier un truc de "meilleur" sans regarder d'autres points que d'autres personnes, eux, considèrent comme un point négatif.
Le multiplateforme n'est pas meilleur technologiquement (quoi que des fois...), mais il est dans de nombreux cas meilleure en terme économique, en ROI, en expérience utilisateur unifié sur toutes les plateformes.
Pour le client qui veut que du natif bien foutu (ce qui n'est pas non plus garantie au passage) : qu'il paye le vrai prix des choses. A défaut de payer correctement les efforts de ces fainéants de développeurs (qui devraient être forcé à faire contre leur gré des choses qui les nourrissent pas plus), il peut avoir du non natif éventuellement, souvent gratuitement.
Les gens sont prêts à mettre $1000 dans un terminal, mais considèrent que $10 ou même $5 c'est trop cher payé pour une application. Payez les gens comme des merdes, ils vous font de la merde. C'est logique. Offre et demande.
> Si les gens choisissaient le meilleur Windows n'aurait jamais pu percer aussi.
Vu ce qu'il existait à l'époque comme concurrence sur architecture PC, c'était bien le meilleur.
Il n'appartenait qu'à Apple de porter MacOS (classic) sur PC pour lui contester cette place.
Mais Apple ne l'a pas fait, parce que proposer les meilleurs solutions n'a jamais été son but, mais de tirer un profit maximal en les liant à l'achat d'un matériel.
Quelle technologie d'Apple non lié à la vente de matériel s'est imposée comme étant la meilleure sur ses seules mérites technologiques ?
Un truc vraiment meilleur s'impose de facto, point.
@ byte_order : « Vu ce qu'il existait à l'époque comme concurrence sur architecture PC, c'était bien le meilleur. »
Non, même pas.
« Il n'appartenait qu'à Apple de porter MacOS (classic) sur PC pour lui contester cette place.
Mais Apple ne l'a pas fait, parce que proposer les meilleurs solutions n'a jamais été son but, mais de tirer un profit maximal en les liant à l'achat d'un matériel. »
Curieuse interprétation de ce qui s’est passé alors. Il convient d’en proposer une autre, ne serait-ce que pour éviter qu’un lecteur naïf confonde cette interprétation avec une vérité absolue. ;-)
On peut donc voir ça d’une façon assez différente, en se disant qu’au contraire Apple voulait absolument proposer la meilleure solution, qu’elle considérait être une machine complète avec son OS, au lieu d’accepter de se laisser aller à l’approche inférieure d’un Mac OS pour PC juste pour tenter de dominer ce marché et d’en tirer le profit maximal.
« Quelle technologie d'Apple non lié à la vente de matériel s'est imposée comme étant la meilleure sur ses seules mérites technologiques ? »
C’est surprenant, cette idée comme quoi ce serait le matériel qui aurait permis à Apple de fourguer ses logiciels, plutôt que l’inverse.
@BeePotato
>> Vu ce qu'il existait à l'époque comme concurrence sur architecture PC,
>> c'était bien le meilleur. »
> Non, même pas.
C'était quoi la concurrence dispo sur architecture PC qui était, selon vous, meilleur, à cette époque ? Répondre "non" semble un peu court en argument.
> Apple voulait absolument proposer la meilleure solution, qu’elle considérait être une
> machine complète avec son OS, au lieu d’accepter de se laisser aller à l’approche
> inférieure d’un Mac OS pour PC juste pour tenter de dominer ce marché et d’en
> tirer le profit maximal.
Pourquoi les gens n'ont pas vu que c'était la meilleure solution alors et acheté massivement des macs plutôt que des PC sous windows alors ?
Quand un truc est meilleur, à un moment cela se sait.
Le problème c'est que c'est jamais qu'une histoire de qualité mais de "rapport" qualité / coût pour l'acheteur.
> C’est surprenant, cette idée comme quoi ce serait le matériel qui aurait permis à
> Apple de fourguer ses logiciels, plutôt que l’inverse.
C'est pas *exactement* ce que je dis. Ce que je dis c'est qu'en matière de méritocratie technologie (on parle bien ici de la compétition entre les "meilleures" solutions, non ?), la meilleure s'impose d'elle même de facto, sur ses propres mérites, elle n'a pas besoin d'être forcée - ce qui au contraire est un défaut, car introduit de la dépendence - ce qu'appelle pourtant @fousfous de ses voeux.
Et quand Apple sait/savait avoir une telle technologie, elle l'a systématiquement lié/intégré à un produit matériel afin d'en tirer un maximum de profit. Apple pourrait très bien vendre un FCP X pour Windows ou Linux avec support de CUDA et tout le toutim, par exemple, mais elle préfère le lié à la vente d'un matériel qui, bien souvent, en réduit l'attractivité du coup.
Et du coup, FCP X n'est plus forcément la "meilleure" solution pour tous, parce que tous n'apprécient pas forcément autant un mac que FCP lui même...
@ byte_order : « C'était quoi la concurrence dispo sur architecture PC qui était, selon vous, meilleur, à cette époque ? »
Je trouvais le GEM, même dans sa version « dé-Macintoshisée » nettement meilleur que les versions de Windows contemporaines. Quelques années plus tard, c'était au tour d'OS/2 de proposer mieux que le Windows d'en face.
« Répondre "non" semble un peu court en argument. »
C'est assumé : l'idée était de répondre avec autant d'arguments que ce que présentait l'affirmation à laquelle je répondais. ;-)
« Pourquoi les gens n'ont pas vu que c'était la meilleure solution alors et acheté massivement des macs plutôt que des PC sous windows alors ?
[…]
Le problème c'est que c'est jamais qu'une histoire de qualité mais de "rapport" qualité / coût pour l'acheteur. »
Ben voilà. C'est beau de répondre à ses propres questions. :-)
Un truc peut bien être meilleur, mais s'il est perçu comme trop cher par la plus grande partie de la population, il n'écrasera pas ses concurrents moins chers.
En revanche, on peut noter que le fait que le Mac, même 25 ans après la victoire de Windows sur ses concurrents sur PC, soit toujours là et avec une part de marché loin d'être négligeable alors qu'il continue à être largement perçu comme trop cher, est un indicateur qu'il a vraiment des qualités qu'on ne retrouve pas dans Windows.
@BeePotato
> Un truc peut bien être meilleur, mais s'il est perçu comme trop cher
> par la plus grande partie de la population, il n'écrasera pas ses concurrents moins chers.
Etre meilleur sur un plan et être meilleur globalement, c'est pas la même chose.
Mon argument, c'est prétendre qu'un truc pourtant meilleur sur un ou plusieurs plans aurait dû être le vainqueur c'est oublier qu'il faut "globalement" qu'une offre soit meilleure pour gagner face à d'autres, pas seulement sur des plans particuliers.
> En revanche, on peut noter que le fait que le Mac, même 25 ans après la victoire
> de Windows sur ses concurrents sur PC, soit toujours là et avec une part de marché
> loin d'être négligeable alors qu'il continue à être largement perçu comme trop cher,
> est un indicateur qu'il a vraiment des qualités qu'on ne retrouve pas dans Windows.
Combien de ces qualités sont dû à des préférences pour macOS vs Windows plutôt que PC (ce qu'un Mac est également) vs Mac ?
Il n'est pas certain que si Apple vendait des licences de macOS pour PC compatible macOS n'aurait pas la même part de marché, voir même bien supérieure.
L'endurance d'une solution sur le long terme est assurément un indicateur plus méritocratique, car la durée a donner amplement l'opportunité à d'autres solutions de jouer la concurrence.
Mais c'est valable autant pour le Mac que pour Windows, vouloir faire jouer cet argument que dans un un seul camp me semble hypocrite.
@byte_order
«Pourquoi les gens n'ont pas vu que c'était la meilleure solution alors et acheté massivement des macs plutôt que des PC sous windows alors ?
Quand un truc est meilleur, à un moment cela se sait.
Le problème c'est que c'est jamais qu'une histoire de qualité mais de "rapport" qualité / coût pour l'acheteur.»
Parce que si ce qui a assuré la survie de MacOS et du Mactintosh pendant des decennies c'est la qualité et la fonctionnalité et surtout l'ergonomie, ce qui a a exterminé la diversité de la microinformatique, c'est le monopole Wintel et ses pratiques scelerates.
Jusqu'aux condamnations exemplaires et historiques de Microsoft et d'Intel, le marché etait controlé artificielement a grand coup d'obsolescence programmée, de mise sous contrainte des fabriquants, assembleurs, vendeurs, developpeurt, editeurs... aucune regle meme de base de l'economie de marché n'etaient respectées.
De plus il faut insister sur les depenses marketing massive des deux societes qui en plus integraient le dumping massif et cross-financé pour s'approprier progressivement des secteurs de marchés.
Rajoutons a cela le choix du produit top-down, c'est dire decidé par les dirigeants de l'organisation, administration, institution a cause du marketing mais aussi culturelement - MS et Intel ont toujours ete des membres du sérail, des institutions de l'establishement la ou Apple ou Sun ou Amiga ou Atari,... etaient des pirates, outsider, fabriquants de jouets...-
On ne peut donc expliquer la preeminence de Wintel et la l'extinction de la diversité informatique par une question de selection du meilleur, mais au contraire par des mecanisme inverses de l'economie de marché ou de la selection "darwinienne"!
Ce qui est par contre anormal c'est que depuis la mises hors d'etat de nuire de Wintel, Apple reste cantoné sous les 10% de PDM et que les architectures alternatives n'aient pas vu le jour.
@C1rc3@0rc
> Parce que si ce qui a assuré la survie de MacOS et du Mactintosh pendant
> des decennies c'est la qualité et la fonctionnalité et surtout l'ergonomie
... et la vente liée matos / os. Les Macintosh ont rarement été concurrentiel du strict point de vue caractéristiques techniques, c'est bien sur la qualité de l'OS que cette survie a pu avoir lieu.
> ce qui a a exterminé la diversité de la microinformatique, c'est le monopole Wintel
Monopole construit sur des caractéristiques qui ont trouvé un écho chez la clientèle : retro-compatibilité, architecture matériel modulaire et évolutive. Après la pratique abusive envers les OEM a installé artificiellement plus de licences Windows que son propre mérite l'aurait justifié, mais je ne vois pas en quoi Intel a obtenu un monopole de manière déloyal face aux concurrentes de l'époque. Pourquoi Atari, Commodore, Motorola et même Apple n'ont pas su proposer une plateforme matérielle *et/ou* logicielle plus attractive pour les clients !?
Qu'est-ce qui leur interdisait de proposer eux aussi une meilleure plateforme matérielle, retro-compatible, modulaire, évolutive, plutôt que de considérer l'architecture matérielle comme une boite noire qui n'intéresse pas le client (et qu'on peut donc lui faire racheter plusieurs fois) ?
Ils ont fait un choix d'architecture matérielle, ce n'est pas celui qui a trouvé un écho majoritaire chez la clientèle. A un moment, il faut aussi savoir le reconnaitre : l'architecture PC a survécu mieux qu'autre architecture parce qu'elle a su s'adapter et reste flexible *et* meilleure marché.
L'arrivée d'ARM va peut-être (ou pas) redistribuer la donne, sur ce point.
> mise sous contrainte des fabriquants, assembleurs, vendeurs, developpeurs, editeurs...
> aucune regle meme de base de l'economie de marché n'etaient respectées.
La situation est tellement différente avec le monopole de iOS que... oh, wait!
@C1rc3@0rc
> On ne peut donc expliquer la preeminence de Wintel et la l'extinction de la
> diversité informatique par une question de selection du meilleur, mais au contraire
> par des mecanisme inverses de l'economie de marché ou de la selection "darwinienne"!
La diversité informatique existe toujours, il existe des plateformes tant matérielles que logicielles alternatives (Linux et autres BSD, Raspberry, mais aussi désormais ChromeOS par exemple), mais surtout la plateforme informatique s'est fortement déplacer sur Internet désormais, là où elle est diverse comme jamais.
Prétendre qu'elle s'est éteinte est faux. Elle a changé, elle s'est adaptée à de nouveaux besoins.
> Ce qui est par contre anormal c'est que depuis la mises hors d'etat de nuire de Wintel,
> Apple reste cantoné sous les 10% de PDM et que les architectures alternatives
> n'aient pas vu le jour.
L'architecture alternative, c'est Internet.
La plateforme personnelle n'a plus autant besoin d'être uniforme qu'avant, des couches de compatibilité multiplateforme s'occupant de maintenir une expérience utilisateur comparable quelque soit la plateforme réelle.
C'est pas tant l'architecture qui compte véritablement désormais, mais son interopérabilité avec des usages les plus répandus.
Le multiplateforme n'a jamais été aussi vrai que maintenant.
Même Microsoft et Apple se sont décidés a embrasser des technos non proprio, souvent open-specs si ce n'est pas carrément opensource, c'est dire.
Comparez avec la situation y'a 25 ans...
Excellentes remarques ! +1
windows équipe les PC par default pour ça il a percé. Microsoft ne faisait que des softs à l'époque. tandis que Apple vend des machines, pas des logiciels. leur logiciel équipe exclusivement leur machine plus cher que les PC équipés en Windows.
c'est le prix qui fait la différence tout seul. y a pas de mystère.
@marenostrum
> c'est le prix qui fait la différence tout seul. y a pas de mystère.
Le prix du couple PC + Windows vs Mac + MacOS donc.
Mais si cela n'était qu'une histoire de prix, vu que le PC est une plateforme ouverte sur lequel Microsoft n'avait pas, après la vente du moins, de contrôle, rien n'a empêché l'apparition d'une concurrence à Windows compatible PC. Et moins cher.
Linux, par exemple, marche sur PC depuis longtemps déjà. Et malgré sa totale gratuité qui, couplé à un PC également moins cher qu'un Mac, il n'a pas remplacé Windows.
Je trouve donc, même si personnellement je ne suis pas grand fan de Windows, que penser que Windows n'a aucun mérite propre (et à travers, Microsoft) dans sa part de marché ultra majoritaire indéniable durant tout ce temps, tout ce temps pendant lequel une concurrence au mérite a toujours été possible, est une sorte d'aveuglement.
Les gens ont trouvé et continue de trouver un intérêt suffisant à Windows pour continuer de le choisir, prétendre qu'ils n'ont jamais eu le choix me semble factuellement faux, c'est surtout que le rapport qualité / coût des autres choix n'était pas si meilleur (soit car trop cher, soit car pas assez qualitatif, soit même les deux à la fois) qu'on aime le prétendre.
@fousfous
"Apple devrait obliger les devs à utiliser ses outils."
Mais bien sûr.
Je croyais que Marzipan devait être présent pour 2019 ?
@MonsieurPomme
"Je croyais que Marzipan devait être présent pour 2019 ?"
L'hypothèse la plus probable est qu'Apple présente Marzipan aux développeurs à la WWDC 2018, le 4 Juin (dans 3 semaines), avec mise à disposition d'une version bêta. Mais effectivement il faudra attendre courant 2019 pour la distribution au public des premières applications Marzipan sur l'AppStore. Nous en saurons plus après la WWDC.
L’équivalence natif = Xcode sur iOS et Android Studio sur Android n’est vraie ni dans un sens ni dans l’autre : je peux faire du natif (ie utiliser les frameworks d’UI officiels) avec AppCode sur iOS, ou bien CLion pour du Kotlin Native, voire du React Native avec n’importe quel éditeur de code. Inversement je peux ne pas utiliser les frameworks officiels et utiliser par exemple Android Studio avec Flutter.
Tout ça pour dire que la frontière n’est pas nette dans ce domaine et que limiter une plateforme à son IDE de référence est dommage, car on se prive de toutes les nuances qui existent quand on parle d’app « native ».
Je me pose une question vis-à-vis des langages de développement. Sur Android le Java et le Kotlin sont les langages officiellement supportés sur iOS le Swift et l’Objective-C. En dehors des langages du web, est-ce qu’il n’y a pas moyen de développer en une application multiplateforme (ou quasiment) avec du C++ par exemple ? C’est le genre de langage qui tourne un peu partout, alors est-ce qu’on peut faire une App en C++, l’enrober d’un peu de Java pour Android et d’un peu de Swift pour iOS ?
@ney
"En dehors des langages du web, est-ce qu’il n’y a pas moyen de développer en une application multiplateforme (ou quasiment) avec du C++ par exemple ?"
Oui, Xcode l'outil de développement d'Apple supporte aussi le C++. Mais le langage n'est qu'une partie du problème. Le plus important c'est les frameworks permettant de communiquer avec le système d'exploitation. C'est pourquoi les applications multi-platesformes sont généralement moches et n'exploitent pas les spécificités d'interfaces des OS.
"C’est le genre de langage qui tourne un peu partout, alors est-ce qu’on peut faire une App en C++, l’enrober d’un peu de Java pour Android et d’un peu de Swift pour iOS ?"
Oui
@IceWizard
D’accord donc l’idée ce serait peut-être de développer un cœur en C++ pour les deux App puis d’utiliser Java/Swift pour utiliser les différentes API mises à disposition ?
@ ney : « D’accord donc l’idée ce serait peut-être de développer un cœur en C++ pour les deux App puis d’utiliser Java/Swift pour utiliser les différentes API mises à disposition ? »
C’est en effet une approche régulièrement utilisée : si on tient à ce que la partie « modèle » soit multi-plateformes, la développer en C++ et écrire de façon native la partie interface qui y donnera accès.
Mais ça n’est pas adapté à tout type d’application : pour certaines, le développement de l’interface représente le plus gros du boulot et tenter de séparer une partie susceptible d’être écrite avec un langage multi-plateformes demande plus d’effort que ça n’apporte de gain. Pour d’autres, le cœur de l’application repose aussi sur des bibliothèques proposées par l’OS et il peut alors être plus intéressant de développer des versions iOS et Android complètement séparées (et éventuellement un peu différentes) plutôt que d’essayer de trouver des bibliothèques multi-plateformes équivalentes.
@BeePotato
D’accord merci pour ces précisions ?
@ney
"D’accord donc l’idée ce serait peut-être de développer un cœur en C++ pour les deux App puis d’utiliser Java/Swift pour utiliser les différentes API mises à disposition ?"
C'est souvent ce qui fait pour les jeux vidéo, un domaine où l'interface est spécifique à l'application et non à la plate-forme. Pour le reste, comme le souligne BeePotato, on préféré généralement faire des versions spécifiques pour les applications où l'interface utilisateur est importante.
@IceWizard
D’accord merci. Juste à titre d’informations, iOS supporte le Java ou pas ?
@ney
"D’accord merci. Juste à titre d’informations, iOS supporte le Java ou pas ?"
Euh .. curieuse ta question. iOS ne supporte pas de langage de programmation. Aucun système d'exploitation ne le fait, d'ailleurs. Tout ce qu'un OS est capable de faire c'est exécuter une application en binaire. On peut créer des applications iOS avec n'importe quel langage informatique existant avec un outil conçu pour ça. Par exemple, il existe un outil (payant) pour faire du C# (un langage typiquement Windowsien) sur iOS. Est-ce que quelqu'un a développé son équivalent pour Java ? Je ne sais pas, le Java n'étant pas ma tasse de thé (je suis plutôt Swift et C#). Mais c'est techniquement possible.
D'autres personnes sur ce topic pourront certainement te répondre avec plus de précision.
> Tout ce qu'un OS est capable de faire c'est exécuter une application en binaire.
C'est pas tout à fait exact.
Le support natif d'astuces telle que le Shebang est bien la capacité par l'OS d'exécuter autre chose qu'une application binaire:
https://fr.wikipedia.org/wiki/Shebang
Par ailleurs, certains OS ont bien nativement le support pour compiler à la volée un langage de programmation, ce qui correspond bien à une capacité native à supporter tel langage de programmation.
En amateur, j'essaie de reprogrammer à nouveau avec les bibliothèques de QT, principalement en langage C++. A noter, Xcode "accepte" le langage C++. Je n'en suis pas encore à ce stade mais il semble que le compilateur de xcode/Apple soit nécessaire pour finaliser le programme.
En bref, C++ est aussi dispo chez Apple. QT a ses propres bibliothèques et permet apriori de jongler entre les plateformes (probablement avec les limites du concept).
@ney
C’est possible à l’aide de framework comme Qt
@Mrpantaloon
D’accord merci. Tu aurais des exemples d’app développées à l’aide de Qt ?
> mais rappelons qu'Apple et Google font payer la publication d'une app sur l'App Store
> et Google Play.
Tant qu'a rappeler les coûts câchés, rappelez-les avec tous les détails :
- $25 une seule fois pour publier sur Google Play,
- $99 chaque année pour l'App Store (et le MAS).
On peut également prendre en compte que rien ne vous oblige à acheter une machine particulière pour utiliser Android Studio, qui est dispo pour Linux, Windows ou même macOS.
Alors que dans le prix initial côté App Store, faut inclure l'achat d'un mac si on en avait pas déjà un.
je peux me tromper, mais n'y a-t-il pas plus de jeux sur iOS que sur Android ? et donc plus de développeurs Unity sur iOS ?
Le ratio App/Game pourrait etre intéressant aussi à connaitre sur les 2 plateformes.
@macG
Vous oubliez celui qui monte le plus : react native.
C’est du dev multiplateforme mais comparé à cordova, c’est nettement plus rapide, et on peut développer nos propres passerelles et ainsi tirer puissances des dernières nouveautés de chez Apple. Je l’ai fait plusieurs fois et depuis je ne développe quasiment plus en swift...
Il n'est pas oublié, mais sa PdM est encore faible (1.85%).
Après, pour mesurer sa progression, il faudra attendre les prochains chiffres :)
Xcode et Android Studio ont-ils des moyens simples de partir d’un projet Xcode pour crée un projet Android ou inversement ?
Pour réutiliser quoi ? Le code Swift pour iOS dépend d'API non disponible sur Android, et le code Java/Kotlin pour Android dépend d'API non disponible sur iOS.
A part pour réutiliser du code portable style C/C++, mais s'il est portable y'a déjà des projets xcode et as existants pour les compiler.
Ca parle des feignants de développeurs (copyright fousfous) mais c'est bien souvent plutôt les boites de dev ou les commanditaires qui ne veux pas payer 2x plsu cher pour un dev sur android et ios.
Honnêtement comment leur en vouloir d'être ok pour payer 50 000 mais pas 100 000 € pour une app ? avec réact-native, on a au final des composants natifs sur les 2 plateformes avec les spécificités de chacune...
Et que dire de faire des jeux en 3D avec les outils apple ou google.... c'est pas bien puissant tout ca ! pas étonnant de voir unity à 30% de PDM
Toutafé.
Y'a pas de raisons que la recherche d'une rentabilité et des réductions des coûts ne soient valable que quand c'est Apple qui la recherche.
C'est valable pour tous.
Si Apple veut imposer des outils de dev natifs, c'est à elle de trouver le moyen (légal...) de convaincre les développeurs que c'est dans *leur* intérêt à eux, les devs, et non pas comme aujourd'hui surtout dans son intérêt à elle.
Enfin, ça, même Apple sait qu'elle ne peut pas vraiment l'imposer de force. Ya que @fousfous en fait qui le pense, à l'occasion...
Z'êtes lourds.
"En 2017, 90 % des apps sur Android étaient réalisés avec Android Studio. Un chiffre en progression de 17 point par rapport à l'année précédente. Sur iOS, Xcode n'est utilisé que dans 76 % des cas"
Mais grosse différence, les outils de développement de Google tournent aussi bien sur Mac que Linux ou Windows. Ce qui n'est pas le cas de Xcode qui reste concentré sur MacOS, même pas sur iOS.
Oui, cela participe en effet à l'audience très large d'Android Studio.
Entre les $25 pour avoir le droit de publier une app développé avec un IDE gratuit qui peut fonctionner sur n'importe quel de vos ordinateurs, qu'ils soient Windows, Mac ou Linux, et les $99 chaque année +plus+ l'achat d'un mac à $1000 minimum si vous n'en aviez pas un déjà, les coûts d'accès ne sont pas les mêmes, et cela se ressent fatalement en terme d'adhésion à l'outil natif.