Journal Miguel, iPhone et développement

Posté par  .
Étiquettes : aucune
8
14
sept.
2009
Novell, par la voix du sémillant Miguel de Icaza, annonce un kit de développement .Net / C# pour iPhone (1)

Loin de moi le souhait / la crainte de vouloir relancer le débat "apple bien/pasbien", car nous sommes d'accord, ça pue, c'est pas libre, et en plus bouh ils gagnent de l'argent / yapa flash / j'en ai pas (rayez la mention inutile)

Seulement, mon côté geek à moi fait qu'une fois un iPhone en ma possession (achat professionnel) j'ai voulu développer^W tester le développement sur cette plate-forme, pour tester la mise en oeuvre de ces nouvelles fonctionnalités et ergonomie (2) pour faire l'interface entre homme et machine.

Apple contrôle très fermement le modèle de développement logiciel sur iPhone : en plus d'être très logiquement seuls à bord donc seuls à décider des APIs, ils ont choisi :
- D'imposer leur plate-forme complète (matériel Apple + logiciel MacOSX), alors que pour d'autres produits ils sont davantage ouverts : e.g. iTunes est disponible sous Windows.
- De faire payer la diffusion d'applications (abonnement développeur : 99$ de mémoire), même si l'on souhaite seulement développer un logiciel gratuit.

J'ai donc arrêté bien vite mon souhait de tester le développement sur iPhone : pas de Mac en ma possession (bon allez, un hackintosh aurait permis le test, mais en totale violation de plein de choses) et surtout pas envie de payer 99$ le test.

Mais je m'intéresse donc toujours à ce sujet qu'est le développement sur iPhone, et je suis surpris de voir un tel produit "hors Apple" sortir. Surpris, parce que encore une fois, l'image donnée par Apple est loin de cette absence de contrôle : hormis les points évoqués ci-dessus, notons l'omniprésence de l'aspect marketing (mise en scène très travaillé de leurs annonces produits), chasse aux explications de jailbreak/hackintosh dans la communauté Mac non-underground sur internet, et surtout politique plus que prudente (et surtout peu lisible / compréhensible parfois) de validation d'applications sur leur magasin de vente en ligne.

L'accès aux fonctionnalités de leurs produits (iPhone OS, Mac OS X) se fait me semble-t-il exclusivement par leurs API très spécifiques. La source (1) précise bien "Developers can take advantage of native iPhone APIs". Qu'a donc choisi Novell comme solution technique ? Se sont-ils contentés d'encapsuler les APIs existantes via une couche Mono/C# ? Quid des performances ? De la mise à jour du kit Novell selon les MàJ Apple ? Qu'est devenu l'ancien foie de Steve Jobs ?

Merci cher bouchot de vos explications sur le sujet.

PS : Oui mettre Miguel dans le nom du journal fait vendre^W lire.

(1) Source : http://www.infoworld.com/d/developer-world/iphone-gets-net-a(...) via http://www.mac4ever.com/news/47746/un_environnement_de_devel(...)

(2) Nouvelles IHM pour Mme Michu, on va dire. Donc pour moi y-compris, n'étant pas propriétaire d'une Wii, ou encore d'une table Microsoft Surface ou équivalent.
  • # ouaip

    Posté par  (site web personnel) . Évalué à 10.

    Se sont-ils contentés d'encapsuler les APIs existantes via une couche Mono/C# ?
    En gros c'est ça.
    Ils utilisent la compilation AOT (AheadOfTime) pour produire un exécutable natif pour l'iPhone, ce dernier interdisant toute technique de JIT (JustInTime).
    A côté ils fournissent un wrapper sur les API iPhone comme ils le font pour GTK ou autre, et un plugin de dev pour l'IDE MonoDevelop.
  • # Ce sera "commercial", aussi

    Posté par  . Évalué à 10.

    Extrait de l'article :
    Although Mono is associated with the LGPL (GNU Lesser General Public) license used for distributing free and open source software, Novell with MonoKit is distributing Mono under commercial terms. The LGPL requires that users can replace an LGPL library with their own version of a library, a conflict with App Store requirements, according to Novell.
    Donc, ce "kit" sera sous une licence "commerciale", ce qui veut dire (selon moi) qu'on aura peut-être les sources (mais c'est pas sûr) mais surtout que ce ne sera pas une licence libre.

    Les contributeurs de Mono qui ont donné leur copyright à Novell peuvent dire merci.
    • [^] # Re: Ce sera "commercial", aussi

      Posté par  . Évalué à 5.

      Mono est je crois sous licence MIT/X11. Les contributeurs savent bien ce qu'ils font et peuvent (comme tout le monde) faire une version commerciale de Mono si ça leur chante.

      Où est le problème ?
      • [^] # Re: Ce sera "commercial", aussi

        Posté par  (site web personnel) . Évalué à -7.

        Le problème est que Novell et Icaza sont des collabos qui nous les cassent avec leurs tentatives pour nous entourlouper. Vivement que Novell fasse faillite et qu'Icaza prenne sa retraite.
      • [^] # Re: Ce sera "commercial", aussi

        Posté par  . Évalué à 4.

        Ha, effectivement, il y a des subtilités : les classes sont sous MIT/X11, le compilateur est sous GPL. Je me suis fait avoir par le "associated with LGPL".

        Si quelqu'un a plus d'infos, je suis preneur (j'avoue que je ne connais pas énormément le projet).

        Donc, ma dernière remarque est en partie fausse. Par contre, ça reste toujours "commercial" (j'aimerais bien qu'ils filent plus de détails quand même).
        • [^] # Re: Ce sera "commercial", aussi

          Posté par  . Évalué à 4.

          Le compilateur, le framework de base sont libres, c'est disponible dans le SVN. En revanche, les APIs spécifique à MonoTouch sont closed source et sans code externe à Novell.
          Unity un framework destiné aux jeux (propriétaire) propose depuis longtemps un SDK iPhone utilisant le compilateur AOT, de nombreux jeux basés dessus sont même disponible dans l'AppStore.
          • [^] # Re: Ce sera "commercial", aussi

            Posté par  (site web personnel) . Évalué à 4.

            c'est un peu ce qui nous embête d'ailleurs avec ta dépêche en modération GeneralZod ;-) Outre que ce n'est pas libre, cela ne fonctionne pas sous Linux non plus :/
            • [^] # Re: Ce sera "commercial", aussi

              Posté par  . Évalué à 2.

              Vu que c'est basé sur un framework libre, j'ai pensé que ça pouvait être intéressant. De plus, entre la fondation Codeplex et MonoTouch, ces derniers temps, MDI cartonne dans le troll de compétition, à croire qu'il fait exprès. :-)
              Après, je comprendrais que l'équipe refuse la dépêche parce que c'est bordeline mais c'est mieux que de ne rien proposer du tout. ;-)
              • [^] # Re: Ce sera "commercial", aussi

                Posté par  (site web personnel) . Évalué à 2.

                Ah bah, c'est l'angle d'attaque qu'il faut trouver dans ces cas-là (mais un "Miguel, sa vie, son oeuvre", ça risque vite de tourner au pugilat /o\). Pour cette fois, c'est juste HS quoi, comme si on mettait seulement dans une dépêche que l'upgrade de 7 peut prendre jusqu'à presqu'un jour : c'est bon pour slashdot, mais ce n'est pas l'esprit - ni la charte - de linuxfr ;-) Dommage, comme dit farvardin, la peste et le cholera en même temps, ya pas à choisir :)
            • [^] # Re: Ce sera "commercial", aussi

              Posté par  . Évalué à 8.

              Réunir dans un seul projet les technologies de chez Apple et de chez Microsoft, cela évite d'avoir à choisir entre la peste et le choléra.

              (ps : j'ai quand même plussé le journal car il est bien écrit et amusant)

              Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

        • [^] # Re: Ce sera "commercial", aussi

          Posté par  . Évalué à -2.

          Je n'ai jamais compris pourquoi Novell a changé la licence des bibliothèques de classes de la GNU LGPL à la licence MIT.
  • # Ah, Miguel ...

    Posté par  . Évalué à 10.

    Le parti socialiste a Jack Lang, les libristes ont Miguel de Icaza.
    • [^] # Re: Ah, Miguel ...

      Posté par  . Évalué à 0.

      Je me faisais la même réflexion, mais avec Eric Besson. Et bien, tiens-toi bien, ca marche pareil.

      La méthode est classique : trouver un mec d'accord avec tes idées et faire croire qu'il représente la majorité. C'est la même chose quand le gouvernement discute avec des syndicats ultra-minoritaires.

      Dernier exemple en date : Hortefeux allant chercher la LICRA (association tres UMP-friendly) pour se racheter une bonne conduite anti-raciste.

      http://fr.news.yahoo.com/4/20090914/tsc-france-hortefeux-lic(...)
  • # Ce n'est pas sale de se MonoToucher

    Posté par  (site web personnel) . Évalué à 6.

    Oui, MonoTouch est un logiciel propriétaire et closed-source, se basant sur Mono, qui est lui complètement libre et open-source.

    On peut séparer logiquement MonoTouch en deux parties. Tout d'abord le runtime, très léger, qui est écrit en Objective-C, et qui utilise Mono. Il fait office de glue entre le runtime objective-c et le runtime Mono. Après il y a les bibliothèques de classes en C#, qui wrappent les API de l'iPhone. Concrètement cela permet d'écrire des applications pour iPhone en C#.

    Techniquement, MonoTouch compile en code natif l'application en utilisant le compilateur AOT de Mono. Le runtime Mono à l'exécution est toujours nécessaire pour le garbage collector, et toute la partie méta-données, mais le JIT n'est pas utilisé (et n'est même pas incorporé). Du coup pour les performances il y a une légère pénalité au démarrage de l'application, le temps de chauffer la VM, mais ensuite c'est du code natif qui s'exécute, et comme il est pré-compilé et pas jitté, les performances sont sensiblement semblables à du code natif traditionnel.

    Ça fait un bout de temps que Mono est déjà utilisé comme ça, des dizaines et des dizaines de jeux disponibles sur l'AppStore utilisent Mono, quand ils sont écrit avec Unity3D, un environnement de développement de jeu. Seulement MonoTouch offre la possibilité d'écrire des applications qui utilisent les APIs de l'iPhone. Après tout, quand l'application est poussée vers Apple pour validation, elle ne contient plus que du code natif et des méta-données. Pas d'interpréteur, pas de JIT compilation, donc pas de problème. Enfin pas plus de problème qu'une autre application, après c'est Apple qui valide. Ou pas.

    Donc oui, c'est commercial. Il faut dire qu'Apple interdit de lier dynamiquement des bibliothèques, de sorte que MonoTouch doit lier statiquement Mono. Ce qui fait qu'on ne peut pas appliquer la LGPL, qui est la licence du runtime Mono. Donc il faut passer par la licence propriétaire de Novell.

    Personnellement, je ne trouve pas ça choquant de commercialiser un produit pour une plate-forme complètement fermée, tout en gardant Mono complètement libre et open-source. Un commentaire plus haut suggérait que c'était pas sympa pour les contributeurs de Mono, qui ont donné leur copyright à Novell. D'abord tout le monde fait ça, Sun pour MySQL / Java, Red-Hat pour JBoss, etc. C'est même un modèle plutôt familier le couple GPL/LGPL + licence propriétaire. Ensuite, pour les contributeurs de Mono, quand ils touchent au runtime, ils ont le choix de publier leur patch en signant un contributor agreement pour le copyright, ou de garder leur copyright et de publier le patch sous MIT/X11. Surtout, si ils contribuent des patchs, c'est surtout qu'ils ont un intérêt et que pour la plus part, ils utilisent Mono commercialement aussi. Donc je vois pas vraiment où est le problème.

    MonoTouch est un produit de niche (pas forcément petite la niche cela dit), pour les développeurs .net expérimentés, qui souhaitent réutiliser leurs compétences et/ou du code pour faire des applications iPhone.
    • [^] # Re: Ce n'est pas sale de se MonoToucher

      Posté par  . Évalué à 2.

      Tout d'abord, merci pour les détails.

      Il faut dire qu'Apple interdit de lier dynamiquement des bibliothèques, de sorte que MonoTouch doit lier statiquement Mono. Ce qui fait qu'on ne peut pas appliquer la LGPL, qui est la licence du runtime Mono. Donc il faut passer par la licence propriétaire de Novell.
      Non, ce n'est pas la bonne raison : on aurait très bien pu décider de tout mettre en LGPL/GPL, même le programme qui utilise MonoTouch. Mais je suppose que ça n'aurait pas plu à certains qui veulent faire du proprio.

      La "vraie" raison que je ne comprend pas très bien est "qu'on doit pouvoir remplacer la lib par leur propre version, selon la LGPL" (traduction libre) et qu'à priori c'est incompatible avec les conditions de l'AppStore (si quelqu'un avait une explication, ça m'intéresse).

      Personnellement, je ne trouve pas ça choquant de commercialiser un produit pour une plate-forme complètement fermée, tout en gardant Mono complètement libre et open-source.
      Je ne trouve pas ça complètement "choquant" non plus, mais l'argument du "puisque c'est fermé, autant rester dedans" ne va pas de pair avec la philosophie du logiciel libre (qui essaye en général de "libérer" les utilisateurs, même lorsuq'ils sont sur une plateforme propriétaire).

      D'abord tout le monde fait ça, Sun pour MySQL / Java, Red-Hat pour JBoss, etc. C'est même un modèle plutôt familier le couple GPL/LGPL + licence propriétaire.
      Encore un argument du "puisque tout le monde fait ça, c'est pas la peine de chercher à faire mieux" : c'est du nivellement par le bas. Le libre ne s'est pas développé grâce à ce genre de réflexions. Et quand tu dis "tout le monde fait ça", je pense que tu as cité les principaux exemples, mais il y en a aussi beaucoup d'autres qui ne le font pas, à commencer par le kernel.

      Ensuite, pour les contributeurs de Mono, quand ils touchent au runtime, ils ont le choix de publier leur patch en signant un contributor agreement pour le copyright, ou de garder leur copyright et de publier le patch sous MIT/X11.
      Pour reprendre dans un autre contexte une phrase citée plus haut : choisir entre la peste et le choléra ... "Garder" son copyright avec une MIT/X11, c'est un argument de BSDiste, pas de "GPListe". Ceux qui contribuent à des logiciels sous GPL le font pour que les dérivés ne deviennent pas proprios. Ce qui est tout le contraire de ce genre de deal.

      Surtout, si ils contribuent des patchs, c'est surtout qu'ils ont un intérêt et que pour la plus part, ils utilisent Mono commercialement aussi.
      Ha bon ? Je ne connais pas vraiment l'écosystème autour de Mono, mais si c'est un paquet de gens qui ne rêvent que de faire du proprio, ça ne m'attire pas vraiment.

      MonoTouch est un produit de niche (pas forcément petite la niche cela dit), pour les développeurs .net expérimentés, qui souhaitent réutiliser leurs compétences et/ou du code pour faire des applications iPhone.
      L'argument de la "niche", on le sort à chaque fois qu'on ne veut pas faire de libre. Le problème, c'est qu'à partir du moment où on autorise du libre dans une "niche", elle ne le reste plus longtemps, et devient commercialement beaucoup moins intéressante.
      • [^] # Re: Ce n'est pas sale de se MonoToucher

        Posté par  (site web personnel) . Évalué à 4.

        Non, ce n'est pas la bonne raison : on aurait très bien pu décider de tout mettre en LGPL/GPL
        Pas convaincu, d'après ma compréhension tu ne peux pas mettre de code sous GPL/LGPL sur iPhone du tout, puisque l'application doit obligatoirement être signé numériquement. Un soft sous (L)GPL oblige à redistribuer cette clé pour permettre d'utiliser la version modifiée, mais c'est Apple qui détient la clé en question... (sauf jailbreak m'enfin ne pas respecter une licence (Apple) pour en utiliser une autre voilà quoi :))

        Donc la véritable question n'est pas de savoir si monotouch doit être libre ou non, mais de savoir si c'est acceptable de faire un produit proprio quand on fait par ailleur la promotion du libre.

        Là où je suis d'accord avec Jb, c'est que le modèle de double licence est largement répendu et accepté dans le monde du libre. Là où je ne suis pas d'accord, c'est que monotouch n'est justement pas sous double licence : même si la version sous GPL/LGPL n'est pas "utilisable", elle pourrait toujours être utile pour d'autres développeurs : technique de binding Objective-C par exemple ou façon de s'interfacer avec xcode, etc.

        Bref, ca fait vraiment bizzare de voir MDI faire la promotion d'un produit totalement proprio sans version "libre". Je comprends que c'est un choix qui incombe à son employeur, Novell, mais quand même, c'est contraire à tout ce qu'il nous avait habitué.
        • [^] # Re: Ce n'est pas sale de se MonoToucher

          Posté par  . Évalué à 2.

          Un soft sous (L)GPL oblige à redistribuer cette clé pour permettre d'utiliser la version modifiée,
          Ola, ola, tu vas un peu vite en besogne la...
          Seul la version 3 de la (l)gpl oblige a faire ca.

          Connaissant novell (ou n'importe qui ayant un cerveau en etat de marche), la gpl3 n'est meme pas envisageable.

          un troll s'est glisse dans ce commentaire, pourra tu, ami lecteur, le debusquer?
        • [^] # Re: Ce n'est pas sale de se MonoToucher

          Posté par  . Évalué à 2.

          Un soft sous (L)GPL oblige à redistribuer cette clé pour permettre d'utiliser la version modifiée, mais c'est Apple qui détient la clé en question... (sauf jailbreak m'enfin ne pas respecter une licence (Apple) pour en utiliser une autre voilà quoi :))
          Le binaire on s'en branle du moment qu'on a les sources. Regarde le cas de la TiVoïsation : ils respectent très bien la licence (à la lettre, mais pas dans l'esprit puisque la GPLv3 a été créée en partie "à cause" d'eux), on a les sources mais impossible de faire marcher le binaire où que ce, il n'y a pas de problème de compatibilité clé / licence LGPLv2. C'est une fausse excuse pour moi.

          Pour la suite, je suis à peu près d'accord avec toi, même si j'ai mon côté barbu qui a envie d'un truc encore plus libre, et que le modèle de double licence ne se répande pas trop (quand je donne mon copyright à une entreprise, en général, c'est qu'elle m'a payé pour ça) ...
  • # 99$ / App Store

    Posté par  . Évalué à 2.

    De faire payer la diffusion d'applications (abonnement développeur : 99$ de mémoire), même si l'on souhaite seulement développer un logiciel gratuit.

    Tes 99$ sont là pour te permettre de distribuer ton application dans l'app store, soit le seul et unique canal de distribution d'application Iphone.

    Sachant que tout possesseur d'Iphone est obligé de passer dans Itunes et donc finalement dans l'app store ( on y trouve aussi les podcasts, donc cela fait un point d'entrée ), c'est une stratégie très efficace de la part d'Apple, qui gagne à vendre le plus d'applications possible. Oui, c'est un méchant monopole, mais pour vendre des applications et enrichir développeurs et éditeur c'est efficace.

    A 1 euros l'application par exemple, sachant que tu prends 70% du prix pour toi, c'est rentabilisé relativement vite si tu gardes à l'esprit que le marché est immense ( et en plus tout est fait pour que tu achète sans t'en rendre compte ... ).

    Enfin, surtout pas envie de payer 99$ le test : tu es allé un peu vite là. Tu peux tout à fait télécharger et jouer avec le SDK sans payer quoi que ce soit ( si ce n'est bien entendu un mac pour faire cela proprement ). Les 99$ sont juste le droit d'entrée sur l'app store.
    • [^] # Re: 99$ / App Store

      Posté par  . Évalué à 2.

      Enfin, surtout pas envie de payer 99$ le test : tu es allé un peu vite là. Tu peux tout à fait télécharger et jouer avec le SDK sans payer quoi que ce soit ...

      Tu as raison : pour 0€/0$, je peux utiliser le SDK et tester un bout d'application via l'émulateur. Mais si je veux installer ce bout d'appli sur mon iPhone, pas possible, sauf à jailbreaker.

      Dommage qu'il n'y ait pas un mode de test, permettant d'installer une appli personnelle sur son propre appareil (quitte à passer par l'AppStore pour éviter d'autoriser l'installation d'appli "warez")

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.