Swift, Objective-C, C++, Kotlin et Java sont dans un bateau...

mars 2019 modifié dans Xcode et Developer Tools #1
Cette discussion a été créée à partir de réponses séparées de : iMac mars 2019.
«13

Réponses

  • PyrohPyroh Membre

    @LeChatNoir a dit :

    @muqaddar a dit :

    @LeChatNoir a dit :
    J'ai gardé mon MBP qui ne me sert plus que de machine de dev.
    Ca aussi c'est scandaleux (qu'Apple propose pas un XCode Windows).

    Ne pas payer ses impôts en France sur ce qui est vendu en France, ça c'est scandaleux.
    Par contre, imposer un Mac pour développer sur iOS, je ne trouve pas ça scandaleux. D'une part, ça force à acheter des Mac, d'autre part, ça évite un second développement Windows (et un second simulateur !). Il faut toujours se demander: si j'étais à la tête de la division, est-ce que je ne ferai pas pareil ?

    Clairement non, je ne ferai pas pareil. Google propose son Android Studio sur toutes les plateformes. La fermeture de l'eco système, ca marchait quand ils étaient premiers, précurseurs. Aujourd'hui, ils n'ont plus rien de précurseurs et la concurrence est là ; c'est le moment de s'ouvrir selon moi.

    Si tu veux mon avis le choix de conserver Xcode en exclu macOS n'est pas que politique mais aussi (et surtout) technique. Il ne faut pas oublier que le simulateur iOS est bien un simulateur et non un émulateur ce qui fait qu'on compile du code x86_64 qui tourne directement sur la machine hôte. Il faudrait pour ça un compilo Obj-C et Swift adapté aux machines Windows ce qui est loin d'être le cas. Et je ne parle pas des API qui s'appuie en grande partie sur le système.
    Android Studio c'est du Java, le simulateur c'est du Java tout ça tourne sur une smart-cafetière si on veut.

  • @Pyroh a dit :

    Il ne faut pas oublier que le simulateur iOS est bien un simulateur et non un émulateur ce qui fait qu'on compile du code x86_64 qui tourne directement sur la machine hôte.

    Il faudrait pour ça un compilo Obj-C et Swift adapté aux machines Windows ce qui est loin d'être le cas.

    Il n'y a pas comme une contradiction dans tes deux phrases ? Le compilateur d'Xcode peut générer aussi bien du code ARM que du code x86_64, tournant sur un processeur intel (ou AMD).

    Et je ne parle pas des API qui s'appuie en grande partie sur le système.

    Le simulateur iOS fonctionne avec une version d'iOS Intel adapté à MacOS. Recréer la même pour Windows n'est pas follement compliqué et totalement à la portée d'Apple. Une petite équipe pourrais le faire en moins d'un an.

    Il a fallu à Steve Job des années pour se convaincre qu'il fallait porter iTunes sur Windows, ce qui a ensuite ouvert d'immenses possibilités commerciales à Apple. (On est d'accord, Xcode Windows n'aura aucun intérêt financier pour Cupertino !).

    Le refus de porter Xcode sur Windows est un choix politique, pas technique ..

  • PyrohPyroh Membre

    @Draken a dit :
    Il n'y a pas comme une contradiction dans tes deux phrases ? Le compilateur d'Xcode peut générer aussi bien du code ARM que du code x86_64, tournant sur un processeur intel (ou AMD).

    Si Xcode génère du code ARM c'est du cross compiling ce qui pris en charge actuellement et ne pose pas de soucis. Seulement pour le simulateur il faut compiler du code pour la machine hôte (donc un Mac actuellement) ce qui fait que si cette machine tourne sous Windows il faut adapter le compilateur. On aurait un émulateur ça ne poserai pas de soucis vu qu'il ferait tourner du code ARM.
    Donc non pas de contradiction a priori.

  • LeChatNoirLeChatNoir Membre, Modérateur
    mars 2019 modifié #5

    A la grande époque, c'était un cercle vertueux. Tout le monde se ruait sur le dev iOS et donc achetait un mac. Aujourd'hui, ce n'est plus un cercle vertueux ; les macs sont devenus hors de prix et et le nb de dev risque de baisser.

    Pour ma part, dans le monde de l'escalade, à ce jour, si tu cherches ce mot clé sous iOS, tu trouves 3 / 4 apps max. Sous Android, tu en trouves facilement une petite vingtaine. Ce sont des signes...

    Pour mon app, l'année dernière, les ventes étaient à l'équilibre iOS/Android. Cette année, Android est en train de dépasser allègrement l'app iOS.

    Alors je sais, mon app est une app de niche, surement loin d'être représentative de la réalité. Mais force est de constater que la tendance change.

  • @LeChatNoir a dit :

    Pour mon app, l'année dernière, les ventes étaient à l'équilibre iOS/Android. Cette année, Android est en train de dépasser allègrement l'app iOS.

    Il y a tellement plus de pauvres sur terre ..

  • klogklog Membre
    mars 2019 modifié #7

    @LeChatNoir a dit :
    Pour ma part, dans le monde de l'escalade, à ce jour, si tu cherches ce mot clé sous iOS, tu trouves 3 / 4 apps max. Sous Android, tu en trouves facilement une petite vingtaine. Ce sont des signes...

    Pas des signes de qualité... ;)

    @LeChatNoir a dit :
    Pour mon app, l'année dernière, les ventes étaient à l'équilibre iOS/Android. Cette année, Android est en train de dépasser allègrement l'app iOS.

    Les ventes iOS ont-elles diminuées ?
    Ou sont-ce celles d'Android qui ont grandement augmentées ?

  • Ouais, mais l'homme se fait à tout ! même à sa femme, mais parfois difficilement !

  • @klog a dit :

    Les ventes iOS ont-elles diminuées ?
    Ou sont-ce celles d'Android qui ont grandement augmentées ?

    Bonne question. Je suis curieux de le savoir ..

  • @LeChatNoir a dit :
    A la grande époque, c'était un cercle vertueux. Tout le monde se ruait sur le dev iOS et donc achetait un mac. Aujourd'hui, ce n'est plus un cercle vertueux ; les macs sont devenus hors de prix et et le nb de dev risque de baisser.

    Pour ma part, dans le monde de l'escalade, à ce jour, si tu cherches ce mot clé sous iOS, tu trouves 3 / 4 apps max. Sous Android, tu en trouves facilement une petite vingtaine. Ce sont des signes...

    Pour mon app, l'année dernière, les ventes étaient à l'équilibre iOS/Android. Cette année, Android est en train de dépasser allègrement l'app iOS.

    Alors je sais, mon app est une app de niche, surement loin d'être représentative de la réalité. Mais force est de constater que la tendance change.

    C'est à force de faire tomber son téléphone pour prendre un selfie à 4m de haut, il n'apprécie pas la chute. Alors en force d'en racheter, on finit par en prendre des moins onéreux du côté Android :p

  • LeChatNoirLeChatNoir Membre, Modérateur

    Ouais. Moins onéreux et qui tiennent bien la charge ;)

    A la louche, je dirai légère baisse sur iOS et forte augmentation sur Android. Mais faudrait que je creuse un peu plus...

  • @LeChatNoir a dit :
    Ouais. Moins onéreux et qui tiennent bien la charge ;)

    A la louche, je dirai légère baisse sur iOS et forte augmentation sur Android. Mais faudrait que je creuse un peu plus...

    T'as utilisé quel outil pour le développement Android ?

  • LeChatNoirLeChatNoir Membre, Modérateur

    Android Studio pourquoi ?

  • Oui, évidement.. Mais Java ou Kotlin ?

  • LeChatNoirLeChatNoir Membre, Modérateur

    @klog a dit :

    @LeChatNoir a dit :
    Pour ma part, dans le monde de l'escalade, à ce jour, si tu cherches ce mot clé sous iOS, tu trouves 3 / 4 apps max. Sous Android, tu en trouves facilement une petite vingtaine. Ce sont des signes...

    Pas des signes de qualité... ;)

    Certes. Mais signe de dynamisme.

    @Draken a dit :
    Oui, évidement.. Mais Java ou Kotlin ?

    Java !

  • @LeChatNoir a dit :
    Java !

    Beurk ...

  • Kotlin c'est le swift de l'obective-C sauf qu'il y a beaucoup moins de matraquage/harcèlement

  • @Harlo a dit :
    Kotlin c'est le swift de l'obective-C sauf qu'il y a beaucoup moins de matraquage/harcèlement

    C'est uniquement dans ta tête, ce matraquage/harcèlement !

  • Non non, quand tu poses une question sur stackoverflow en précisant que tu fais objective-C y'en a toujours pour te donner une réponse en swift uniquement.
    Dans les moteurs de recherche, t'as beau préciser Objective-c t'aura un maximum de réponse en swift.
    Pas mal de site montrant des méthodes ont dégagé la partie objective-c pour n'y mettre que du swift en exemple.
    Quand tu regardes des commentaire sur des projets objective-c sur github y'en a toujours à pleurer pour que ça passe en swift.
    etc.

    Quand je me suis inscrit ici en précisant que je partais sur de l'objective-C tu as été le premier à me dire que je ferais mieux de faire en swift et il m'a fallu justifier mon choix.

    premier message, première réponse

    @Draken a dit :

    @Harlo a dit :

    et depuis peu Objective-C sur Mac.

    Euh .. oublie ça très vite, surtout si tu débute. Swift est beaucoup plus facile à apprendre pour un novice.

  • @Harlo a dit :

    Quand je me suis inscrit ici en précisant que je partais sur de l'objective-C tu as été le premier à me dire que je ferais mieux de faire en swift et il m'a fallu justifier mon choix.

    Tu as oublié le "surtout si tu débutes" de ma réponse, ainsi que "plus facile à apprendre pour un novice". Tes questions laissaient à penser que tu étais un débutant en programmation, ce qui n'est pas le cas. Et je n'étais pas le seul à le dire.

    Pour le reste, bah oui, Swift est en train de remplacer l'Objective-C, dans le coeur des développeurs, sur les forums et probablement bientôt dans tous les gros développements.

  • Ben je suis débutant en programmation pourtant, 3 petites applis en Java et ma première en objective-C.

    Tout les gros développement j'ai un doute, dans le libre en tout cas, il y a beaucoup de réfractaire à Xcode qui se tournent et incitent à aller vers QT. Chez les pros je doute aussi que des applis adobe, microsoft ou autre fassent leur truc en swift. Obejctive-C n'est pas des plus performant mais swift a l'air de l'être encore moins d'après mes lectures.

    Perso j'y vois surtout un langage "jetable" pour des petites/moyennes applications qui doivent rapporter un maximum d'argent en un minimum de temps. Son avenir (et celui d'apple) est surtout là mais pour de gros projets bien lourd qui doivent durer dans le temps j'ai quand même des doutes.

  • @Harlo a dit :

    Perso j'y vois surtout un langage "jetable" pour des petites/moyennes applications qui doivent rapporter un maximum d'argent en un minimum de temps. Son avenir (et celui d'apple) est surtout là mais pour de gros projets bien lourd qui doivent durer dans le temps j'ai quand même des doutes.

    Pour ce qui est du code "jetable" je comprends. Il est difficile de considérer un langage comme pérenne alors que sa syntaxe n'est pas stable (ni même son ABI mais c'est un lien de causalité). Il y avait de gros changements entre les versions ce qui rendait le code incompilable sans modification d'une release sur l'autre au début.
    Mais ce qui était vrai entre les versions mineures à l'époque de la 1.x puis entre les versions majeures à partir de la 2.1 n'est plus vrai aujourd'hui. Les modifications sont souvent majoritairement additives et l'ABI est stabilisée dans la version 5.0 qui sort normalement ce soir en version de PROD (ou dans les jours qui viennent).

    Et je trouve que c'est la force de Swift, un langage qui a été développé au grand jour avec une prise en compte de ce que voulait la communauté des devs. Pour qui a suivit les péripéties depuis juin 2014 c'est aisé de comprendre certains choix et que même dans un langage de programmation tout est affaire de compromis.

    Au final on a un très bon langage (j'en connais un paquet je ne dis pas ça par dessus la jambe), multi-usage, scriptable et open-source. C'est une entreprise qui est faite pour durer et maintenant que l'ABI est stable et disponible dans les systèmes l'adoption va s'accélérer.

    Pour ce qui est des projets qui doivent durer dans le temps je pense que tu te fais des idées sur la manière dont sont gérés les projets que tu qualifie de gros. Tu as déjà les cycles de renouvellement des systèmes d'exploitation.

    Chaque fois qu'une version majeure d'iOS ou macOS sort il y a des adaptations à faire, déjà parce que les APIs changent ou parce que des ruses de sioux ne fonctionnent plus correctement d'un système à l'autre. Puis il y a les nouvelles fonctionnalités à intégrer les nouveauté apportées avec la release de l'année. Y'a un gros changement tous les ans si c'est pas le support du versioning des documents ou de CloudKit c'est un nouveau mode sombre.

    Ce qui fait que le projet qui végète dans son coin et qui est vaguement recompilé d'années en années c'est plus un mythe qu'autre chose. Les gros projets sont dynamiques surtout sur mobile et démarrer un projet Obj-C only est une hérésie. Et j'ai relu tes arguments, si ils te conviennent je le respecte mais moi il ça ne me convint pas 😉

  • klogklog Membre
    mars 2019 modifié #23

    @Draken a dit :
    Pour le reste, bah oui, Swift est en train de remplacer l'Objective-C, dans le coeur des développeurs, sur les forums et probablement bientôt dans tous les gros développements.

    Ce n'est pas qu'une question de coeur... Et tant que Swift n'est, par exemple, pas capable de communiquer directement avec C++, il se coupe de tous les gros développements dont tu parles. Il existe des milliers de bibliothèques en C++, et il est impossible de réinventer la roue en Swift pour chacune.

  • @klog a dit :

    @Draken a dit :
    Pour le reste, bah oui, Swift est en train de remplacer l'Objective-C, dans le coeur des développeurs, sur les forums et probablement bientôt dans tous les gros développements.

    Ce n'est pas qu'une question de coeur... Et tant que Swift n'est, par exemple, pas capable de communiquer directement avec C++, il se coupe de tous les gros développements dont tu parles. Il existe des milliers de bibliothèques en C++, et il est impossible de réinventer la roue en Swift pour chacune.

    T'as des exemples en dehors de macOS ? (même macOS ça m'intéresse)

  • klogklog Membre
    mars 2019 modifié #25

    @Pyroh a dit :

    @klog a dit :

    @Draken a dit :
    Pour le reste, bah oui, Swift est en train de remplacer l'Objective-C, dans le coeur des développeurs, sur les forums et probablement bientôt dans tous les gros développements.

    Ce n'est pas qu'une question de coeur... Et tant que Swift n'est, par exemple, pas capable de communiquer directement avec C++, il se coupe de tous les gros développements dont tu parles. Il existe des milliers de bibliothèques en C++, et il est impossible de réinventer la roue en Swift pour chacune.

    T'as des exemples en dehors de macOS ? (même macOS ça m'intéresse)

    Des exemples de quoi ? De bibliothèques en C++ ? T'es sérieux ?
    Et oui c'est du point de vue macOS dont je parle essentiellement... Mais Swift n'est-il pas censé représenter l'avenir du dev sur tous les systèmes Apple ? S'il s'agit d'un langage entièrement dévolu à iOS, c'est que j'ai raté un truc...

  • Mouaip, je viens de télécharger un client MPD codé en swift loin d'être terminé, histoire de voir.

    Taille final de mon application 1.5Mo, taille de la sienne 28Mo. Quand je regarde dedans y'a tout plein de libswiftXXX qui sont embarqué.

    Moi qui aime bien chipoter pour optimiser au maximum l'utilisation du CPU/RAM/HDD, j'aime pas du tout ça.

    'fin bon, le type ne doit pas être doué non plus, son appli tourne avec 70% de charge CPU en continu même à l'arrêt O_ô.

    Avec mes 0,8% en utilisation je passe pour un expert à coté :D

  • @klog a dit :

    Des exemples de quoi ? De bibliothèques en C++ ? T'es sérieux ?

    Oui des lib C++ je n'en ai jamais utilisé pour du dec macOS/iOS, sérieusement. Qt ne compte pas parce que c'est largement dispensable sur macOS (amha)...

    @klog a dit :

    Et oui c'est du point de vue macOS dont je parle essentiellement... Mais Swift n'est-il pas censé représenter l'avenir du dev sur tous les systèmes Apple ? S'il s'agit d'un langage entièrement dévolu à iOS, c'est que j'ai raté un truc...

    Là on touche à un autre soucis : macOS est devenu un citoyen de seconde zone chez Apple 😧. Je suis le premier à le déplorer.

  • klogklog Membre
    mars 2019 modifié #28

    @Pyroh a dit :

    @klog a dit :

    Des exemples de quoi ? De bibliothèques en C++ ? T'es sérieux ?

    Oui des lib C++ je n'en ai jamais utilisé pour du dec macOS/iOS, sérieusement. Qt ne compte pas parce que c'est largement dispensable sur macOS (amha)...

    Je ne sais pas, il y en a tellement ! Tout projet objet qui se veut multi-plateforme envisage toujours le C++ comme la principale alternative...

    Pour moi, un exemple caractéristique et parlant (que j'utilise), c'est une lib très pro et très utile, et qui ne pourrait pas être autre chose que du C++ (objet indispensable, cross platform, automatiquement générée avec un moteur open source qui appartient à une tiers, à partir des spécifications d'un autre tiers)... Il s'agit de lib-ifc créée par le CSTB. La lib contient des centaines d'objets C++, donc impossible de créer une passerelle Swift facilement. Tu vas me dire que c'est un projet anecdotique, mais les exemples sont légion... Intel et AMD fournissent par exemple pas mal de bib C++.

    Sans parler de l'open source. Si tu cherches un peu (sur GitHub par exemple) tu verras que le nombre de projets C++ outrepasse largement le nombre de projets C ou Objective-C (je ne parle même pas de Swift qui n'est pas dans le top 10)...

    Donc amha, que ce soit sur macOS ou sur iOS, dès que tu veux aller vers des applications sérieuses, tu as besoin de réutiliser du code ou des libs, et si Swift ne s'ouvre pas un peu plus, il restera restreint au microcosme Apple.

    Franchement, qu'est-ce qui empêche techniquement Apple de faire avec Swift ce qu'elle a fait avec Objective-C, en permettant une certaine interopérabilité de C++ dans du code Swift ? À mon avis rien... Il s'agit vraisemblablement d'une restriction volontaire, dont l'objet est peut-être de maintenir captifs les développeurs iOS.

  • CéroceCéroce Membre, Modérateur

    Franchement, qu'est-ce qui empêche techniquement Apple de faire avec Swift ce qu'elle a fait avec Objective-C, en permettant une certaine interopérabilité de C++ dans du code Swift ? À mon avis rien...

    Et le manque de temps et d'ingénieurs assez qualifiés, ça ne compte pas ?
    Tu n'as aucune idée de la difficulté de la tâche. Rien que la gestion mémoire (ou plutôt son absence) en C++ rend l'interopérabilité avec Swift très difficile.

    Il s'agit vraisemblablement d'une restriction volontaire, dont l'objet est peut-être de maintenir captifs les développeurs iOS.

    Oui, il s'agit d'une restriction volontaire, mais il n'y a pas besoin d'explications complotistes.
    Les ingés d'Apple doivent se fixer des priorités. La stabilité des ABI qui arrive seulement avec Swift 5 aura certainement beaucoup plus d'impact pour la plupart des programmeurs Swift que l'interopérabilité avec C++ (qui n'est pas impossible, mais qui oblige à passer par Objective-C).

  • klogklog Membre
    mars 2019 modifié #30

    @Céroce a dit :

    Franchement, qu'est-ce qui empêche techniquement Apple de faire avec Swift ce qu'elle a fait avec Objective-C, en permettant une certaine interopérabilité de C++ dans du code Swift ? À mon avis rien...

    Et le manque de temps et d'ingénieurs assez qualifiés, ça ne compte pas ?
    Tu n'as aucune idée de la difficulté de la tâche.

    Bien entendu, contrairement à toi, j'en sais absolument rien... :/

    Rien que la gestion mémoire (ou plutôt son absence) en C++ rend l'interopérabilité avec Swift très difficile.

    Ils l'ont bien fait il y a 10 ans avec Objective-C et ARC, totalement compatibles avec C++... Et il n'est même pas nécessaire qu'ils permettent l'inclusion de code C++ directement à l'intérieur de code Swift. Simplement que soit possible l'import de modules C++, l'allocation d'objets C++, et leurs utilisations en Swift, en suivant la syntaxe Swift s'il le faut. Rendre compatibles des langages de programmation n'a rien d'extraordinaire, et c'est pratiqué depuis des lustres...

    Il s'agit vraisemblablement d'une restriction volontaire, dont l'objet est peut-être de maintenir captifs les développeurs iOS.

    Oui, il s'agit d'une restriction volontaire, mais il n'y a pas besoin d'explications complotistes.

    J'ai bien précisé "peut-être"... Loin de moi toute idée "complotistes"... Que tu mésestimes mes compétences, passe encore, mais pour le coup je te trouve un poil agressif... Mon avis vaut le tien, et on peut ne pas être d'accord sans disqualifier ou méjuger son interlocuteur.

    Les ingés d'Apple doivent se fixer des priorités. La stabilité des ABI qui arrive seulement avec Swift 5 aura certainement beaucoup plus d'impact pour la plupart des programmeurs Swift que l'interopérabilité avec C++ (qui n'est pas impossible, mais qui oblige à passer par Objective-C).

    Je radote, mais je t'invite à écrire une passerelle C++/Objective-C/Swift pour une bibliothèque de plusieurs dizaines d'objets... Les développeurs ont autres chose à f...aire que de se coltiner de la glue. Tu crois franchement qu'Office, Photoshop, Autocad, Cinéma 4D, Final Cut, sont totalement écris en Objective-C ? Ce qui concerne l'interface l'est certainement, mais le moteur de ces softs, multi-plateforme, est vraisemblablement en C++. Ces boites ne vont pas réécrire des dizaines de millions de lignes de codes en Swift parce qu'il est incompatible avec C++. Je pense qu'elles basculeront peut-être un jour à Swift quand :

    1) Apple leur permettra de faire migrer progressivement leur code (donc en préservant Objective-C)
    2) Apple rendra Swift compatible avec C++.

    En attendant, tant qu'Objective-C++ et sa compatibilité C++ est maintenu, et que je peux continuer à donner mon avis, ça me convient... B)

  • Objective-C vaincra \o\ \o/ /o/ :D

Connectez-vous ou Inscrivez-vous pour répondre.