It isn't a lowest-common-denominator approach. We expose the entire native API on each platform. So anything you can do in Objective-C, you can do in C#.
I see. In your experience, do people end up complementing the platform-specific C# UI code with native (e.g., objectiveC) pieces?
My worry is there are so many nuances in building a rich UI app - that even searching/finding samples online for specific things will make me want to have native/objectiveC elements into it - as opposed to trying to hack the sample in C#. I just want to copy and paste!
How does that native-C# binding happen? Is it user friendly? Is it your expectation that most folks out there will have this duality? (if not most of the UI code being native?)
I am literally sitting on a new idea that will be multi platform by nature and am wondering all these things as we speak here.
In my experience, all the code is written in C#. The only time when folks use Objective-C is when they are bringing some existing library they found on GitHub to their project. And even in those cases, they dont actually write Objective-C, they just use the library.
In my experience, copy-paste development is seldom a recipe for creating high-quality applications. So I do not think you should be worried about not being able to cut and paste code, you will be better off understanding what the code is doing and adapting your code (even if you do so in Objective-C).
As for how the C# binding happens, it is very simple.
Each Objective-C type exists with the same name in C#. You typically use intellisense to navigate the API.
For example, the Objective-C code: [foo addSubview:bar] becomes: foo.AddSubview (bar) in C#
The best thing to do is to follow our tutorials to get a taste for it.
I will let one of the Xamarin guys speak to this in detail but having built a couple apps for customers with Monotouch I can tell you that you can pull in some native objective c libs for things like richer UI. There is a method for creating a binding to a native objc libs and using it from C#. I use ATMHud, TestFlight and Flurry in one of my apps - all of which are built from bindings to the native objc libraries.
The other thing I will say is that while there are 1:1 API mappings they have also went out of their way to make some common and rigorous tasks simpler. TableViewSource is one that comes to mind, simplifies the UITableView scenarios.
I think you'll actually find that translating Objective-C snippets into C# to be trivial for the most part.
For third-party ObjC libraries, a lot of the more popular ones are already bound.
Writing your own C# bindings for ObjC isn't that difficult, but there is a learning curve involved. We're working on making improved tools to automate more of it, though. In the meantime, we've got a guy that is writing the bindings for libraries based on popular demand.
http://xamarin.com/how-it-works