Choosing a Mobile Development Platform

I've written a lot about the subject of choosing a mobile development platform; how to compare mobile development platforms, which ones perform better and it what circumstance. A lot of what choosing the right mobile development platform comes down to is mitigating the risk of choosing the wrong platform for your organization's needs and having to engage in expensive refactoring or rewrites later in the process.

In my mind, the need for this decision normally comes into play when you have to create applications for more than one mobile platform. Quite frankly, I you have the luxury of only needing to develop for one platform use the native tool set; it will give you the platform vendor's vision on how apps should be developed in a no compromise fashion. Unless you have some existing preference for different development languages or eco-systems, the best choice for single mobile platform scenarios is usually to use the vendor's tool set.

However, for the vast majority of us that just isn't reality. Even within enterprises, the rise of bring your own device has created a situation where needing to develop for multiple platforms is extremely likely. With this in mind I've been increasingly trying to work out a more formulaic approach to thinking about and choosing the right mobile development platform for different situations. The approach I've come up with is STANCE.

STANCE is a system that looks at several pertinent factors in the requirements for a mobile application and then forces you to rank those factors. With this ranking, different development platforms are given a rating on the STANCE factors. With this in mind, you have the ability to measure how different mobile development platforms rate on the stance factors, and you should pay particular attention to the factors you rank the highest.

First let's take a look at those factors and what they mean:

Speed / performance - how important is it that your application perform CPU intensive tasks, rendering, external applications calls with the best performance possible? Do you really have a CPU intensive application that will push the bounds of the mobile platform or do you just need good enough?

Time to complete / Cost - Is the time and cost a significant factor? I would not underestimate or under-rank this metric.

Always working with the newest standards / APIs - Will your application always be using the latest technologies of the mobile platforms. For example, will you start using 3D Touch or the newest design standards shortly after they are released or will those types of changes not be a significant factor in your application until sometime after they are released?

Native user experience - How sensitive are your users to having a true native experience in your application? Will your users be put off if your Android application isn't using Material design or will they be OK if it's close enough or potentially even uses web design standards?

Complex hardware / platform API interactions - Will your application need different or very specific interactions with the device's hardware or APIs? For example, does your application need to have a check scanning algorithm utilizing the camera, direct access to Health Kit or precise control over the format and bit rate audio and video are being recorded at?

Enterprise Services and Tools - Are there some particular enterprise services or tool sets that have already been decided on or your organization has decided should be used. If the development technology doesn't work with one of these, will it mean that your app is a non starter for meeting corporate standards or communicating with corporate services?

Each of these factors should be rated against the others. This is done instead of a straight ordering to get a relative weight on each of the factors; just how more important is one compared to the others? To do the ranking you can use a chart like the following:

To use this chart look at each of the green cells and ask yourself which is more important, the one on the Y axis or the item on the X axis. For example, the first cell compares T(ime/cost) to S(peed/performance). If cost of the application is more important to the application draw a symbol pointing to the T, otherwise one pointing to the S. It may even be useful to have several different stakeholders fill this out to make sure there is agreement on what the priorities and requirements of the solution are. A filled out chart may look like the following:

To use this simply assign one point to each metric where it has been selected as the more important. In the above example we find the following rankings:

S - 2
T - 5
A - 2
N - 2
C - 1
E - 3

(Note: The total of all the ranking should always be 15)

In the above example, far and away the most important factor of making this application would seem to be keeping the cost low. It is more important to anything else; scoring a full five points. It would also appear that integrating with some enterprise services and tools is also reasonably important while complex hardware interactions do not appear to be particularly important to this application at all.

With this understanding we can now look at how they compare to some of the development platforms that are available. I have scored some of the ones we use at Magenic, but with a little research you could score other mobile development platforms as well (I have scored on a scale of 1-8 with the higher number being that the platform is better at delivering that metric).

Cordova:

The Cordova platform has many compromises but it also has one particular area where it shines. If you can work within the bounds of its plugins, don't have complex hardware interactions, are not overly concerned with it fully looking native and performance isn't a huge issue then Cordova will create cross platform applications faster and cheaper than any other mobile development technology on this list.

Xamarin Platform:

The Xamarin Platform has very few compromises. The largest compromise it does have is in Time / cost. It certainly does better than the native technologies but in our experience only 40-60% of code is shared, depending on the business logic of the application. The user interface is written once on each platform and mobile applications then to have a lot of user interface code and potentially platform specific API calls.

Some of you may notice that the Xamarin Platform didn't get a full score for always working with the newest standards / APIs. This would seem to be somewhat at odds with their day one support of new APIs that Xamarin is known for. The reason why I didn't score them fully here is that occasionally a change to an ecosystem is so fundamental that it takes Xamarin a while to implement. An example of this is when iOS started supporting 64 bit applications. It took the Xamarin Platform quite a while to re-architect for this change, only releasing a stable version within a month of when Apple stopped accepting new apps to the store that were not on the 64 bit standard. You can be reasonably confident that Xamarin will fulfill your needs for always working with the newest standards / APIs and also should be prepared for the off chance of a fundamental change happening where day one support does not appear.

Xamarin.Forms:

Xamarin.Forms is much more of a compromise than the Xamarin Platform. There is a slight Speed / performance penalty, it isn't as good as always using the latest standards / APIs (for example, it didn't implement elements of Android Material design for quite some time after it was released), there is not as much flexibility in the design and complex hardware interactions require writing platform specific code. But those penalties compared to the Xamarin Platform are offset by a better Time / Cost score. If your app can work with the limitations of forms then you can write cross platform applications at a cost advantage over the Xamarin Platform. The cost advantage isn't quite as good as it is for Cordova, but then again the other trade offs are not quite so severe.

Native:

When it comes to using the platform's native development technology  and creating cross platform applications there is one primary trade off that is being made, it is usually the most expensive way to do it. You will have to create and maintain two or more completely separate code bases. But in every other way the native development platform gets full marks. Even in Enterprise Services and Tools that all tend to tread the native development technologies as first class citizens, which is usually not the case with other mobile application development technologies. It is for this reason why when there is only one platform I usually starting thinking about native.

Now you might notice even though I scored the rankings of the factors that are required for the application I don't then take it the next step and formulaicly compare it to the ratings of the development platforms. I don't do this because it usually isn't a formulaic answer. For example, if you find it critical that your app work with some enterprise service or tool, then really what is required is some research to find out which mobile development platforms work with your selected enterprise services and that's what will matter.

In many cases there are usually other more subjective factors that come into play or ones that are very context sensitive. For example, if your entire development team is familiar with .Net, in which technology would they be more likely to create well architected, stable and maintainable applications? Another factor that may complicate these ratings are the design of the UI itself. I have seen many digital agencies create mobile application designs that are more akin to websites than native mobile applications. In such cases HTML based technologies such as Cordova really start becoming more attractive.

The STANCE metrics do not lead you to the absolute, in all circumstance,s correct mobile development platform based on your needs. There are just too many situational and subjective factors involved to make a completely formulaic approach. Instead, it gives you a tool to start thinking about what factors are more and less relevant to your mobile efforts and from that what tools are more and less likely to fulfill those needs. STANCE won't, in and of itself, clearly identify the one and only mobile development platform for your problem, but it will help you mitigate risk so you are more likely to choose the one that best fits your needs.