Choosing a mobile application development platform

Having developed several mobile apps and deployed them to both the Google Play and Apple Store, we have been forced to re-write the apps. The reason we have to re-write our apps is due to the fact that our development platform — Telerik Platform — has been retired. The reasons are probably so that they can focus their development efforts on their other cross-platform mobile technology — Nativescript.

That leaves us in the position of having our app in the app stores, but with no means by which to update them. We can update the RESTful services used by the apps as these are completely separate to the apps (thank goodness for good architecture), but we can’t make any changes to the apps themselves. That puts us in a slightly vulnerable position, as we can’t respond to customer suggestions or changes in market forces (or even change the branding / look and feel).

We have therefore been forced to re-evaluate the technologies that are available to us for developing the mobile apps. We have looked at several technologies. I have previously written why I think Building native enterprise apps is (probably) the wrong approach[^]. In relation to enterprise apps, there is very little (if any) benefit to going native (longer development cycles, greater expense, bigger teams with bigger skill sets, little overall benefit). Cross-platform therefore is the only approach on the table.

We firstly looked at NativeScript (the natural successor of Telerik Platform) as both are owned by Progress. This looked like a great development platform. Progress have made big strides in trying to ease the migration path of existing Telerik Platform users to their newer NativeScript platform. You can choose from Javascript, Angular or Typescript as the language in which to build your apps. It comes with a companion application called Sidekick to simplify many of the development processes. Has the support of a large community and backed by Progress (giving peace of mind). Also, it rendered native components on the device making it a truly cross-platform development environment.

The only other alternative that I considered seriously was Xamarin. I have used this previously (before the Microsoft acquisition) and so was already familiar with it. I was intrigued as to how it may have changed since the Microsoft acquisition. The first thing I noticed when looking through the documentation and examples was the tight integration with Azure. We already make substantial use of Azure with our other mobile and web apps, so it great to see the same design philosophy applied to Xamarin. In fact, the overall architecture used by Xamarin is not too dissimilar to the one I developed for our existing apps and current web app. This was a huge benefit to us right out the box, as I was already familar with the architecture and the key moving parts to building a mobile app with Xamarin. Like NativesScript, Xamarin also renders truly native components on the device.

I spent considerable time looking at both offerings, as well as taking into consideration the skill set of the team. In the end we have decided to go with Xamarin. I am far more familiar with C# and Azure (as well as the architecture of their apps) and this played a part in the final decision. Nativescript would have required us to learn Typescript. Although this is not necessarily a barrier on its own, the reality is that I will be up and running far quicker with Xamarin than compared to NativeScript.

A father, cyclist, vegetarian, atheist, geek and multiple award winning technical author. Loves real ale, fine wine and good music. All round decent chap.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store