I wonder how folks are thinking about that problem - i.e., if you are starting a new app from scratch - even if you are doing iOS only initially - do you go objective-c or xamarin/c# ?
it's quite hard to make an educated decision.
any thoughts?
It is simpler to think of Xamarin as providing you with:
* C# language on iOS, Android, Mac * 1:1 API bindings to whatever is native on a given platform. On iOS, the CocoaTouch APIs, on Android, the Android APIs, on Mac the Cocoa/CoreFoundation-based APIs.
From this basic setup, you can already see that you wont get code that will run on all platforms. You will need to split your code into cross-platform code (database access, web services, xml, json parsing, offline caches, authentication) and things that are UI-specific (Android activities, Android widgets, iOS View Controllers, and so on).
This actually is the reason I keep away from Xamarin, and I guess I'm not alone...
I think that there is a room for having a cross-platform lowest-common-denominator, including UI, File system, Networking, etc... with ability to dive into platform specific details when needed.
But it also supports the full experience for each platform.
At least, that's my understanding and OP (Miguel) confirms it. And I guess your mileage won't vary in this aspect ;)
Although, Xamarin.Mobile is a step in the right direction, as commented here.
Yes, but they do offer a "base" abstraction layer besides the C# libraries, that includes stuff like GPS access, accelerometers, etc.
As for the UI part, one could use a Webkit View as the view, and link the various heavy actions to C# code. For something like a common denominator UI, for a simple calculator or some form based stuff, it would be perfectly fine.
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.
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.
A lot of the bindings can be found here: https://github.com/mono/monotouch-bindings
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.
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 think for me, having a decade plus of C# experience this was a no-brainer. Moving from building web apps to mobile on a new platform was a big shift and removing the confusion of a new language helped smooth the transition.