如何在MonoTouch和Objective-C之间做出选择？[关闭]

今天在一次本地.Net活动中，在Mono上参加了一次会议之后，MonoTouch的使用被“触及”为iPhone开发的替代方法。尽管Mono堆栈有些古怪，但在C＃和.Net上非常满意，这似乎是一个吸引人的选择。但是，由于MonoTouch的价格为400美元，所以如果这是iPhone开发的方法，我会有些不知所措。

任何人都有使用MonoTouch和Objective-C进行开发的经验，如果是这样，那么使用MonoTouch进行开发比学习Objective-C更简单，更快捷，那么值得花400美元吗？

我最近已经看到了这个问题（及其变化）。使我惊讶的是人们经常回应，却很少回答。

我有我的喜好（我喜欢两个堆栈），但这是大多数“答案”开始出错的地方。这不应该是我想要的（或其他人想要的）。

我将按照以下方法确定MonoTouch的值-显然我不能很客观，但是我认为这是没有狂热行为的：

• 这是娱乐还是商务活动？如果您想从事这一领域的咨询工作，可以很快退还399美元。

• 您想从内到外学习该平台，还是“只是”想要为其编写应用程序？

• 您是否足够喜欢.Net，因此使用其他开发堆栈将为您带来很多乐趣？同样，我喜欢这两个堆栈（Apple和Mono），但对我而言，MonoTouch使体验变得更加有趣。我没有停止使用Apple的工具，但这主要是因为我确实很喜欢这两个堆栈。我爱iPhone，也爱.Net。在那种情况下，对我而言，MonoTouch毋庸置疑。

• 您对使用C感到满意吗？我不是说Objective-C，而是C-这很重要，因为Objective-C 是 C。这是一个不错的，漂亮的，友好的OO版本，但是如果指针给您带来了heebie-jeebies，MonoTouch是您的朋友。而且，如果碰巧您不喜欢指针（或C等），也不要听那些认为您是开发者的反对者。我过去经常走一看IBM ROM BIOS Pocket Reference的副本，当我编写程序集并迫使计算机进入有趣的视频模式，并为它们和（当然是垃圾的）窗口系统编写自己的字体渲染位时，我没有认为QuickBasic开发人员是坏事。我当时一个QuickBasic开发人员（除了其余人员）。永远不要屈服于书呆子的大男子主义。如果您不喜欢C，并且不喜欢指针，并且希望与手动内存管理保持尽可能的距离（公平地说，在ObjC中一点也不错），那么。 .. MonoTouch。而且不要为此而烦恼。

• 您想定位用户或企业吗？对我来说并不重要，但是Edge上仍然有很多人，事实是：如果使用Apple的堆栈，则可以创建一个更小的下载程序包。我一直在玩MonoTouch，我有一个不错的小应用程序，一旦压缩，它的大小就会减少到2.7 MB（将您的应用程序提交分发时，请压缩它-从商店下载应用程序时，它们会重新压缩-因此在确定您的应用程序是否将在10MB OTA限制下使用时，请先压缩傻瓜-MonoTouch给您带来惊喜。但是，除了MT的幸福感外，如果您以最终用户为目标，则对您而言可能很重要，例如，半微秒对近三微秒。如果您正在考虑企业工作，那么几MB根本不重要。和，只是要清楚-我将尽快向商店提交基于MT的应用程序，而且大小没有问题。根本不打扰我。但是如果那会引起关注你们，那么苹果的筹码就赢得了这一局。

• 做任何XML工作吗？MonoTouch。期。

• 字符串操作？日期操作？我们已经习惯了.Net的一切-厨房-接收器框架的其他一百万个小东西？MonoTouch。

• 网页服务？MonoTouch。

• 从语法上讲，它们都有自己的优势。在必须编写 Objective-C的地方，它往往会更加冗长。您会发现自己用C＃编写代码，而不必使用ObjC编写代码，但是这两种方式都可以。这个特定的主题可以写一本书。我更喜欢C＃语法，但是在摆脱了对Objective-C的最初的“这是一个超乎寻常的反应”之后，我学到了很多东西。我取笑它在谈判中位（这是怪异的习惯了C＃/的Java /等谁开发者），但事实是，我有一个Objective-C的形状在我的心脏点使我幸福。

• 您打算使用Interface Builder吗？因为，即使在这个早期版本中，我发现自己要用IB构建UI并在代码中使用它们的工作量也要少得多。感觉好像缺少Objective-C / IB的处理的所有步骤，而且我很确定这是因为缺少Objective-C / IB的处理的所有步骤。到目前为止，我认为我还没有经过充分的测试，但是到目前为止，MonoTouch在您要做的工作上要少得多，因此是赢家。

• 您认为学习新的语言和平台有趣吗？如果是这样，iPhone可以提供很多东西，而苹果的堆栈可能会让您脱离舒适区-对于某些开发人员来说，这很有趣（嗨-我是其中一些开发人员-我开玩笑并给予苹果很难，但通过苹果的工具学习iPhone开发给我带来了很多乐趣。

有很多事情要考虑。价值是如此抽象。如果我们在谈论成本以及它是否值得，那么答案就落在我的第一个项目符号上：如果这是用于商业活动，并且您可以得到工作，那么您将立即赚钱。

所以...这几乎是我的目标。这是您可能会问自己的简短列表，但这是一个起点。

就个人而言（我暂时放弃客观性），我喜欢并使用两者。我很高兴我首先学会了苹果堆栈。当我已经了解了苹果世界的方式后，使用MonoTouch起来就容易起来了。正如其他人所说，您仍将与CocoaTouch一起使用-它只会处于.Net格式的环境中。

不仅如此。没有使用MonoTouch的人往往会停在那里-“这是一个包装等等……”-不是MonoTouch。

MonoTouch使您可以访问CocoaTouch必须提供的功能，同时还可以访问.Net（提供的一部分）所提供的功能，使某些人更满意的IDE（我是其中的一个），与Interface Builder的更好集成，尽管您不会完全忘记内存管理，但是您有很大的回旋余地。

如果不确定，请抓住Apple的堆栈（免费），然后抓住MonoTouch评估堆栈（免费）。在您加入Apple的开发计划之前，两者都只能在模拟器上运行，但这足以帮助您确定您是否非常喜欢另一个，以及MonoTouch是否对您来说值得399美元。

而且不要听狂热者-他们往往是没有使用他们反对的技术的人:)

这篇文章中有很多关于尚未尝试过MonoTouch 和 Objective-C的开发人员的传言。似乎大多数是从未尝试过MonoTouch的Objective-C开发人员。

我显然有偏见，但是您可以查看MonoTouch社区的最新动态：

http://xamarin.com

在这里，您会发现一些使用Objective-C和C＃进行开发的开发人员的文章。

因此，我对先前类似问题的答案是学习Objective-C。（此外，请不要忘记调试支持）

坦白说，这可能会冒犯某些人，如果您要进行任何认真的开发，则应该学习Objective-C。不知道iPhone开发中的Objective-C只是一个障碍。您将无法理解许多示例。您必须处理Mono的怪癖，而如果您对Objective-C有一定的了解，则可以从平台文档中获得更多信息。

就个人而言，我不明白这样的立场，即增加使用平台的本地语言支持Mono所需的信息量。这似乎对我适得其反。我认为，如果这是一个非常昂贵的命题（学习一种新语言），那么可能值得花一些时间在基本的编程概念上，以便学习新语言是一个相当便宜的命题。

另一个用户也这样写道：

Monotouch现在对您来说更容易。但是以后很难。

例如，当您需要测试新种子但由于某种原因破坏MonoTouch时会发生什么？

通过坚持使用Mono，每当您在查找框架资源时，都必须在头脑上转化为如何将其与Mono一起使用。您的应用程序二进制文件会更大，进入Objective-C几个月后您的开发时间不会快得多，并且其他应用程序开发人员将因为使用本机平台而比您拥有更多优势。

另一个要考虑的因素是您正在使用C＃，因为您比Object-C更熟悉该语言。但是iPhone的学习曲线绝大部分不是Objective-C，而是框架-您也必须使用C＃调用它们。

对于任何平台，您都应该使用直接表达该平台设计理念的平台-在iPhone上，即Objective-C。从相反的角度考虑这个问题，如果曾经在GTK中进行编程的Linux开发人员想要编写Windows应用程序，您会认真地建议他们不要使用C＃并坚持使用GTK，因为这样做对他们来说“更容易”？

使用Mono不是拐杖。它为iPhone操作系统添加了许多功能。LINQ，WCF，Silverlight应用程序，ASP.NET页，WPF应用程序，Windows Form应用程序之间的共享代码，还有适用于Android的mono，它也适用于Windows Mobile。

因此，您可以花费大量时间来编写Objective-C（您将从许多研究中看到，与OC相比，用C＃编写的完全相同的示例代码要少得多），然后将其全部复制为其他平台。对我来说，我选择MonoTouch是因为我正在编写的Cloud App将具有许多接口，iPhone只是其中之一。从云端将WCF数据流传输到MonoTouch应用程序非常简单。我拥有在各种平台之间共享的核心库，然后只需要为iPhone / WinMobile / Android / SilverLight / WPF / ASP.NET部署编写一个简单的表示层。随着产品继续向前发展，在Objective-C中重新创建所有内容对于初始开发和维护都是巨大的时间浪费，因为所有功能都必须复制而不是重复使用。

侮辱MonoTouch或暗示其用户需要拐杖的人们都缺乏掌握.NET框架的全局印象，并且可能无法理解以某种方式将逻辑与表示正确分离的方式可以跨平台和设备重复使用。

Objective-C很有趣，并且与许多通用语言完全不同。我喜欢挑战，学习不同的方法...但是这样做不会阻碍我的进步或创建不必要的重新编码。关于iPhone SDK框架，确实有一些很棒的事情，但是MonoTouch完全支持所有这些出色的事情，并且消除了所有手动内存管理，减少了执行相同任务所需的代码量，允许我重用我的程序集，以及保持我的选择开放，以便能够迁移到其他设备和平台。

我换了 Monotouch让我编写应用程序的速度至少要快3-4倍（每月4个应用程序，而我每月在Obj C中只有1个应用程序）

打字少很多。

只是我的经验。

如果这是您将要开发的唯一iPhone应用程序，并且对开发Mac应用程序也没有兴趣，那么MonoTouch可能值得。

如果您认为自己将开发更多的iPhone应用程序，或者想进行Mac的本机开发，那么学习Objective-C和相关的框架可能是值得的。另外，如果您是喜欢学习新事物的程序员，那么这是一种有趣的新学习范例。

我个人认为，学习Objective-C会让您有更好的时间。

简而言之：

• “学习Objective-C”并不是您想像的那么艰巨，甚至在刚开始的几周后您就可以享受它了
• 您已经对带有许多*＆（）{}的“ C样式”语法很熟悉；到处
• 苹果在记录事物方面做得非常出色
• 您将按照Apple的预期方式与iPhone进行交互，这意味着您将直接从来源获得收益，而无需通过某些过滤器。

我发现像Unity和MonoTouch之类的项目应该“节省您的时间”，但最终您还是需要学习它们的领域特定语言，并且有时不得不回避。只要能学到您想要避免学习的语言（在日历时间内），所有这些可能都将花您很长时间。最后，您没有节省任何时间，并且您与某些产品紧密相关。

编辑：我从不打算暗示对.NET的负面看法，我恰好是它的忠实拥护者。我的观点是，仅仅由于您对怪异的objc括号表示法还不满意而增加了更多的复杂性，对我而言实际上并没有多大意义。

2019年更新：7年后。如果不是更多，我仍然有同样的感觉。当然，“领域特定语言”可能是错误使用的术语，但我仍然认为直接为正在使用的平台编写代码要好得多，并尽可能避免兼容性层和抽象。如果您担心代码的重用和返工，通常来说，跨平台应用程序需要执行的任何功能都可以通过现代Web技术来实现。

要补充别人已经说过的话（嗯！）：我的感觉是，您基本上要担心的错误数量要加倍，将MonoTouch中的错误添加到iPhone OS中已经存在的错误中。更新新的OS版本将比正常情况更加痛苦。uck，到处都是。

对于MonoTouch，我能看到的唯一令人信服的案例是组织中有很多C＃程序员和C＃代码，他们必须在iPhone上利用这些代码。（那种商店甚至不会以3500美元的价格眨眼。）

但是对于任何从头开始的人，我真的认为这没有任何价值或智慧。

三个字：Linq to SQL

是的，这是值得的。

我想补充一点，即使有一个可接受的答案-谁能说Apple不会仅仅拒绝具有用Mono Touch构建的迹象的应用程序？

我之所以将时间花在Objective-C上，主要是因为可以从这样的站点获得所有帮助。Objective-C的优势之一是您可以使用C和C ++代码，并且有许多项目都经过了良好的测试。

另一件事是您的代码（选择的语言）将受到Apple的支持。例如，iOS 5.x取消了对MonoTouch等第三方解决方案的支持？那你会告诉你的顾客什么？

如果您还没有准备好使用Objective-C，也许最好使用独立于HTML5的平台独立解决方案？

我已经使用MonoTouch几个月了，我从ObjectiveC移植了一半完成的应用程序，因此将来可以支持Android。

这是我的经验：

坏位：

• Xamarin Studio。像我这样的独立开发人员被迫使用Xamarin Studio。每周都会变得越来越好，开发人员在论坛上非常活跃地识别和修复错误，但是它仍然很慢，经常挂起，有很多错误，调试也很慢。

• 构建时间。构建我的大型（链接）应用程序以在设备上进行调试可能需要几分钟，这与XCode几乎可以立即部署相比。模拟器（非链接）的构建要快一些。

• MonoTouch问题。我遇到了由事件处理引起的内存泄漏问题，并且不得不采取一些非常丑陋的解决方法来防止泄漏，例如在进入和离开视图时附加和分离事件。Xamarin开发人员正在积极研究此类问题。

• 第三方图书馆。我花了相当多的时间转换/绑定ObjectiveC库以在我的应用程序中使用，尽管使用自动软件（例如Objective Sharpie）会变得更好。

• 较大的二进制文件。这并没有真正打扰我，但以为我会提到它。如今，IMO多余的Mb很少。

好位：

• 多平台。我的朋友正在从我的核心代码库中愉快地创建我的应用程序的Android版本，我们正在并行开发，并致力于Dropbox上的远程Git存储库，一切顺利。

• 。净。使用C＃.Net比使用Objective C IMO更好。

• MonoTouch。iOS中的几乎所有内容都反映在.Net中，并且让工作正常进行很简单。

• Xamarin。您会看到这些人确实在努力改善所有方面，使开发更加顺畅和轻松。

我绝对推荐使用Xamarin进行跨平台开发，尤其是如果您有足够的钱来使用与Visual Studio一起使用的Business或Enterprise版本时。

如果您只是创建一个iPhone应用程序，而该应用程序在其他平台上将永远不需要，并且您是独立开发人员，那么我现在将坚持使用XCode和ObjectiveC。

作为具有C＃和Objective-C经验的人，我想对大多数人来说Xamarin都是物有所值的。

C＃是一种非常好的设计语言，而C＃API也是一种很好的设计。当然，Cocoa Touch API（包括UIKit）也具有出色的设计，但是该语言可以通过多种方式进行改进。与使用Objective-C编写相同的代码相比，使用C＃编写时，您可能会更有效率。这是由于多种原因，但某些原因可能是：

• C＃具有类型推断。类型推断使编写代码更快，因为您不必“知道”作业左侧的类型。这也使重构更加容易和节省。

• C＃具有泛型，与等效的Objective-C代码相比，它将减少错误（尽管Objective-C中有一些变通办法，但在大多数情况下，开发人员会避免使用它们）。

• 最近，Xamarin添加了对Async / Await的支持，这使得编写异步代码非常容易。

• 您将能够在iOS，Android和Windows Phone上重用部分代码库。

• MonoTouch通过非常直接的方式很大程度上实现了CocoaTouch API。例如：如果您有使用CocoaTouch的经验，就会知道在MonoTouch中可以找到控件类的位置（MonoTouch.UIKit包含UIButton，UIView，UINavigationController等的类，同样，MonoTouch.Foundation也包含NSString的类， NSData等）。

• 与PhoneGap或Titanium等解决方案不同，Xamarin将为用户带来原生体验。

现在，Objective-C比C＃具有一些优势，但是在大多数情况下，用C＃编写应用程序通常会减少开发时间和更简洁的代码，并且减少将同一应用程序移植到其他平台的工作。一个值得注意的例外可能是依赖OpenGL的高性能游戏。

MonoTouch库的成本完全没有意义。您不应该在iPhone应用程序中使用Mono的原因是它是拐杖。如果您不愿意学习本机工具，那么我没有理由相信您的产品值得下载。

编辑：2010年4月14日用MonoTouch编写的应用程序不符合iTunes Store的条件。这是应该的。苹果公司在Mac上看到了许多浅层端口，它们使用了Qt等跨平台工具包，或者Adobe自己对System 7工具箱进行了部分重新实现，但总的来说，它们还不够好。