Mono Developers start their own company

I don't know what the terms are of that agreement.

Nope... no real profits.

From the Moonlight FAQ: http://www.novell.com/products/desktop/moonlight_faq.html#j

This collaboration between Microsoft and Novell is a formal engineering development program. Novell is bringing the .NET-based Silverlight framework to Mono, an open source framework for running .NET applications on multiple platforms including Linux. Microsoft is providing a version of the necessary codecs for Linux.

Performance of monotouch is extremely good. For 99% of what you're doing, you do not notice any performance loss at all. I've played around with disabling GC temporarily, but I haven't seen yet a reason to do that in my apps. A few of them use things like huge databases with data, creating thousands and thousands of gc'd objects, and everything works amazingly well.

Not everything can be done in MonoTouch, though. For some things you'll never get enough performance unless you go to C. You can't do a lot of things in Obj-C either. Remember, Obj-c is a dynamic language, so every method call is fairly expensive, which is not the case when you're in .NET land.

If you go with mono, the most striking thing you will notice is increased startup time. On iOS with full AOT this effect is less pronounced, but on webos/android even tiny mono apps have 1-3 seconds of black screen at startup since there's a lot of JIT/metadata work to be done.

On darwin platforms, we've found that mono's garbage collector pauses unmanaged threads at inconvenient times and were forced to move audio playback into a separate process to prevent glitches. This only mattered with large numbers of live objects (>500k), but it did come into play. The new SGen collector may fix this, but it still (as of 2.10.2) crashes too often to be used.

Memory usage is noticeably higher than for comparable objective-c apps, but is not the end of the world.

Once your app is up and running, the mono runtime is plenty fast enough for most things. We even do some light DSP in C# on these platforms. It's better than you would think.

On a related note, just because you're using C#/.net doesn't mean that you can code like you're in the desktop/server world. You still need to focus on doing as little work possible per screen displayed to get the snappiest possible user experience.

1. The majority (99%) of your app is not perf-circital. It's just setting some properties on UIViews and letting CoreAnimation do the rest, or reading data from the DB, or waiting on a network socket. If something is slow, you just throw it on a background thread with a continuation to resync it with the UI thread.

2. Over the years, I have found that micro-optimizations (like: allocating objects on the stack as in C vs allocation on the heap in C#, no dynamic dispatch in C vs lots of virtuals in C#, etc.) are _all_ that C give you and are not enough to make an app like iCircuit fast.

What you need instead is the ability to easily change and experiment with algorithms. C# gives me this -- programming in a strongly typed OOP language gives me the safequards I need to do this. The GC is what allows me to do this quickly and without pulling out my hair (caches in C/C++ drive me nuts because I have to be so careful about ownership rules of objects).

In a nutshell, I'm willing to trade the small (constant) perf hit in order to have better tools for tackling the hard problems - such as analyzing a 1,000 node circuit.

iCircuit contains one tight loop where it has to factor a very large matrix many times a second. That loop runs fine on .NET on desktop machines (don't even break a sweat), but I used a C function for the iOS version since there was about a 2X improvement of speed for this function. Fortunately, .NET makes it stupid easy to call C functions so I have the best of both worlds.

Personally, I wouldn't touch Mono would a ten foot pole, but that's just me....

A year, wow, it doesn't seem like that long ago!