Just starting out, debating use of Xamarin


I am just starting out writing a mobile app for iOS and Android. I am looking at various technologies and trying to make a sound decision on what to go with. I've been toying around with Xamarin for a few days with a nice little prototype running.

I feel pretty comfortable with this framework but I do have some reservations about it.

The primary reason for choosing Xamarin would be the possibility of writing a single codebase and deploying to multiple apps. I am now starting to doubt that this is even the case, as I look over documentation that is specific to either iOS or Android. Is this a selling point of the Xamarin framework? If so, are there any architectural best practices to observe so that some of the discrepancies between iOS and Android can be resolved elegantly?

As a C# devleoper I understand that another selling point for Xamarin is that I can simply use a language that I am comfortable with. But to be honest, the further abstraction from the native languages does not sit well with me. I am very comfortable learning a new language and framework, especially free ones! Besides, every day for the last week that I have been toying with Xamarin I have found many stability issues especially to do with their Visual Studio integration. It's worrying me to think that I will deploy production packages in this state.

In any case, I'm interested to hear thoughts on my concern about multiple codebases, which is really what I am trying to avoid.



  • JasonAwbreyJasonAwbrey USInsider, University, Developer Group Leader mod

    For point 1, the platform specific parts of your code (primarily UI) will need to be written per-platform. The common parts (data, services, domain, business logic, etc) can be shared. Xamarin has several sample apps that demonstrate different ways to architect solutions to share common code.

    For point 2, keep in mind that it's not just learning a new language and framework, it's learning 2 of them (Obj-C and Java). It's a personal decision about whether this trade off is worth it - I personally think it is.

  • Hi Jason, thanks for the response. I am just going to throw some thoughts out and see what you think. I am not trying to refute you :)

    I've architected my solution so that my business logic and everything further down the stack abstracted through an exposed API over HTTP. Of course, that is all written in C#. My iOS and Android apps will simply make calls to that API.

    In that scenario, does it make sense to perhaps stick with the native languages for native app development given that I am okay biting the bullet regarding objective-c and java?


  • If so, are there any architectural best practices to observe so that some of the discrepancies between iOS and Android can be resolved elegantly?

    A few things:

    Implement the MVVM pattern. From simple, the Xamarin field service app or MvvmCross. By doing so you can move code out of ViewControllers or Activities that probably aren't view concerns into your view models and services.

    If the MVVM pattern seems heavy, this is another interesting way to share code through partial classes and some other tricks.

    Abstract out platform specific things so your view models can talk to an interface to do stuff with location services or storage for example. MvvmCross shines in this department.

    Event if you abstract things out into a rest service you will still have two different code bases that do all the stuff needed to create requests, call the service, parse responses, deal with errors, etc.

  • AndreKohnAndreKohn DEMember
    edited March 2014

    Hallo Jeremy,

    I'd slightly disagree with Jasons' Point 2.

    You will need to learn very much about the native APIs of Android and iOS anyway as not abstracting from them is clearly a design goal of the Xamarin framework.
    As a good boarding point it might be very useful to understand how Xamarin does what it does by understanding things like the JNI, ACWs MCWs or ARC.

    It might also be very helpful to learn the characteristics of the language Objective-C as the protocols and the weak type system have some important implications.

    If you got that you will understand why using Xamarin is very much like using a complementary technology instead of a substituting one.

    As by far most important strength of Xamarin it allows you to use Portable Class Libraries to write your logic platform independently. Like DerekBeattie correctly wrote architectural patterns like MVVM (well MVP or MVC fit equally) will help you to clearly seperate the platform dependent views and navigation characterstics from the logic of your application.

    That implies many advantages as you only have to manage a single codebase that can be written with powerful tools like Resharper in VisualStudio and easily tested centrally with NUnit or even Microsofts testing tools.

    If you have concerns regarding the stability of this approach i'd like to point out that the mono implementations on the platforms and the specific API wrappers are working really well. There can be hassle when dealing with the Visual Studio extension but once everything is set up it works pretty convenient.

    So in the end you need to decide whether you want to write three code-bases that definitely need to be managed independently from each other or unify them into one.

    To learn the whole extent of the development with Xamarin you probably want to read books targeting each of the platforms in addition to the documation on this website anyway.

    Best regards

  • SKallSKall USMember ✭✭✭✭
    edited March 2014

    To add to what others have said, to me it is also about productivity. I could write everything natively using ObjC and Java but using C# and common codebase is a great timesaver. Even compared to Java using C# saves time but compared to ObjC...huge difference.

    Take ORM for example, serializing data from web service or storing it to database. I have not looked lately into if there are any new libraries for ObJC but compare f.e. RestKit to how you can communicate with a webservice using C# instead. The amount of boilerplate code is huge in ObjC:


  • jamesp111jamesp111 GBMember


    I'm trying out Xamarin at the moment as well, and the main concern I have is that I could write valid C# code that doesn't work when converted into Java/Obj-C, and is impossible to debug.

    Does anyone have any experience of this?

  • AndreKohnAndreKohn DEMember

    Hi @jamesp111‌ ,
    perhaps you should try to learn the internals of Xamarin first.
    Your C# code is not getting converted into Java or Objective-C in any form.
    Dependent on the platform your code runs in a mono JIT environment (Android) or is compiled natively (iOS).

    As a result some features of .NET are not supported (e.g. some forms of Generics).
    In case of iOS many of these incompabilities should be catched by the ahead of time compiler but anyway this could be a reason for your problems.

    For further assistence you could simply open up a new thread and describe your error.

    Best regards

  • SKallSKall USMember ✭✭✭✭

    @AndreKohn‌, I don't think he is having issues at the moment but his concern of course is valid. Whenever you introduce a new tool to the chain you are introducing new bugs associated with that tool. Looking at the release notes for each Xamarin release is a good indication of this. Overall I think the problems are minor.

  • AndreKohnAndreKohn DEMember

    Ah sorry, for sure I just got that wrong.

    Well, I just think it is very important to not compare Xamarin as another chain link as the tools are heavily backed up by the proven Mono project.

    If Xamarin shall reach a wider acceptance it is essential to differentiate them from tools like Titanium that actually implement another layer on top of the native language.

  • wallymwallym USInsider, Beta ✭✭✭

    @jeremyalexander, this is a great question and one I get all the time. There are many answers to this question. For me, there are two parts to the answer. First, I get to write c# to target iOS and android. For me, that is a huge boost in productivity. I don't have to learn a new language for this at all. How much time would it have taken me to learn objective c? Probably an infinite amount of time due to my lack of patience. With xamarin, I have to learn the platformisms, which I can do. With objective c, I have to learn a new language, the platformisms, and a new tool. For me, that is probable too high of a price for apple's walled garden.

    Second, I can create a native ui with xamarin's tools. Creating a native ui is an advantage of xamarin's tools, not the disadvantage some seem to say. Users want apps that look like all the other apps on a platform. Xamarin lets me do this in c#. For me, that is winning.

    From there, you can add pcl support, integration with native libraries, same tools, and a number of other features.

  • RobertDebaultRobertDebault USUniversity ✭✭✭

    I have been developing Enterprise applications in .NET for many years using both c# and vb.net. I started developing in Objective-C in 2010 and came across the Mono toolset around the same time. I have been developing using the Mono Toolset and now Xamarin Studio ever since. I don’t find myself using Objective-C much anymore since the Xamarin libraries are so complete. I have many cross platform applications deployed and I find I can reuse almost 95% of my code. I have not been able to find one reason not to use Xamarin. Now just so you now I develop on a MACBOOK using Xamarin Studio but I also have a Virtual PC setup on the same machine so I can do my .NET development. Funny thing is my Virtual PC runs faster then my physical PC. I consume a lot of WCF services in my mobile applications and find that it all works flawlessly.

  • GuillermoGutierrezGuillermoGutierrez ESMember ✭✭✭

    It seems that I'm the only one that didn't have a .Net background, so I'll drop my 50 cents here.

    My knowledge about .Net and C# was very close to 0, I worked in Java for several years and almost exclusively Objective-C for the last 5 years. All my clients asked me for iOS Apps and around 20% of them wanted an Android version. So, to sum up, around 5 years of iOS native Apps and around 2 years of Android native Apps with the vendor tools (ObjC+XCode and Java+Eclipse).

    I've been developing Xamarin Apps for nearly one year. The learning curve for C# is practically flat coming from Java. The only 'strange' feature that I encountered is LINQ, but I used something very similar in Ruby anyway, so nothing to worry about there. The main obstacle was learning MVVM to obtain a high code reuse by using MvvmCross.

    The main PROs for using Xamarin:

    • Objective-C is a terrible language, and Foundation framework is horrible. C# and .Net is a pleasure compared to Objective-C (although new auto-generated @synthesizes, ARC and blocks have improved the developments a lot).
    • Code reuse: This is the main point of using Xamarin at all. Code reuse implies faster developments, lower costs, easier maintenance and better benefits of the acquired knowledge.
    • Mono framework: async/await, DateTime, Timers... there are some stuff that makes the framework a joy compared to native frameworks. (Seriously Apple, date handling in iOS is a pain).
    • Unified development tools.
    • MVVM.

    And of course, there are a bunch of CONs:

    • Xamarin bugs. There are a lot of bugs. They are working on it, just keep an eye on the release notes. But most of the time you are looking for workarounds because the bugfixing response times are pretty bad. Xamarin updates usually break one thing or another and they seem to be focused in adding more functionality rather than fixing some outstanding bugs. It's the main issue of adding another tool to the build chain and can be very frustrating at some point.
    • Bigger application size. This is not an issue for big Apps, usually the resources take more space. But for simpler Apps, a simple ARMv7+ARMv7s HelloWorld app is around 8MB compressed compared to a few KBs for iOS native apps.
    • Startup time. Hello world apps takes more to 1 second more to load than native Java equivalent and memory cons, and close to 0,5 seconds on modern iOS devices.
    • Memory consumption. Related to the previous one. Starting Mono framework is not free in time nor memory. Hello world MvvmCross App takes 10MB on startup whereas the same native App stays below 1MB.
    • Development environment. Eclipse is pretty unstable (JetBrains comes to the rescue), but XCode is a wonderful IDE once you get used to it. Xamarin Studio is decent at most. It crashes every now and then when editing big files (~500 loc). No in-code documentation for iOS or Android platform frameworks. XML editor is a shame, I think it's better to completely remove it rather than providing it like that. Debugger sometimes crashes with no apparent reason. VisualStudio + Resharper is your best choice (if you have some bucks to spare) for developing in Xamarin. But get ready to get bitten by bugs.

    Overall. I think that it's worth it. And it's not expensive compared to other cross-platform tools.

    Hope it helps.

  • RobertDebaultRobertDebault USUniversity ✭✭✭

    Interesting Cons Guillermo, I have had many more problems with Visual Studio then I have with the Xamarin Studio. Of course I do quite a lot of development with both. Excellent write up though and I concur Xamarin is still the best choice on the market today.

Sign In or Register to comment.