Why React-Native: Part Three
Part three takes a look at the rise and fall of hybrid promises.
20th May 2018
Why React-Native: Part Three
The Rise and Fall of Hybrid Promises.
It’s difficult to pinpoint exact usage numbers since most graphs are based on shipped units and not sold or used units, but sometime in around 2010 to 2011 it was clear that Android was here to stay. The years of only being able to write apps for iOS was in the past and the question of whether or not we could use a single code base to run on both iOS and Android came to the forefront. This was due, in no small part, to the fact that it was an absolute nightmare to develop for Android. There were no standards, every company had different screen sizes, features, chips, etc. And, on top of all that, there was no clear path to upgrade since it was left up to the carriers. On the other hand, Apple had one form factor and over 90% of users upgraded their OS within a few weeks of updates being released. But Android was cheap and there were still plenty of people that hated Apple which helped Android gain a solid foothold.
As an app developer, it seemed that every new client wanted to talk about the latest hybrid solution being pushed by a plethora of third party, one-solution-fits-all, companies. There were dozens that were evaluated and dismissed. Let’s take a closer look at two of them: PhoneGap and Xamarin.
The PhoneGap approach was straightforward. Your app will be writing in Javascipt, css, and html and run inside a web browser encapsulated inside a native app. This meant you didn’t need to hire expensive mobile developers since your web developers were able to write this code. There was also the promise of making it look “native like” and knowing that you could even use web hooks to use some of the native features on the phone. In the end, this solution was really only good for a very limited type of app (content delivery for example) and anything with a custom user interface required way more work to be performant than promised…and it never felt native.
Xamarin took a completely different approach. They felt it was the two different languages that presented the biggest problem, not the two different code bases. Xamarin uses C# as the core language and uses .net as the underlying framework. This made it easy for Microsoft shops to get into mobile development. The downside, if you didn’t already know C# and .net, is that it wasn’t any easier to learn than pure native languages. Xamarin also depends on a one-to-one mapping to the underlying native APIs, which change every year. They do a good job of keeping these in sync, but there is now another layer of issues that can arise. In addition, you still had to write your interface logic for each platform. So, while you used the same language and could share some code, you still were creating two separate code bases in the end.
Neither of these solutions really made mobile development better, but rather shifted the problems to different places. You could sacrifice performance with PhoneGap or shift the language dependency with Xamarin, but in the end neither obtained widespread adoption and both have faded out of the spotlight (although they still do exist).
Apple and Google’s solution to this was not to merge their platforms of course, but to introduce or adopt, new, easier to learn languages which we’ll take a closer look at in part four.