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.
# Ce n'est pas sale de se MonoToucher
Posté par Jb Evain . En réponse au journal Miguel, iPhone et développement. É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.