约翰格鲁伯最近的一篇文章指出以下法律术语:
3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.
已修改如下:
3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).
并做出以下观察:
我对这种新语言的阅读是禁止交叉编译器,例如Adobe即将推出的Flash Professional CS5版本中的Flash-to-iPhone编译器.这也禁止使用MonoTouch编译的应用程序 - 一个将C#和.NET应用程序编译到iPhone的工具.
这实际上是否禁止在iPhone上使用Monotouch?
这最近改变了.MonoTouch不应再与协议冲突.以下任何陈述都是纯粹的历史!
是的,从他们的许可协议现在看来很明显,如果原始应用程序是用C#编写的,那么它将违反许可证:
...应用程序必须最初用 Objective-C,C,C++或JavaScript编写,由iPhone OS WebKit引擎执行...
他们甚至进一步锤击它:
禁止通过中间翻译或兼容性层或工具链接到Documented API的应用程序
有点无赖,MonoTouch和Flash CS5 - > iPhone转换器非常酷.
更新:
Apple已经(几乎)降低了iOS的语言和库的所有技术要求,因此MonoTouch毫无疑问是一个可行的解决方案.请参阅Apple的公告.
这里的大多数人只是想用苹果的文件说"是,它被禁止".嗯,这是我的观点:在这一点上,没有人真的知道MonoTouch是否会被禁止,我将解释原因:
Apple协议版本3(不是最新版本,前一版)明确指出,使用任何其他框架开发除Apple提供的应用程序之外的应用程序是非法的:
3.3.2应用程序本身不能通过任何方式安装或启动其他可执行代码,包括但不限于使用插件体系结构,调用其他框架,其他API或其他方式.除了由Apple的Documented API和内置解释器解释和运行的代码之外,不得在应用程序中下载或使用解释代码.http://adcdownload.apple.com/iphone/iphone_sdk_3.2__final/iphone_sdk_agreement.pdf
虽然情况确实如此(实际上是2.x以来的情况,苹果公司接受的应用程序没有任何问题.例如,所有EA游戏都使用Lua脚本,很多人都使用外部库iPhone本身并不是原生的.即使iPhone有这些原生API,Apple也不会接受使用不同版本的应用程序的问题,比如SQLite.
我的观点是说"是的,它们现在会被禁止"只是过早地过早.在这一点上唯一清楚的是,苹果可能会在实际上使用禁止应用程序.就像他们今天接受违反他们某些规则的应用程序一样,他们可能会继续这样做.
还有一个事实是,当前运行Mono的商店中有数百个(或可能是几千个?)的应用程序,Apple需要接受这些应用程序的更新.使用Mono(和Lua)创建了具有数百万销售额的主要应用程序,我怀疑他们会退还每个用户.
最后,企业应用程序在未经Apple批准的情况下部署到iPhone,这是MonoTouch的一个大市场(我自己开发企业应用程序).在这一点上,Apple无法禁止MonoTouch用于这些应用程序,这可能足以让MonoTouch保持活力很长时间.
对3.3.1,3.3.2和3.3.9节的新修改使得MonoTouch(以及所有其他交叉编译器/语言/等)在iPhone上完全可以接受. 请参阅Apple的公告
米格尔似乎并不这么认为.查看推文和Miguel的回复.让我们不要在这里反复过度,并说Monotouch已经死了,或者停止使用Monotouch进行开发,直到所有相关方做出一些澄清.
这就是说,我肯定会开始对苹果采取这种严厉的发展政策.像这样的事情,以及iphone/ipad/touch应用程序批准政策的模糊过程应该让开发人员感到害怕.接下来是什么,他们的许可说明你可以使用的唯一广告平台是iAd?不允许在没有iAd的情况下分发免费应用程序?慢慢提高Apple在应用销售收入中的份额?作为一个被锁定的生态系统中的开发者,我们是一群热水中的青蛙,而苹果正在慢慢地加热.现在是探索其他移动平台的时候了,因为随着它们变得更好,将人们带入Apple平台的主要原因是其他平台上缺少应用程序.
我花了几个月的时间在Objective C中为一个杀手级iPhone应用程序的想法工作.我的日常工作是C#.当我成为一个可行的替代品时,我下载了MonoTouch C#,并且花了3个月的时间将我的代码转换为iPhone特定的MonoTouch C#.通过切换C#/ Objective C,这让我发疯了.
我现在该做什么把它扔掉然后重新开始或放弃!?!
我对Mono家伙感到非常抱歉.这是完全错误的.阻止没有推出产品且没有客户的Adobe并停止MonoTouch,并在AppStore中批准产品也是一回事.
为什么有人想要建立一个企业并投资苹果公司,因为他们会在不知不觉或有问题的情况下及时将其全部拿走?
很明显,苹果的开发者和客户照顾他们和他们的产品是一条单行道.
我希望苹果公司因这种荒谬的政策而受到打击.傲慢不具吸引力,通常对企业不利.这是我没有开始iPhone开发的原因之一.
大多数硬件和操作系统提供商都乐于为其平台提供额外的工具和受众.苹果公司采取的态度是,它的(脑死亡)工具是城里唯一的游戏.
1984年的"老大哥"广告越来越相关......
编辑
它的编写方式似乎也意味着如果我在目标C/apple翻译器上写了一个.net,那么代码是不可接受的,因为原始代码不是客观的c.这是荒谬的(并且无法执行.)
新的许可协议明确地明确了这一点.是的,它将被禁止.
建议,如果你想真正开发iPhone,试试XCode.如果您已经熟悉Java或C#或更好的C++,那么学习Objective-C就不那么难了.
iPhone/iPad是苹果新的成功业务,他们将采取一切措施来保持这项业务的增长,也许他们现在不会禁止使用Monotouch应用程序,但谁知道下一步呢?因此,如果你真的对iPhone开发真的感兴趣,而不是做噩梦,你的工作可能会被拒绝.只需切换到XCode,至少会降低您的应用拒绝百分比.因此,我的建议.
Unity也是基于Mono而且这是一个相当大的商业产品,我想这是一个我们还没有听说过的问题.
禁止所有非Obj-C/C++编写的应用程序,理论上也禁止所有Unity游戏,其中已有大量已在应用程序商店中.
这个问题也在Unity Answers网站上被问过,他们的官方答案是:
"我们刚刚听说过iPhone OS4.0和新的服务条款.虽然我们认为我们完全符合这些要求,但我们现在正竭尽所能让Apple验证这一点.一旦我们确切知道,我们当然会与每个人分享这些信息.请在我们得到这个信息时紧紧抓住."
有趣的是看到Apple告诉他们的内容.
问题是,肯定说应用程序必须用某种语言编写有点用词不当,因为一旦应用程序被编译下来,无论它是如何构建的,它总是一个原生的二进制文件.我的猜测是,他们可以寻找的只是二进制文件中的某种签名来检测它构建的工具.一种有缺陷的方法.
编辑:有一个有趣的概述这个博客的情况:monotouch现在死在水中苹果新的iPhone开发者协议意味着什么
我认为需要强烈考虑的是Apple的动机.
我同意在线发布的其他观点,即Apple试图阻止应用程序的商品化 - 也就是说,越来越多的应用程序使用生成可以跨多个设备运行的应用程序的框架编写.
但这不是Monotouch的意思.Monotouch就是使用Apple框架编写应用程序 - 但是通过Mono,而不是Objective-C.因此,从这个角度来看,Monotouch正在做的事情并不是真正打扰苹果的事情.
我仍然认为开发人员最好用他们正在使用的平台的本地语言编写,因为当你不引入可能具有抽象阻抗不匹配的系统时,事情通常会更平滑 - Cocoa框架都是为了使用而构建的Objective-C,当你习惯Objective-C的哲学时,它们是最有意义的.但我确实希望Apple能够使用MonoTouch.
所有苹果公司都在说,你现在必须使用1980年代的语言来发展你的竞争对手最先进的移动应用程序....
有一个完美的感觉.对我来说听起来像是一个成功的策略.
它也阻止您使用任何第三方库,您不能保证它们是直接用C,C++或Objective C开发的.
所以基本上它意味着你不能购买像Unity这样的Games API.