When it comes to developing a mobile application the first question one should be asking is “Which platform to support?”. These days the answer is obvious. iOS and Android heavily dominate the market with a combined share of more than 95% and growing.
Between iOS and Android market share is not equal: Android has twice as much active users as iOS and the gap is growing, as the 2016 smartphone sales indicate that for each Apple iOS device sold there are four new Androids. However, even though Android has advantage in users, it is still behind in dollars spent by users for a multiplicity of reasons.
Without going much into the details, the bottom line is: unless you are doing something very specific, you should develop for both iOS and Android. Other operating systems can be generally ignored until Android and iOS markets are conquered.
It is also a common practice to start with either iOS or Android and add the second platform later on. But either you do that or launch for both platforms simultaneously, there is a central question that needs to be answered: are you going to build fully native applications for both platforms or go with on of the cross-platform solution available.
Terms “platform” and “operating system” are often used interchangeably in the context of mobile. Technically these terms mean slightly different things, but as much as we concerned in this article we will disregard this difference and use them as synonyms.
From the technical point of view, fully native application means the application developed with native tools for the specific platform. iOS applications are built with Objective C or Swift programming languages (which actually are often mixed) and directly utilize iOS SDK. Android applications are normally built in Java and directly utilize Android SDK with some occasional mix in of NDK (Native Development Kit). Android applications can also be built in other languages that support ART (Android Runtime) like Scala or Kotlin, and still be considered “fully native”.
Cross-platform applications use a third party framework, which serves as an abstraction layer between the application code and the specific mobile platform. The goal of the abstraction layer is to allow reusing the application code on different platforms with none-to-minimal alterations. Most of the platform specific code stays inside the abstraction layer and is provided by the framework.
The only real reason to prefer cross-platform over the fully native is to reduce the cost of development and support. If this is not a decisive factor in your case you can stop reading right here and just go with a fully native application.
However, a cross-platform application is not necessarily worse than fully native. It all depends on the specific application. There are a few major things to consider.
In this article, we are speaking specifically about the “applications” as opposed to “games”. Games are so very special case, that cross-platform solution in most cases totally beats the fully native approach. We will write a separate article on this topic soon.
Cross-platform applications are cheaper to develop, but for how much exactly? In case of the native application for iOS and Android we basically need to build 2 application identical in scope, so we can say the cost of building them is 200% related to a single application. Would, thus, the cross-platform cost be 100%? From Factorial Complexity experience it never would. The realistic figure is somewhere in a range of 120-160%. The larger the application work - the more the gain is not only in the absolute but also in the relative figures. It also depends on the specific cross-platform solution used. More on this in the next article.
Why it is more than 100% if we go with WORA approach (write once - run anywhere)? For a multiplicity of reasons. In fact, we are still building 2 applications. They need to be tested and debugged on both platforms. Each of the platforms has a lot of hidden “gotchas”. Both iOS and Android are being developed rapidly, cross-platform frameworks are often unable to pick up the pace, as their developers do not have the resources nearly comparable to what both Apple and Google have at their disposal.
And then when one is building the cross-platform abstraction layer, it is essential to achieve a balance between the unification (and consequently speed and cost of the development) and maintaining the native look and feel of the application.
2. Native look and feel
If you are aware of the latest mobile design trends you know that these days the difference between iOS and Android applications is becoming less and less distinct. There are still certain ideological and architectural differences, that will probably never go away. But similarities prevail: both Flat and Material design styles share a lot of concepts and hardware features of comparable iOS and Android devices are mostly the same. Whenever something new is introduced, it is almost immediately copied by the competitors.
User interface of Instagram looks almost identical on iOS and Android. Instagram is built using React Native - the cross-platform application framework.
And yet the specific application may win a lot in usability and value for users if it makes a good use of the platform specific features. Cross-platform framework may become an obstacle. For example, HTML-based solutions, like Apache Cordova (formerly PhoneGap), tend to be really bad at making the applications look native.
3. Responsiveness and performance
Speaking of HTML-based solutions, some frameworks are not capable of delivering the lightning fast responsiveness of native iOS application by design. The developers of Ionic framework (solution based on Apache Cordova) are totally aware of that. That’s why Ionic landing page has no single mention of HTML or CSS (well, ok, they have an obscure HTML5 icon if you scroll down enough). In fact, it claims that you can build a “native” application.
The misuse of “native application” term became so common, that I had to invent the “fully native application” term for this article. When you hear someone saying “native app”, always clarify what exactly is implied. In many cases, it just means “the application that can be published to mobile store”. Well, any website can be wrapped into a container and published on the Google Play within hours. Can you call it a “native application” then? Only if you want to sell it badly.
On a bright side, React Native for example is pretty fast (regardless of the misleading name), because it uses the native views under the hood. It also has a good support for extending functionality with the platform specific truly native code (had to invent yet another term).
4. Extending the cross-platform framework
What if cross-platform just doesn’t support what your application needs? How easy would be to extend it? Depends on the application and the specific framework. You should consider this from the very beginning. There is a risk of ending up with increased development costs and development time even when compared with native.
5. Paralleling the development
Speaking of development time. It is not always the same as the development cost. Normally you can do iOS and Android native development in parallel and have both apps ready in say 10 weeks. While in order to complete the cross-platform application with the same workforce you will need 15. You will end up reducing cost by 150%, while effectively extending timeline to the same 150%.
I agree, real life is more complicated and this example is a bit far-fetched. But still the fact is: the development of two different applications can be paralleled much more effectively than the development of a single application.
6. Same behavior on the different platforms
Yes, you can have 2 different teams developing iOS and Android applications at the same time but will they end up with the same application? Finally, something that sounds like in favor of cross-platform. But do the users really care that Android and iOS applications have the same features? Probably not, as most of them will use either iOS or Android. And yet, you should remember that speed up in development time might require more management efforts. If you build 2 different applications - you might end up managing 2 different applications.
7. Finding the programmers
You may have the resources to set up a team of N developers, but how easy is it to find the required amount of experts in the specific cross-platform framework? How easily will you be able to extend the team or replace someone in few years? These questions do not have universal answers but still, you need to ask them if you plan for a long term.
As you can see cross-platform development can be really beneficial, but it also has a number of pitfalls. The decisive answer depends on a specific case (just like when you are choosing between the payment models or working with remote vs. in-house developers). And we at Factorial Complexity are always here to help you decide!