Mobile Applications? Xamarin.Forms? Why?

by | Apr 4, 2017

Mobile Applications?

As mobile applications continue to gain in popularity, businesses are presented with a very serious question.  Do we need a mobile application?  Per ComScore, Digital Media usage has increased 26% for tablets (small form factors), 99% on Smartphones and decreased 8% on Desktops in the past 3 years.

Graph depicting growth in digital media time spent in minutes

I know what you are thinking.  “We have a responsive website that people can use, so we are covered for mobile already, right?”  Not exactly.  Here are some interesting statistics that I have come across while scouring the internet to find answers to this question:

  • There are more mobile phones than PC’s.
  • 64% of mobile phone time is spent using Apps.
  • Customers use mobile Apps 6x more than websites.
  • People check their mobile phones over 150 times a day. That is 1 in every 6 minutes.
  • 79% of phone users use their phone to make purchases and Over 50% of those people purchase within 1 hour as opposed to 1 month when on a desktop.
  • 85% of users prefer mobile apps over mobile websites.

So, what does that mean?  Well, it is simple.  People are using their phones all the time and they are looking to use an application as opposed to a website.  There are some advantages to creating mobile applications as well.

  • Interactivity – generally, if your application needs a lot of interaction, mobile applications will outperform most web applications.
  • Complex Calculations or Reporting – Taking data, manipulating it and seeing complex calculations take place in real-time, will almost always perform better in a native application.
  • Personalization – If your user needs to use a lot of personalization of the application, native applications provide great ways store and customize settings locally, while still allowing for syncing these settings across devices.
  • Native Functionality – if your application needs to access mobile specific functions such as mobile calling, SMS, Camera or even need more processing power, mobile applications will usually provide this functionality out of the box.
  • Offline Capabilities – if your application needs to support offline access and synchronizing, a mobile application will surely fit the bill.
  • Tools – native development tools are generally far more advanced and allow for greater debugging capabilities.
  • Distribution – distribution of mobile applications have come a long way. Now it is as easy as clicking an icon, accepting access rights and you are up and running.  This is a one time effort.  An advantage of websites used to be the ease of updating the service.  However, updates for mobile applications have also become almost transparent to the user almost eliminating the advantage entirely.
  • Discovery – outside of doing searches on the web, mobile applications are easy to discover and search for in their respective application stores.

Although several of the advantages above may also be implemented via the web, the effort involved is far greater and results are not always as performant or easy to maintain.

KEY POINT:  A well-made mobile application will almost always provide a better experience than even the best websites.

Traditional SaaS vs Mobile SaaS

I should note that traditional SaaS strategies over the last couple of years have been forced to redefine what SaaS really means in the wake of mobile application popularity.  Enter, Mobile SaaS.  Basically, the concept of Mobile SaaS is more about applications than it is about web-browsers.  What this really means is that instead of using a browser to host the application, the native OS application hosts the same logic you would expect in the browser but connected to one or more cloud-based services.  These services could include authentication services, data services and/or business logic.

Xamarin.Forms?

So, at this point, you might be asking yourself, “Okay, so it seems obvious that native applications are the best experience, but now I must support multiple teams, with multiple skill-sets and with multiple code bases, right?”  Not exactly…

Enter Xamarin.Forms.  Xamarin.Forms is a Microsoft owned company that started with the engineers that created the popular Mono, Mono for Android and MonoTouch, which are cross platform implementations of the Common Language Infrastructure (CLI) and the Common Language Specifications, also known as .NET.

Xamarin.Forms, uses a shared C#/.NET codebase along with either Xamarin Studio or Visual Studio, to write native Android, iOS, and Windows Apps.  Did you understand that?  Yes, native applications.  Wow, so, all your code is 100% shared.  Again, not exactly.  But, close.

For most simple UI patterns, Xamarin.Forms allows you build native user interfaces for iOS, Android and Windows using 100% shared C#.  It also includes dozens of controls and layouts which are mapped to native controls in their respective platform.

Depending on your application needs, however, you may need to access a platform specific feature, such as Live Tiles for Windows, or maybe you need to create a custom control that isn’t a native control for any of the platforms.  In these scenarios, Xamarin.Forms provides a means to call into platform specific code.  However, check this out, … wait for it … wait for it … it is still in C#.

Image of what you get when you use Xamarin and Xamarin.Forms

So, as you can see, the App Logic and most of the user interface code is shared across all platforms.  In fact, there is even a community of user-built components that you can leverage in your application using both NuGet and the Xamarin Component Store.

Why?

So, I mentioned earlier why we should build native applications for mobile devices.  Then, we posed the question of having to support multiple teams, with multiple skill-sets and with multiple code bases.  Did I answer that question?  Well, not directly.  All I did was throw out a possible solution to the problem.  So, let me be a little more direct now and tell you why you should consider using Xamarin.Forms for your mobile application.  The points I make below should help finish my answer.

Learning Curve

If you already have a development team that is familiar with the C# and the .NET stack of technology, this is almost a no brainer.  They might have to learn a little native code development and/or deployment techniques for each, along with some minor syntactical sugar, but that is minor compared to learning it all from scratch.

What if you don’t have a .NET stack set of resources?  Well, then your learning curve will be larger, but not nearly as large as if you had to learn, native iOS, Android and Windows development languages.  In this scenario, you really only have to learn one language, C#.NET, and maybe a little here and there with the other languages.

Xamarin.Forms keeps you as close to one language as possible.

Platform Uniqueness

I talk to people about this all the time.  A lot of mobile websites tend to make their sites look the same in each browser.  Now, for some sites, especially marketing sites, this makes sense.  However, what I usually argue is that people buy and use devices based on their preference of the user experience  that comes with that device.  That might mean navigation, application support or physical hardware resource.

I know what you are thinking, “but you can use some fancy library or magical CSS to make the site look more like the device it is running on.”  Yep, you can, but why?

Xamarin.Forms basically gives you this user experience by embracing the uniqueness of each platform by using the native controls specific to that platform.  Natively.

Faster to Market

By creating a shared set of business logic, time to market is minimized.  Gone are the days where we are implementing business logic in multiple languages, coordinating functionality across multiple projects with varying deployment schedules.

Xamarin.Forms allows you to write one set of code that gets compiled for each platform enabling you to get your applications in the hands of the users faster.

Less Bugs

This might already be obvious, but since we only have one set of business logic code, it can be tested, fixed and deployed much faster.  Generally speaking, the less code you write, the less number of bugs you have.

Another reason for less bugs is the incredible support for testing and debugging built into Xamarin Studio and Visual Studio.  Couple that fact with less, but more effective, tests that focus on one set of code, as opposed to multiple tests for multiple sets of code bases, and your test coverage can be the same across only one set of code.   Saving a lot of time and testing.

Xamarin.Forms allows us to spend less time writing tests while maintaining coverage of one code base.

Future Proof

Knowing that your investment into your mobile applications is important, and that technologies are constantly changing, having a single code base isolates a lot of business logic that isn’t dependent on a specific platform.  This means as platforms change, or new platforms are introduced, Xamarin.Forms is in the position to respond quickly and provide support.

Xamarin.Forms provides a means to move in any platform direction, including new platforms in the future.  (Of course, that Xamarin.Forms supports)

Summary

Well, my hope with this post is to help give you enough information to make the right decision for your company.  Websites or Mobile Applications.  With the popularity of mobile devices, their usage and the desire from users to have mobile applications over websites, one must consider the tools available to get solutions developed, running and into market quickly.  Xamarin.Forms is one of those tools.

Come back soon as I attempt to show you how quickly you can get setup and create cross platform applications using Xamarin.Forms.

If you found this useful, please share with others.

Building a mobile application and need assistance? Intertech knows a thing or two about Xamarin.Forms. We provide along with services to your team. See how we can help!