Managed languages are designed with a different set of goals than unmanaged languages. C#'s design goals were in general to reduce the number of bugs, help developers write better code, and maintain the code over the long term.
It has evolved over the years to also adopt new programming techniques that have proved to be useful (generics, iterators, functional constructs, delayed-execution frameworks, Async programming features and dynamic features).
But the idea is that you start with a safe environment that is relatively fast, close to C, but where the goal is not maximum speed, but increased productivity, fewer bugs.
Then you try to optimize things to get closer to the performance of a native C compiler. For some things, you can get there, for some others you can not do it.
So it leads to a different style of programming, you spend less time thinking about book-keeping, about making sure that you did not free the same buffer twice, ownership rules and so on, and you can focus more on the problem at hand. In day-to-day life, you spend less time tracking down production bugs.
It is not a silver bullet, and wont fix every problem, and you still need to do careful bookkeeping of other things (like, did you load too many images?) but at least you can ignore the grueling minutiae and focus on what matters most.
It is a little bit like the difference between using raw OpenGL and loading your vertices manually every time or using a toolkit that loads meshes and textures for you.
We are hard at work in upgrading both MonoTouch and MonoDroid to use Mono 3.0's compilers and class libraries. That is why you have seen a flurry of commits to Mono's master tree.
Nothing's wrong with Objective-C. But if you're interested in sharing some code to do cross-platform apps Xamarin makes it easier to do so with C#. You might write a layer to do API and data management/storage and general business logic and then share that code between Mac, Windows, iPhone, Android, Windows Phone, and Linux.
It would still be a lot of work because they don't try to abstract any of the UI or other things for you (and imo, they shouldn't). But if your app fits into this kind of design, and if you like C#, then it could be very valuable.
It has evolved over the years to also adopt new programming techniques that have proved to be useful (generics, iterators, functional constructs, delayed-execution frameworks, Async programming features and dynamic features).
But the idea is that you start with a safe environment that is relatively fast, close to C, but where the goal is not maximum speed, but increased productivity, fewer bugs.
Then you try to optimize things to get closer to the performance of a native C compiler. For some things, you can get there, for some others you can not do it.
So it leads to a different style of programming, you spend less time thinking about book-keeping, about making sure that you did not free the same buffer twice, ownership rules and so on, and you can focus more on the problem at hand. In day-to-day life, you spend less time tracking down production bugs.
It is not a silver bullet, and wont fix every problem, and you still need to do careful bookkeeping of other things (like, did you load too many images?) but at least you can ignore the grueling minutiae and focus on what matters most.
It is a little bit like the difference between using raw OpenGL and loading your vertices manually every time or using a toolkit that loads meshes and textures for you.