4 ms·

I am a bit ambivalent - on one side, as I think about new product ideas that will naturally be multiplaform, something like this is very appealing in theory, bu

I am a bit ambivalent - on one side, as I think about new product ideas that will naturally be multiplaform, something like this is very appealing in theory, but my experience tells me that the lowest-common-denominator approach has almost always failed. 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?

natfriedman 14y ago
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#. http://xamarin.com/how-it-works http://xamarin.com/how-it-works
- PabloOsinaga 14y ago
  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.
  - jstedfast 14y ago
    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. A lot of the bindings can be found here: https://github.com/mono/monotouch-bindings https://github.com/mono/monotouch-bindings
  - keithwarren 14y ago
    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.
  - migueldeicaza 14y ago
    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.
jstedfast 14y ago
Just to clear things up, Xamarin.iOS and Xamarin.Android are not really "lowest common denominator". They are full bindings for the underlying platform APIs.
migueldeicaza 14y ago
We do not actually provide a lowest-common-denominator. 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).
- zura 14y ago
  >We do not actually provide a lowest-common-denominator. 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.
  - jstedfast 14y ago
    We've got some abstractions that build on top of the native APIs as well such as Xamarin.Mobile.
  - coldtea 14y ago
    Nothing stops you from treating Xamarin as one. But it also supports the full experience for each platform.
    - zura 14y ago
      You can't treat Xamarin as one... e.g. you can't write a simple calculator UI in a cross-platform way - You would have to code the UI part separately for iOS and Android. 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.
keithwarren 14y ago
The LCD argument is false here, there is nothing that can be done in Objective C through public APIs I cannot do with C#/Xamarin. The day after iOS 6 was released, Xamarin had an update to Monotouch. The betas were available before that as well. 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.

natfriedman 14y ago

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#. http://xamarin.com/how-it-works http://xamarin.com/how-it-works

PabloOsinaga 14y ago
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.
- jstedfast 14y ago
  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. A lot of the bindings can be found here: https://github.com/mono/monotouch-bindings https://github.com/mono/monotouch-bindings
- keithwarren 14y ago
  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.
- migueldeicaza 14y ago
  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.

jstedfast 14y ago

Just to clear things up, Xamarin.iOS and Xamarin.Android are not really "lowest common denominator". They are full bindings for the underlying platform APIs.

migueldeicaza 14y ago

We do not actually provide a lowest-common-denominator. 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).

zura 14y ago
>We do not actually provide a lowest-common-denominator. 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.
- jstedfast 14y ago
  We've got some abstractions that build on top of the native APIs as well such as Xamarin.Mobile.
- coldtea 14y ago
  Nothing stops you from treating Xamarin as one. But it also supports the full experience for each platform.
  - zura 14y ago
    You can't treat Xamarin as one... e.g. you can't write a simple calculator UI in a cross-platform way - You would have to code the UI part separately for iOS and Android. 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.

keithwarren 14y ago

The LCD argument is false here, there is nothing that can be done in Objective C through public APIs I cannot do with C#/Xamarin. The day after iOS 6 was released, Xamarin had an update to Monotouch. The betas were available before that as well. 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.