苹果是否会将Mono Touch运行时与每个iPhone捆绑在一起?

3
我认为苹果与Novell谈判并将Mono Touch运行时(仅限运行时)捆绑到每个iPhone和iPod Touch中是一个好主意。甚至可以使其成为“一次性安装”,该安装程序会在第一次下载使用Mono Touch构建的应用程序时自动从App Store下载,从而使每个后续的Mono Touch应用程序更轻便(没有运行时)。
这样做类似于将Bootcamp添加到OS X中:它会使C#开发人员更容易加入其中,但这并不意味着这些开发人员都会坚持使用C#…让我决定购买Mac的是Bootcamp-我想我如果不喜欢OS X可以随时安装Windows(我喜欢硬件,所以没有问题)。6个月后,我全职使用OS X...
这样做是否存在任何技术问题?我只看到所有方面的优势,没有任何人的缺点(除了可能有一些不幸的苹果员工必须在捆绑之前完全测试Mono Touch运行时):
- Novell获胜,因为Mono Touch变得更具可行性(Mono Touch应用程序突然变得更轻) - 开发人员获胜,因为现在有了更多的工具 - 许多C#开发人员会对此非常感兴趣 - 苹果赢了,因为这会引起更多关注,增加开发人员费用收入,带来更多潜在的出色应用程序等 - 用户获胜,因为不同应用程序在其设备上累积相同运行时的副本所占用的空间较少
在将Mono Touch捆绑到iPhone OS中是否存在重大技术障碍?

1
这并不是一个真正的编程问题。 - Alex Reynolds
6个回答

18
不,但苹果也没有充分的理由这样做。iPhone并不是因为缺少Mono而受到影响,开发过程中存在更大的问题(例如被超负荷工作的应用程序审核员奇怪的拒绝),还有其他备选语言,苹果更可能先关心如MacRuby和Python这样的语言。苹果支持这两种语言在Mac上编写Cocoa应用程序,所以我会期望它们在iPhone上得到支持,而不是像C#这样突然冒出来的语言。
(请注意,我并没有确切回答苹果是否应该捆绑MonoTouch的问题,这有点主观。我只是解释了影响他们是否这样做的力量。)

这个问题的措辞确实会导致主观性。我真正想表达的是“苹果会捆绑Mono Touch运行时吗?”,苹果这样做是否有意义。你对此做出了很好的回应。我认为许多C#开发人员都在思考这个问题。鉴于高昂的入门费用,投资Mono Touch基本上是否有意义。我将问题改为“会”而不是“应该”,这更多地涉及预测而不是主观判断。 - Zoran Simic
考虑到关于Mac上JRE的旧/模糊承诺,我认为Mono也不能被区别对待。是的,我对此持悲观态度。 - Lex Li
Cocoa和Cocoa Touch是建立在Objective-C的功能之上的。 Cocoa Touch中所有设计决策的原因都基于Objective-C的优势。 C#几乎完全颠覆了Objective-C的设计。 C#可以与Cocoa Touch配合使用,但Objective-C才是使其发光发亮的关键。 - PeyloW

4
根据 即将发布的iPhone OS 4 SDK的iPhone开发者计划许可协议,MonoTouch实际上将违反规定并不被允许:
3.3.1 - 应用程序只能按照苹果公司规定使用文档化API,并且不能使用或调用任何私有API。应用程序必须最初是用Objective-C、C、C++或由iPhone OS WebKit引擎执行的JavaScript编写的,只有用C、C++和Objective-C编写的代码才能编译和直接链接到文档化API(例如,通过中介翻译或兼容性层或工具链接到文档化API的应用程序是被禁止的)。
由于C#不是这些语言之一,因此将不被允许。

4
Miguel de Icaza正在开发iPhoneOS 4版本,并且引用他的话来说:“ MonoTouch已经有一个编译为C + XCode的选项,只需调用mtouch --xcode program.exe”- http://twitter.com/migueldeicaza/status/11844609073&http://twitter.com/migueldeicaza/status/11836097616。 - Michael Stum

4
我的理解是,iPhone上的Mono运行时(可能不正确)并不像其他平台上的运行时那样真正意义上的运行时 - 所有代码(包括Mono)都被编译为静态代码。
这只是一个1.0版本,尚未证明其价值。可能会有很多版本,预先下载所有版本将会很麻烦。
它将开发者的成本从99美元增加到至少498美元,因此采用率可能会受到限制。
他们已经提供了一个完全良好的开发环境和一套库。
Java和Flash不可用 - 为什么要关注一些不太成熟的东西。
我希望它能做得好,但为了使下载变小,对于不到1%的应用程序而言,苹果公司考虑这个问题并不值得。

点2不成立,因为Unity已经使用了这项技术来定位iPhone/iPod Touch。我也不同意点4,因为它有点束缚你的选择,而我认为其他几点是合理的。 - Lex Li
lextm - 我不明白为什么Unity会让Mono touch成为更成熟的系统?当然它们都允许你编写C#,但它们是不同的技术。在第4点上,他们没有将你锁定,因为你可以使用Mono。他们只是没有大费周折地让它稍微容易一些。Mono不会让你向终端用户提供任何现有工具/库所不能做到的功能。 - RichH
+1 是因为评论1。MonoTouch根本没有CLR运行时,它是编译下来的。苹果禁止任何形式的JIT运行时。在我看来,MonoTouch的价值在于商业.NET公司,他们想制作iPhone应用程序,而不需要让开发人员学习Objective C的开销(成本)。 (在较小程度上,Java公司也可能以同样的方式受益)。 - Andrew M

3

不这样做有很好的理由,因为这会使开发人员分散。一些人会学习Objective-C,一些人会学习Mono,如果苹果支持Mono,他们就必须同时支持两种语言。

如果苹果要做什么,他们会给iPhone Objective-C添加垃圾回收支持,因为它已经存在于桌面上了,但是他们认为设备性能限制足够紧密,不能增加额外的负担。

我非常相信使用符合平台哲学的框架。Mono的工作方式很酷,在像Unity这样的游戏脚本语言中,我认为这是一个绝妙的想法——但是,如果你正在进行iPhone应用程序开发,你应该学习Objective-C,以了解平台的实际情况。


2
将框架与操作系统捆绑在一起具有重大影响。这样做将使保持Mono Touch的安全性和最新状态的责任完全落在苹果的肩上。也就是说,任何Mono Touch的问题都会比Novell更加不利地反映在苹果身上,而任何框架更新都需要进行重大测试,以确保现有的Mono Touch应用程序不会出现故障。我相信这是苹果不想要或不需要的责任。
更重要的是,苹果似乎没有遇到吸引开发者到iPhone平台的任何困难。这有助于吸引开发者进入OS X平台,这是非常重要的。我无法想象苹果现在想改变任何事情。

0
除了Chuck所说的,苹果还必须验证MonoTouch中的所有内容都能正常工作,不会导致崩溃,从而影响苹果的形象。这意味着苹果不仅要对现有的MonoTouch进行严格的测试和QA,还要对每个后续版本进行测试。
即使添加MonoTouch支持很简单,但要做到“正确”却并不容易。
BootCamp可能也是一个巨大的工程项目,需要为苹果开发和QA,但它值得这样做,因为它吸引了Windows用户(一个巨大的市场)来使用Mac。

即使像谷歌语音这样优秀的东西也被屏蔽了,我认为验证并不是一个我们能够信任的过程。当苹果被我讨厌的事情咬到时,它看起来已经很糟糕了。 - Lex Li

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接