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.
Journal Miguel, iPhone et développement
14
sept.
2009
# ouaip
Posté par TImaniac (site web personnel) . Évalué à 10.
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 benoar . Évalué à 10.
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 reg . Évalué à 5.
Où est le problème ?
[^] # Re: Ce sera "commercial", aussi
Posté par Brioche4012 (site web personnel) . Évalué à -7.
[^] # Re: Ce sera "commercial", aussi
Posté par benoar . Évalué à 4.
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 GeneralZod . Évalué à 4.
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 BAud (site web personnel) . Évalué à 4.
[^] # Re: Ce sera "commercial", aussi
Posté par GeneralZod . Évalué à 2.
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 BAud (site web personnel) . Évalué à 2.
[^] # Re: Ce sera "commercial", aussi
Posté par B16F4RV4RD1N . Évalué à 8.
(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 vida18 . Évalué à -2.
# Ah, Miguel ...
Posté par Sébastien B. . Évalué à 10.
[^] # Re: Ah, Miguel ...
Posté par David . Évalué à 0.
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 Jb Evain (site web personnel) . Évalué à 6.
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 benoar . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 4.
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 thedude . Évalué à 2.
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 benoar . Évalué à 2.
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 jhc_ . Évalué à 2.
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 tom120934 . Évalué à 2.
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.