Does Cross-platform App Development Really Save Time & Money?

Does Cross-platform App Development Really Save Time & Money?

Can Cross-platform Save Time and MoneyThe year is 2007, a new CTO is hired at the company I shortly worked for. As many new arrivals, who want to rewrite everything without even looking at what is already there, Mr. CTO decided to throw away all the native Java code and write the whole application in Flex. After objecting to this very idea, I was told that I am opposing it because I do not want to learn a new language. I took the challenge happily, and in two weeks I launched my first Flex web app (1 week to learn Flex / Action Script 3, and another week to write the app). After proving myself, I once again warned the executive staff about the great danger in the path they want to take but to no avail, the spell of the new-hire was stronger than my words. Nine months into development with 5 full-time resources and about half a million dollar invested, they finally reached the conclusion that Flex is not best for the job.

Two years later Apple announced they will be pulling the plug on Flash on iOS, and that was the death sentence for Adobe Flex.

So WWW What Went Wrong?

The answer is simple, we do not ask the right questions before tying the knot with a framework or a platform. The decision should not be solely based on whether it is a new technology, or if it is backed by Google, Microsoft, Facebook or Adobe, or if is it going to save me time and money. Yes! many factors will weigh-in, but companies tend to forget the key question:

Is this the right platform for the job?

If the answer is ‘no’ and we go for it, we have just signed up for the Nightmare on Elm Street franchise. It does not matter who is backing the platform and how much those companies are promising a smooth ride, brace yourself for guaranteed turbulence.

Every time I hear someone saying at a company “We want to use cross-platform solution to cut on the cost and time.” I wonder if that person even knows what it takes to launch a successful product out the door.

App Development Frameworks for iOS & Android

There are more than a dozen cross platform frameworks that are currently popular and there are dozens more which did not make it to see the light today. In this article I am not listing pros and cons or comparison charts what I want is to shed light on the ‘unanticipated’ problems companies are facing with many of these mobile app frameworks.

1 – Cross Platform Hybrid Frameworks

A Hybrid Cross Platform is a non-native development framework which uses WebView to render UI components. This is why they are called ‘Hybrid’, the UI is  most commonly implemented in HTML, CSS and Javascript.

10 Hybrid App Development Frameworks in 2018

Here is a list of some of the most popular hybrid mobile app frameworks in alphabetical order and with links to their websites:

Framework Environment Cost
Apache Cordova Cordova is an open-source hybrid framework which is also the base for several other projects. Free/Open source
Adobe PhoneGap This framework, built on top of Cordova, was quite popular once, but stats show a downfall of this platform. Non-free
Appcelerator Titanium Titanium has mixed development environments provided by Xamarin and PhoneGap. Non-free
Framework 7 Hybrid mobile apps or web apps with iOS & Android with native look and feel. Free/Open Source
Ionic This framework is built on top of Angular.js and Cordova and uses Web technologies like CSS, HTML5, and Sass. Free/Open Source + Paid Pro Service
jQuery Mobile Another oldie, but not a goldie. Slogan: “Write less, do more”. Failing big time because of its sluggishness and bugginess. Free/Open Source
Kendo UI HTML5/Javascript UI framework for jQuery fans, with added support for Angular, React & Vue. Non-free
Mobile Angular UI This is a hybrid mobile framework for the fans of Bootstrap and Angular. Free/Open Source
Onsen UI Onsen also promises native look and feel with lots of ready-to-use components and automatic styling, and has support for AngularJS, Angular 2, React & Vue. Free/Open Source
Sencha Ext JS This framework is used to build data-intensive, cross-platform web applications. Ext JS leverages HTML5 features on modern browsers. Non-free

Some already dead or on their deathbeds are: Adobe Air, Intel XDX, RoboVM, JavaFX, J2ME, Sencha Touch

Personally, I do not consider these WebView based frameworks worth exploring, the only use I can think of them would be to create a prototype or a proof of concept which I will throw away after use. I will explain why I feel this way when I talk about the common problems these frameworks present.

2 – Cross Platform Native Frameworks

A Native Cross Platform development framework does not use WebView, it talks directly to the mobile OS while it may or may not use HTML/Javascript as the programming language. Following is the list of a few native cross platform app development frameworks (the most recent ones first):


This would have been a great solution if Google would have been a little smarter about it. There is one big flaw in this framework:

Say what? Dart?

Yes Dart language not Darth Vader. Maybe I am just immune to the person selling me an old Honda as if it was a Porsche, but there are many who will buy it just because it’s Google or Facebook the one selling. According to the Flutter page:

For developers, Flutter lowers the bar to entry for building mobile apps…

I’m curious, if on top of learning mobile dev I have to learn a new language which no one heard of before, how can this lower the bar to entry for mobile dev? Not only the developers have to add one more language to their resume, but also the companies will have to invest in yet another developer.

React Native

While many JS evangelists are convinced that React-Native is the framework of the future, I think it is built on a weak foundation, starting by the choice of their custom Javascript, and hence already falling short on its promises. Read the rest of the post and you will see why companies like Airbnb decide to drop React Native.


Microsoft backed, non-free, C# based framework to write native Android, iOS, and Windows apps with native user interfaces.

The framework is known for its complex setup, operational overhead, incompatibility with OS updates, and being very expensive. Unfortunately, Microsoft never understood ‘mobile’, hence they decided to purchase Xamarin in 2016. While the platform is shrinking, the only thing keeping it alive are the developers of closely tied C# / .NET ecosystem.

Codename One

Talk about the “walking-dead”. I was really surprised that this project, which is also one of the oldest framework, is still alive and kicking. Wow!

This framework is inspired by two very successful UI Frameworks from the mid 2000s, Swing & LWUIT, but with a far larger and more ambitious scope. You can learn more about the framework here.

For a bit more detailed comparison between Flutter and React Native I found this article interesting.

3 – Fully Native Platforms

Fully Native approach uses respectively Google and Apple’s original platform tools to develop mobile applications. Since each has its own development environment and set of languages you will end up maintaining two separate set of codebases.

While Fully Native mobile development may have some little annoyances here and there,  you know that you are getting the full package giving you full control over what the platform has to offer. It is also the least risky path.

Android – Java or Kotlin

Android is a Linux based OS and its official coding language is Java. Recently, Google has added Kotlin to the official stack. You can use either language to code and there are several IDEs that let you develop Android apps natively. At this point Google has not announced to drop either language.

iOS – Swift or Objective-C

iOS is BSD/macOS based OS with official coding language now being Swift. Apple has announced that it will eventually drop support for Objective-C hence all current and future development must be done in Swift.

False Claims of Happily Ever After

Let’s analyze the two bogus claims which are made by all these cross platform mobile frameworks:

Claim #1: Write once run everywhereCross Platform Development Problems

Every developer’s dream come true! Wouldn’t it be wonderful if this actually worked?

While “write once run everywhere” is definitely a very noble concept, it is not the first time it has been introduced. As long as we have had OS wars we have had frameworks popping left and right. But if it did work for Desktop OSs with frameworks such as Java, QT, FLTK, etc, why would it not work for mobile? Well, these frameworks were either written in C/C++ which was actually native to the OS, or in case of Java, the framework was so rich that you rarely had to go down to the C/C++ level. When it comes to Mobile OSs however, these cross platform solutions are not really using the OS’s native language. Hence, what ends up happening is that the codebase becomes a mix of native and framework code which produces two or three sets of codebase which need to be maintained anyway.

An ugly side effect is that the Javascript cheetah you hired to write cross-platform code, now ends up writing Java or Swift code as well which he does not have much expertise in. (I wish DMV also issued coding permits, so no developer can write production code without behind-the-wheel test.)

Claim #2: Cut Development Cost & Time

So now we look at the above scenario where you still have to mix cross platform code with Java or Swift code. You end up not only maintaining two separate codebases but actually maintaining:

Javascript + Java + Swift + Android workarounds + iOS workarounds

Try reaching those milestones, while that poor developer who is jack of cross-platforms and master of none, juggles the above!

The fact is that companies are spending a lot more time and money on these workarounds and maintenance than what they expected upfront.

Common Problems with Cross Platform

Cross-platform Development HeadachesPerformance

Fast and natural execution of the app is most important from a user’s perspective. It is one of the biggest factor to consider when implementing an app. Performance will be always an issue with Hybrid apps while the fastest execution will come from true native apps. You want to target 60fps and above frame rate for animations and interaction to look good and natural, otherwise the user will quickly move on to a smoother, faster competitor app.

App Size

Desktop developers may have forgotten how important the compiled size was and be able to get away with it, but for Mobile apps size still does matter. Not only it matters for fast load and execution time, but also for less memory usage. And do not forget the app download factor on slow networks, if the application is too large it would be a turn off for many to install. All the current cross-platform solutions will generate significantly larger app size compared to the truly native ones. A simple “hello, world” app might take anywhere from 6 MB up to 16 MB or more depending on the framework used.

API Changes

This is an important factor to keep in mind specially when talking about companies like Google who are known to throw beta frameworks out in the market for years and meanwhile keep changing their APIs drastically while many developers have already adopted them. If someone remembers working with GWT (a Google Web Toolkit) where basically every dot release came with a whole bunch of porting instruction while the old code used to become uncompilable.

I have already pointed out both Flutter & React Native are v0.2.8 & 0.55 respectively.

Feature Set Lag

Here is where most of the workarounds come in. These frameworks are consistently lagging behind in feature set from the actual native platform. So lets say Android comes up with a new UI component and an API feature, now it will take the framework some time to support this feature in their next release or the release after next. If the developers need to use this new feature they will end up putting some native code or a temporary workaround. Keep in mind that this is not the Desktop OS where new versions are released on average 2 year apart. Mobile OSs are commonly released 6 months to 1 year apart. A lot of catching up to do there…

The Javascript Factor

Javascript is a horrible choice of a language when coding more than three files. With no true OOP, static typing, no standard library, it is already a nightmare to work with and maintain. Forget it if you have to do debugging or profiling, or even refactoring! On top of that it is an interpreted language which will always run slower compared to a compiled language.

Non-standard Languages

Despite of being a horrible choice for development, Javascript is known to the world and if you ever open a manhole cover, you will still see a dozen Javascript developers crawling out running into the shadows. But when you say ‘Dart’ or ‘Go’ language, apart from a small community you will not find that many developers with this skill. Now I never hesitate exploring new tech, but is there a real need to choose and use such an unpopular language over many powerful new languages like Swift?

Complex Setup

Initial install and setup of most of these frameworks is neither simple nor smooth. Several of them require a bunch of command line interfaces and manual configurations. Do not think it will be as easy as launching Xcode or IntelliJ and click on ‘New Project’.

Lack of Documentation

If I managed to make it this far hurdling over all the above obstacles and I am finally ready to make my first app in one of these frameworks, I will needs three things:

a) Good documentation

b) Useful Tutorials or Examples

c) A big community of active developers.

Here you will find mix results some with a great active community and fantastic documentation while others not so much. But wait, who is keeping this documentation up to date? You will find most becoming sloppy at documenting as the framework becomes popular whether cross-platform or truly native.


Ask around in your circle of companies who went the hybrid route and they are already a year or two into maintenance phase, how do they like it now? Are they really happy with their choice? Did they save that development time and cost which was promised to them? I have yet to meet a single company which decided to go non-native and are happy with it.

Second Important Question:

Have I hired the right person/company for the job? (A topic for future post)

Two Bonus Questions:

  • If these cross-platforms solutions were as perfect as they claim, why every few months there is a new framework popping up saying what was done before was all wrong and we do it the right way?
  • If these cross-platforms solutions are really going to cut down development cost and save time, why are all their consumers constantly struggling and ending up spending more on maintenance?

Feel free to give an answer below in the comments.


In my humble opinion, it is too risky to choose any of the cross-platform frameworks available today in the market whether native or web based. It is a risk which big corporations can take, because they can just start all over again after hitting a wall but for startups and small business I strongly recommend to go fully native, even if it might seem like a costly option. In the long run you will be saving and might decide to even buy me a coffee.

To be honest, I would love to find a Native Cross Platform Framework that can be as good of a solution for the Mobile world as Java was a cross-platform solution for the Desktop. Every time a new platform is announced I rush to check it out with great hope. Do you think I enjoy developing for two platforms? Negative. But at the same time I am not ready to settle for something too risky and immature.

That said! At the end of the day we are a product team for hire. Our job is to advise our clients what is the best solution available for their product, if they take our advice we will work with them and if they decide to go otherwise we will still work with them and provide the best service possible to make their product successful. If you want quality app development, please contact us.

Word of Wisdom

Your app is your asset, do not be cheap with it or it will be cheap back to you.

%d bloggers like this: