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:
Xamarin Platform:
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:
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.
