Software Engineering

Cordova, React-Native, Swift: What is really next?

January 03, 2019

I’m quite excited about writing about mobile application development. It has been in my mind for quite some time now. Before going into discussing my experience on these technologies I want to give a brief about my background.

I’m a Software Architect and a Full Stack Developer who was working with JavaScript for the past 6 years. Since the old days of JavaScript with ES5, the language has grown a lot. It’s quite obvious. But it’s important to remember our past to understand our future.

So, let’s dive into the technologies!


I don’t think it’s fair for me to write about Cordova since I’m not an active developer for the past 4 years. Back in the days, a simple animation using CSS3 Keyframe animation was not working as intended in Android devices. Since they were using the default browser and not the Chromium it was intended to run in. Since those days, Cordova has evolved and started to ship itself with a smaller version of chromium inside itself.

Being able to run your website as a mobile application using Cordova was and still is a really interesting and fascinating feature for most of the web developers who just wanted to try the mobile application development.

Additionally, for a team who focuses not only on a specific technology but on JavaScript and it’s ecosystems, it’s really an interesting investment to write your own PoC using Ionic (Angular). But the very thing it makes Cordova strong does also make the technology weak compared to others. The web.

Cordova Architecture

Main Issues

  • Browser layer of the application and the communication between the native code through it.
  • WKWebView being the only browser support for iOS devices and the inconsistencies between browsers (Android vs iOS).

Due to constraints of the iOS platform, all browsers must be built on top of the WebKit rendering engine.

  • All communication must go through the HTML Rendering Engine (in iOS: WebView) and causes the performance of the application to have a strict correlation with the browser.

React Native

When React Native was first released it was quite a hype. The technology was unstable, but the promise it brings with it was quite fascinating!

Before continuing to my thoughts on React Native, let’s dive into the React Native ecosystem.

Up until October, Facebook was using its own fork of open-sourced React-Native. Since it came with extra pullbacks and effort, they switched to using the open sourced one. (You can see some issues where a Facebook developer doesn’t encounter a specific bug, even though the same functionality was used inside Facebook itself, but because of Facebook using its own fork.)

Facebook releases a new version every month, up until September (I guess). After that, they started to release every 2 months (as far as I observe).

React Native vs Swift: Performance Comparison

Even the performance comparison with native apps showed a lot of promise both in React-Native and in JavaScript. Even in 2017, we wrote a production ready app all in React-Native. It was going great. Everybody was happy. The code was shipped fast, and since most of our developers had a JavaScript background, we were delivering on time and shipping production quality apps.

Until the time I needed to write my own plugin to communicate with Swift side of the app through the JavaScript bridge, I was quite happy with it. Even, I suggested using it in my latest startup SchoolApply.

The breaking changes in React Native caused my native code to misbehave due to unknown changes made by react-native-git-upgrade module which React Native and Facebook suggests to update the core itself.

Main Issues

  • It’s main dependency React and inconsistencies between the React-Native core and React.
  • React still doesn’t follow the Semantic Versioning. From my perspective, software which is 4 years old, shouldn’t be in 0.5X.XX.
  • Inconsistencies with native modules due to the breaking changes that happen to React-Native core a lot. (This is one of the main reason that React-Native defends of it being in 0.5X version, but this is again the main reason to use Semantic Versioning: to keep track of breaking changes and to inform developers about the ecosystem and deprecation)


It’s quite unfair for me to judge a language by it’s cover since I’ve been writing it for the past month but let’s give it a shot.

I had a quite prejudice since I thought React-Native or Cordova was doing the same exact thing as Swift: A mobile application.

Every code written in Swift has a purpose. Yes, even the UITableView. It creates pain for new developers to get used to it and forces the user to use mainly XCode for development, even though there are solutions on the internet for using VSCode, Sublime or else.

The auto layout constraints are quite hard for a new developer. There are really great libraries such as SnapKit, Cartography exists which aims to solve this ambiguity, but still not the default way of doing it.

Even though all of the things above, the best experience I had as a developer is with Swift. There’s no JavaScript bridge, WebView to get yourself bound into. You can use any library you want, with unlimited access to the device itself.

Yagiz Nizipli

Written by Yagiz Nizipli a Software Architect living in Istanbul working on mobile applications. Look me up on Youtube and follow me on Twitter.