我已经使用MonoTouch几个月了，我从ObjectiveC移植了我的半成品应用，这样我就可以在未来的某个时候支持Android。

以下是我的经验:

不好的地方在于:

Xamarin Studio. Indie developers such as myself are forced into using Xamarin Studio. It is getting better every week, the developers are very active on the forums identifying and fixing bugs, but it's still very slow, frequently hangs, has a lot of bugs and debugging is pretty slow also. Build times. Building my large (linked) app to debug on a device can take a few minutes, this is compared to XCode which deploys almost immediately. Building for the simulator (non-linked) is a bit quicker. MonoTouch issues. I've experienced memory leak issues caused by the event handling, and have had to put in some pretty ugly workarounds to prevent the leaks, such as attaching and detaching events when entering and leaving views. The Xamarin developers are actively looking into issues like this. 3rd party libraries. I've spent quite a time converting/binding ObjectiveC libraries to use in my app, although this is getting better with automated software such as Objective Sharpie. Larger binaries. This doesn't really bother me but thought I'd mention it. IMO a couple of extra Mb is nothing these days.

好的方面:

多平台。我的朋友很高兴地用我的核心代码库为我的应用程序创建了一个Android版本，我们正在并行开发，并将其提交给Dropbox上的远程Git存储库，进展顺利。 . net。在c# . net中工作比在Objective C中工作要好得多。 MonoTouch。iOS中几乎所有的东西都映射到。net中，让事情正常工作是相当直接的。 Xamarin的。你可以看到这些人真的在努力改进一切，使开发更顺畅和更容易。

我强烈推荐Xamarin进行跨平台开发，特别是如果你有钱使用与Visual Studio合作的商业版或企业版。

如果你只是在创造一款在其他平台上永远都不需要的iPhone应用，并且你是一名独立开发者，那么我现在会坚持使用XCode和Objective C。

我个人认为你只学习Objective-C会过得更好。

简而言之:

“学习Objective-C”并不像你想象的那样令人生畏，你甚至会在最初几周后就喜欢上它 你已经熟悉了含有大量*&(){}的“C风格”语法;到处都是 苹果在记录方面做得很好 你将以苹果公司预期的方式与iPhone互动，这意味着你将直接从源头获得好处，而不是通过某种过滤。

我发现像Unity和MonoTouch这样的项目应该“节省你的时间”，但最终你还是需要学习他们的领域特定语言，有时不得不回避一些事情。所有这些可能会花费你学习你试图避免学习的语言的时间(按日历时间计算)。最后你并没有节省任何时间，而是与某些产品紧密耦合。

编辑:我从未想过要暗示任何关于。net的负面信息，我只是碰巧是它的忠实粉丝。我的观点是，仅仅因为你还不习惯古怪的objc括号符号，就添加更多的复杂性层，对我来说真的没有多大意义。

2019年更新:7年过去了。我现在仍然有同样的感觉。当然，使用“领域特定语言”可能是错误的，但我仍然相信，最好直接为您正在使用的平台编写，并尽可能避免兼容层和抽象。如果你担心代码重用和重做，一般来说，你的跨平台应用需要执行的任何功能都可以通过现代web技术来完成。

使用Mono并不是一种依赖。它为iPhone操作系统增加了很多功能。LINQ, WCF, Silverlight应用程序之间的可共享代码，ASP。NET页面，一个WPF应用程序，一个Windows Form应用程序，还有针对Android的mono它也适用于Windows Mobile。

So, you can spend a bunch of time writing Objective-C (You'll see from many studies where the exact same sample code in C# is significantly less to write than OC) and then DUPLICATE it all for other platforms. For me, I chose MonoTouch because the Cloud App I'm writing will have many interfaces, the iPhone being only one of them. Having WCF data streaming from the cloud to MonoTouch app is insanely simple. I have core libraries that are shared among the various platforms and then only need to write a simple presentation layer for the iPhone/WinMobile/Android/SilverLight/WPF/ASP.NET deployments. Recreating it all in Objective-C would be an enormous waste of time both for initial dev and maintenance as the product continues to move forward since all functionality would have to be replicated rather than reused.

那些侮辱MonoTouch或暗示它的用户需要拐杖的人，是缺乏拥有。net框架的大蓝图，可能不理解逻辑与表示的正确分离，这种分离可以在跨平台和设备上重用。

Objective-C is interesting and very different from many common languages. I like a challenge and learning different approaches... but not when doing so impedes my progress or creates unnecessary re-coding. There are some really great things about the iPhone SDK framework, but all that greatness is fully supported with MonoTouch and cuts out all the manual memory management, reduces the amount of code required to perform the same tasks, allows me to reuse my assemblies, and keeps my options open to be able to move to other devices and platforms.

我换了。Monotouch让我编写应用程序的速度至少提高了3-4倍(与我以前在Obj C中每月1个应用程序相比，每月4个)

打字少了很多。

只是我的经验。

我最近经常看到这个问题(以及它的变体)。让我惊讶的是，人们经常回复，但很少有人回答。

我有我的偏好(我喜欢这两组)，但这是大多数“答案”开始出错的地方。它不应该是关于我想要什么(或其他人想要什么)。

以下是我如何决定MonoTouch的价值-我不能客观，显然，但我认为这是相当狂热的:

Is this for fun or business? If you wanted to get into consulting in this area, you could make your $399 back very quickly. Do you want to learn the platform inside-out, or do you "just" want to write apps for it? Do you like .Net enough that using a different dev stack would take the fun out of it for you? Again, I like both stacks (Apple and Mono), but for me MonoTouch makes the experience that much more fun. I haven't stopped using Apple's tools, but that's mainly because I really do enjoy both stacks. I love the iPhone, and I love .Net. In that case, for me, MonoTouch was a no-brainer. Do you feel comfortable working with C? I don't mean Objective-C, but C - it matters because Objective-C is C. It's a nice, fancy, friendly OO version, but if pointers give you the heebie-jeebies, MonoTouch is your friend. And don't listen to the naysayers who think you're a dev wuss if it happens that you don't like pointers (or C, etc.). I used to walk around with a copy of the IBM ROM BIOS Pocket Reference, and when I was writing assembly and forcing my computer into funny video modes and writing my own font rendering bits for them and (admittedly trashy) windowing systems, I didn't think the QuickBasic devs were wusses. I was a QuickBasic dev (in addition to the rest). Never give in to nerd machismo. If you don't like C, and if you don't like pointers, and if you want to stay as far away from manual memory management as possible (and, to be fair, it's not bad at all in ObjC), then... MonoTouch. And don't take any guff for it. Would you like to target users or businesses? It doesn't matter much to me, but there are still people out there on Edge, and the fact is: you can create a far smaller download package if you use Apple's stack. I've been playing around with MonoTouch, and I have a decent little app going that, once compressed, gets down to about 2.7 MB (when submitting your app for distribution, you zip it - when apps are downloaded from the store, they're zipped - so when figuring out if your app is going to come in under the 10MB OTA limit, zip the sucker first - you WILL be pleasantly surprised with MonoTouch). But, MT happiness aside, half a meg vs. nearly three (for example) is something that might be important to you if you're targeting end users. If you're thinking of enterprise work, a few MB won't matter at all. And, just to be clear - I'm going to be submitting a MT-based app to the store soonishly, and I have no problem whatsoever with the size. Doesn't bother me at all. But if that's something that would concern you, then Apple's stack wins this one. Doing any XML work? MonoTouch. Period. String manipulation? Date manipulation? A million other little things we've gotten used to with .Net's everything-AND-the-kitchen-sink frameworks? MonoTouch. Web services? MonoTouch. Syntactically, they both have their advantages. Objective-C tends to be more verbose where you have to write it. You'll find yourself writing code with C# you wouldn't have to write with ObjC, but it goes both ways. This particular topic could fill a book. I prefer C# syntax, but after getting over my initial this-is-otherworldly reaction to Objective-C, I've learned to enjoy it quite a bit. I make fun of it a bit in talks (it is weird for devs who're used to C#/Java/etc.), but the truth is that I have an Objective-C shaped spot in my heart that makes me happy. Do you plan to use Interface Builder? Because, even in this early version, I find myself doing far less work to build my UIs with IB and then using them in code. It feels like entire steps are missing from the Objective-C/IB way of doing things, and I'm pretty sure it's because entire steps are missing from the Objective-C/IB way of doing things. So far, and I don't think I've sufficiently tested, but so far, MonoTouch is the winner here for how much less work you have to do. Do you think it's fun to learn new languages and platforms? If so, the iPhone has a lot to offer, and Apple's stack will likely get you out of your comfort-zone - which, for some devs, is fun (Hi - I'm one of those devs - I joke about it and give Apple a hard time, but I've had a lot of fun learning iPhone development through Apple's tools).

要考虑的事情太多了。价值是如此抽象。如果我们谈论的是成本和是否值得，答案就归结为我的第一个项目:如果这是为了生意，如果你能得到这份工作，你就能赚回你的钱。

所以…这是我最客观的评价了。这是一个你可能会问自己的问题的简短清单，但这只是一个起点。

就我个人而言(让我们暂时放弃客观性)，我喜欢并使用这两种方法。我很高兴我先学会了苹果堆栈。当我已经熟悉苹果的世界时，使用MonoTouch会更容易上手。正如其他人所说，你仍然要使用CocoaTouch——它只是将在一个。net化的环境中。

但不止于此。没有使用过MonoTouch的人往往会止步于此——“这是一个包装器等等”——这不是MonoTouch。

MonoTouch让你访问CocoaTouch所提供的功能，同时也让你访问。net所提供的(一个子集)，一个一些人觉得更舒服的IDE(我是其中之一)，更好地与Interface Builder集成，尽管你不能完全忘记内存管理，但你得到了一个很好的余地。

如果你不确定，抓取苹果的堆栈(它是免费的)，抓取MonoTouch的eval堆栈(它是免费的)。在你加入苹果的开发程序之前，这两种软件都只能在模拟器上运行，但这足以帮助你弄清楚你是否更喜欢其中一种，以及MonoTouch对你来说是否值得花399美元。

不要听那些狂热者的话——他们往往是那些没有使用过他们所指责的技术的人:)

MonoTouch库的成本完全不是重点。你不应该在你的iPhone应用中使用Mono的原因是，它是一种拐杖。如果您懒得学习本机工具，那么我就没有理由相信您的产品值得下载。

编辑:4/14/2010用MonoTouch编写的应用程序不适合iTunes Store。这是应该的。苹果在Mac上看到了大量的浅端口，使用跨平台工具包，如Qt，或Adobe自己的System 7工具箱的部分重新实现，总之，它们不够好。