Targeting/Developing for multiple mobile platforms with one programming language (C#)? Cost-Benefit?

StackOverflow https://stackoverflow.com/questions/5335764

Question

Today it is possible to use C# programming for multiple mobile platforms such as:

(feel free to edit if I missed some) Of course, it is still programming effort for UI, but main libraries of app can be shared.

We can all thank to a team gathered around Mono project and superhero Miguel de Icaza whose effort is priceless.

What bothers me is, what are the benefits of these options? Is it cost of maintaining one app across multiple mobile platforms less impediment then having to code each library separately for better performance. Learning curve of each language? Being Jack of All trades vs .NET Ninja

Or knowing that binaries of app programmed in native environment are less in size, maybe even optimized better and not to forget that you have to wait support of new platform os updates.

UPDATE: Obviously there is one more thing to consider and that is support. Since Novell is bought by Attachmate Group, all Mono team is laid off. However the core member of the team lead by Miguel De Icaza founded new company Xamarin which will reinvent Mono Mobile development tools from the scratch.

Was it helpful?

Solution

In my opinion, the big pro of using one single environment (i.e. C#/.NET) is code portability. And cool things like LINQ that, once you get used to it, you can't live without. However, the few mobile OS's (iOS, Android, WP7) are quite different with regards to UI.

And, if I am not mistaken about your application, it's got a fair share of UI interactions if it is to run on a mobile device. Most mobile apps are like 80% UI code.

Therefore, you'll end up writing a separate set of UI code for each platform anyway -- for example, you'll be writing in Silverlight WP7 (and all the WPF goodness), you'll be writing a completely different set of code for iOS in Cocoa (IB, Views, controllers and stuff), you'll be writing yet a completely different set of code for Android.

My experience has always been that it take a lot of experience to write good UI code on any platform -- e.g. learning WPF/SL is already the nightmare that is, throw in Cocoa Touch and the whole Android mess. Of course you can write three sets of UI that look and feel reasonably similar, but chances are that you'll be trying so hard to reuse code and have common data structures that your UI's will end up sub-par when compared to dedicated apps -- and in this cut-throat world of mobile apps today, a non-super (not to mention sub-par) UI experience means death to your app.

Also, all three mobile environments have different connectivity paradigms, as well as multimedia paradigms. You end up writing three versions, and learning three environments, albeit writing in one language you're familiar with.

The most you're going to reuse is back-end modules. Decision engines, search routines, data-management etc. And even these are going to be problematic because you'll be force to have compromises in your data structures just to enable easy integration with three different sets of UI code working on three different UI paradigms. For example, do you use DependencyObjects for use to bind to Silverlight views in an MVVM model? If you do, it won't work with Cocoa's MVC model, and you have to code those bindings separately.

And since not all mobile environments enable you to use the full set of functionalities -- for example, MonoTouch for iOS does not generic constructs that cannot be determined at compile time. You're essentially using a very small subset of .NET (and must constant be reminding yourself what functionality can be used where) just so that you can run them all on three different platforms without significant changes.

Now image having all these limitations when you are writing for the WP7 platform, which supports the entire .NET features set. I don't know about you, but I'll go crazy. And your WP7 app is never going to be even close to being competitive with other apps out there.

In my opinion, the pain and the compromises are not worth it. You'll end up with three so-so apps, which people in neither of the platforms are going to like.

Unless all the goodness lies in your app's back-end logic, and it is so good that people are going to ignore UI issues just to get to your app's back-end functionalities. In my experience, this almost never happens.

OTHER TIPS

The biggest advantage for me is the ability use reuse the business logic and communications code between mobile platforms. Yes, I have to write the UI over and over again, and it takes time to get your head around that, but at least my base platform is reusable.

In my experience when moving to a new platform, it takes me a lot longer to learn the UI framework than to learn a new language.

Since the accepted answer had been written in 2011, a couple of different frameworks have emerged, which bring MVC and MVVM patterns to Mono for Android and MonoTouch, which helps quite a lot when developing applications for these targets.

For MVC check out the project called MonoCross

For MVVM check out Stuart Lodge's MvvmCross

The latter contains a lot of code for opening images on the three platforms, composing e-mails, opening webbrowsers, playing sounds and much more. It aslo handles navigation between ViewModels.

a big advantage is certainly the reusability of code / class libraries across the platforms. With that in mind you`re able to port/develop applications even faster, which in turn reduces the costs.

Also, because of the reusability of code, it will reduce maintenance expenses.

There are certain drawbacks to the Monotouch/Droid-libraries. There is a little speed setback (about 5%, so neglectable in most of the cases).

In my experience, the size does not differ that much. Much of the size is in the resources (data resources, packed images and alike - not processor usage), and most apps don't carry that much resources with them (because of loading times and the availability of much default controls on mobile platforms).

I don't think you should use the frameworks on games however. I don't have much experience in mobile game development, but the pretty different frameworks you're using in game development (XNA, Android's NDK..) and the need for system resources (processor usage, memory etc.) make them pretty useless imho.

Advantages:

  • Code all in same language and (mostly) usable on each platform
  • Reduced development time
  • Cheaper

Disadvantages:

  • Including needed libraries increases minimum application size quite significantly - if you're app is going to be large then the difference is not so significant
  • Performance overhead

If you have the money and the people it's always better to have some people focused on the iPhone and Objective-C, some Android and Java etc. That way your programmers will have an intimate knowledge of the platform you are targeting and will be able to make sure your application takes full advantage of the platform's features -- an app should not be exactly the same (except perhaps games) across all platforms, you need to play to their strengths and weaknesses: an iPhone app should look and function like an iPhone app etc.

That said, if you don't have the people or the money, using a single language together with several frameworks is certainly cheaper and faster, and may give you better results than the result of strained attempt to develop for each platform individually.

Another way to look at this is you could port an existing .NET/C# application to a variety of mobile clients (both native and non-native) relatively easy using WebORB integration server. On the client side you would have to code in either the native language or you could create an Adobe AIR application that is fairly portable across different mobile OS' such as iOS, Android and BlackBerry PlayBook.

Cross-platform solution only works if your application is simple and straightforward. If you require complex features such as local data store with complex object graphs, go native or expect to spend months to debug problems

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top