App Development

Xamarin vs. native app development

xamarin-vs-cordova-phonegap

As mobile developers, we are often asked about what it’s like working with Xamarin versus working directly on a client’s target platform. As with anything, there are upsides and downsides to both. One of the most important things to remember, though, is that Xamarin compiles to native code and uses native APIs to display all of an app’s UI. This means the best Xamarin apps should take advantage of all of the platform’s common interface paradigms and best practices. A well-written Xamarin app should be indistinguishable from its native counterparts. Here are the tradeoffs, as we see them, of using Xamarin over working in each platform’s native environment:

Upsides of Xamarin Over Native

  • Shared Core Code: While issues relating to portability can arise, code sharing between iOS and Android is pretty uncomplicated and simple. Networking, business logic, parsing logic (including error handling), navigation logic, models, and view models are shared between all versions of the app. What this means is there are no discrepancies in functionality between platforms, resulting in similar operation and easier bug hunts. In fact, of all the bugs reported in our Xamarin apps only a small handful are platform specific, and this means they only need to be fixed in a single place by one person at a time (instead of many different locations).
  • C# : One of the biggest perks Xamarin affords us is being able to write in C# across all platforms. Objective-C, Swift, and Java are all great languages, but C# has evolved considerably over the years and allows us to develop and iterate much faster with strong type safety. More recent patterns in C# (generics included) like LINQ, implicit typing, extension methods, async methods, and closures make what would be incredibly long boilerplate code in other languages completely unnecessary, which helps create cleaner, more readable, and more reliable code.
  • .NET (and Other) C# Libraries: The .NET libraries (including HTTPClient) are fantastic, and so is the upped support of PCLS and a few of Microsoft’s recently relicensed libraries. Xamarin’s support for all these libraries makes executing complex tasks on the platform an almost effortless experience.

Downsides of Xamarin Over Native

  • Lag Time: Xamarin is incredibly good about getting interfaces to new APIs out very quickly, sometimes the day they’re released. Unfortunately, APIs don’t always make up the whole platform story, and there are other areas where Xamarin can tend to lag behind some of the platform tooling. The current example of note is that the current release of Xamarin does not support tvOS or watchOS 2 in stable channels, and has limited support for binding against Swift only libraries. If you want to use the latest and greatest features on a platform, you may need find yourself needing to wait.
  • Third-Party Library Support: On both iOS and Android, there are certain third-party libraries you get used to using, especially UI components that make life easier on your target platform (including some that we’ve created internally). Unfortunately, using these libraries on Xamarin is non-trivial. Even though Xamarin offers bindings for some of the more popular libraries, some developers would need to provide bindings for themselves, and this is not as easy as Xamarin makes it seem.
  • Non-Portable .NET Libraries: If you decide to use a PCL core library, you will have problems finding third-party libraries that support it. Some companies that offer .NET libraries to interface with their APIs do not yet offer PCL versions, or do not have PCL versions that support Xamarin iOS or Xamarin Android. This is particularly true for Google APIs. While Google offers PCL versions of some of their libraries, they do not have versions targeting Xamarin platforms. This means you would have to rely on the native libraries, which have the drawbacks listed above, or Xamarin implementations. Thankfully, with the new Shared Projects systems in Xamarin Studio and Visual Studio, you do not necessarily have to use PCLs.

Our Recommendation

We really like using Xamarin, but occasionally the upsides don’t outweigh the downsides. Rather than recommending Xamarin or native for all projects, we suggest using Xamarin when the following is true for your app:

  • Your app has a significant amount of on-device logic that is not, or cannot be, handled on a backend server. Otherwise the amount of code shared is minimal, so you don’t save in terms of cost or complexity, but take on all of the risks of the platform.
  • You have a team that is already well-versed in developing and maintaining C# or .NET systems, and you intend on maintaining your mobile app long term. In this case, the costs of having your team learn multiple new languages and technologies (or hiring an entirely new team) can make the native development route cost prohibitive.
  • You want to support one or more Windows devices, and have a moderate amount of shared on device logic. In all cases, we recommend working with a team that really understands your target platforms, and that will guide you to the best user experience for each.
Quickstart-Guide-to-Kotlin-Multiplatform

A Quick Start Guide to Kotlin Multiplatform

Kotlin Multiplatform, though still experimental, is a great up-and-coming solution...

Read the article