As someone whose work life involves a lot of C# development I can honestly say it's a great little language that would get used much more if it's name wasn't tied to Microsoft. Beyond that there's no doubt the Mono project has done some impressive things.
That said, I wouldn't do this on a commercial project. Because when a bug does come up you just have too many layers to contend with. Is it a bug in my code, in the Unity Framework, in Mono, in the device or what? This is a particularly significant problem when dealing with Open Source projects with very little in the area of support mechanisms and Apple which seems to think far too much of itself to offer decent developer support.
So in the end it's a nifty proof of concept but I personally couldn't bring myself to trust it.
As someone whose work life involves a lot of development of C# development tools, I can honestly say that these concerns apply to our team at Microsoft just as much as they apply to Mono. The only difference is that when someone asks us a question about some bugs or our direction or policies, we have to ignore it to appease the lawyers. This is a risk you run if you write any software at all, no matter the vendor.
EDIT: Although, if you are writing a commercial, big budget game, our game development support staff is incredible. So if you want that, then yeah, you'd have to use one of our official products. My comment was about if you didn't intend to go that big publisher route. I was talking mostly about small ISVs.
"bug" or, if you prefer, there are "bugs" and there are "quirks". I can't say that I've ever found a full on bug in the .net framework but I have encountered several quirks that had us baffled but which were solved in 5 minutes with a quick call to Microsoft.
Bottom Line: Our contract with them cost us $2500 and no matter what the problem has been (be it code, OS, whatever) they've fixed it.
When we looked at Mono we found only one viable service vendor and that was Novell. Their contract was prohibitively expensive (I think it was like $11,000) and their support stopped at Mono. Meaning to use this solution you'd have to have their support, plus a linux vendor support contract, plus Unity support, etc ...
I ran into a problem at a previous job with the catch-code in the "global" try block in an ASP.Net app, itself throwing an exception. IIS just dies with a 8-digit hex code that according to MSDN means pretty much whatever ("try some or all of these 15 different possible solutions").
It took a few days working the support, and I did get on a conference call with some brilliant people, and they figured it out quickly - using a (forget its name) debugger that talks directly to the CRL (which the one in Visual Studio apparently doesn't).
All this because (I think) something somewhere in that stack decided to "protect" me from the cause of the error.
This is generally my problem with Microsoft. No so much the arbitrary discussion of whether or not it sucks, but the difficulty of getting under its helmet, which tends to make problems much bigger than they ought to be.
That said, I wouldn't do this on a commercial project. Because when a bug does come up you just have too many layers to contend with. Is it a bug in my code, in the Unity Framework, in Mono, in the device or what? This is a particularly significant problem when dealing with Open Source projects with very little in the area of support mechanisms and Apple which seems to think far too much of itself to offer decent developer support.
So in the end it's a nifty proof of concept but I personally couldn't bring myself to trust it.