http://blog.xamarin.com/2012/08/07/picturethis-fun-for-both-...
They have a nice case study.
You do not have to pay before you try, the evaluation version lets you do all your development on the simulator. If you like it, you can buy it and deploy to device. And if you are unhappy, you can return it within 30 days.
That said, we will work hard to make sure you are delighted with our product, and keep you as a user.
Layout was wrong, the application was ugly and non-native, and the final straw was the printing API that flat out crashed whenever we tried to use it. We ended up re-writing in Java, and achieving a relatively high level of quality in a short period of time. Java was easy to pick up after C#, and the tooling was much more mature than Mono.
MonoTouch for iOS works similarly, and bridges into native Objective C UI libraries (and you continue to use Interface Builder). Last time I tried it, it had the downsides of long startup time (2-3 seconds) and big runtime. However, if you're writing a big app, let's say 5MB, then going from 5MB to 7MB is probably ok.
I think MonoTouch for Android also uses native UI, but I have not tried it yet.
An alternative is to split your code along the business logic/presentation layer boundary. Share the business logic and write a platform specific UI using the native toolkit on each platform: WPF or Winforms on Windows, MonoMac (Cocoa) on Mac and Gtk# on Linux.
The Winforms stack has not been maintained for about 5 years, and was never particularly debugged nor maintained on Mac. We wanted to remove it, and just tell people "Sorry, this API is useless", but there are a few type dependencies that are needed elsewhere.