Your Cordova App is Probably Terrible

If you aren’t already in the process of switching your Javascript mobile app to Facebook’s React Native platform, you should be.

As a product manager at Huge and a full-stack developer active in the New York tech and startup scene, I’ve come across a wide array of apps that span every imaginable industry and use case.

Throughout my digital travels I’ve seen a large number of apps built with Apache’s Cordova engine, an open source project which allows developers to create cross-platform apps using HTML, CSS, and Javascript. One popular distribution of this technology is Adobe’s PhoneGap.

In my experience, these apps are uniformly fairly terrible.

Here’s a few reasons why:

Cordova apps have painfully slow and jittery animations

No matter how carefully you style your app, no matter how detail-oriented you are creating that native “feel,” there’s not a user out there who wouldn’t notice the stuttering when you open your app’s hamburger menu, or the jerking when you slide and scroll elements.

Cordova apps rely on the phone’s web engines to run your app — you’re pretty much just giving users a full-screen web browser. The same way your mobile website just doesn’t feel as as slick as it does on desktop is why your Cordova app just doesn’t feel as smooth as a native app.

CSS-based animations on iOS and Android will never feel as smooth as native animations, and neither Apple nor Google have any incentive to improve them significantly. Both companies want you using their development tools and technologies, so your Cordova app will always feel awkward.

Using something like the Ionic Framework may make your app look better, but apps have users, not viewers, and yours know your app feels like a hack.

Most Cordova apps are lackluster because their developers are constrained

I think a lot of Cordova apps are terrible mostly because the teams that create them are aware of the platform’s limitations and purposely try to avoid doing familiar native things like sliding animations and fun transitions because they know users will see the cracks. Having developed apps using Ionic myself, I can speak to this temptation.

For example, let’s say you wire up a nice sliding hamburger menu because you’ve seen it in some of your favorite apps and you think it would be the natural choice for your users. But once you code it, you realize the animation is smooth only about 20% of the time — usually the phone just chokes on the CSS. So, you start considering ways you could let users navigate without a hamburger menu so they won’t encounter any jerky transitions. Pretty soon, your app is defined by compromises, and you’re far from the delightful experience you had planned at the outset.

Building great products is difficult enough without tying your hands from the start by using a technology you’ll need to shoehorn into your use case. Just ask anyone who’s tried to launch a social network using Wordpress plugins.

Most Cordova apps are just their company’s website in an app wrapper

If this describes your app, please pull it from the market now.

This is one of the most fundamental problems I see with how most companies think about their product strategy. They look at at the myriad channels by which they can interact with costumers (e.g. web, iOS, Android, Facebook, Snapchat), and they say, “we just need to reproduce what our users can do on the website in our apps.” This completely misses the point of having mobile phones, and tablets, and email, and text messages. The strength of the variety of channels is that it lets you target your users in those channels by understanding what those channels are used for.

Apps are terrific for providing regular information and functionality you access frequently. Websites are great for one and done transactions you do less frequently. Text messages are well-suited for asynchronous, short communication.

Now let’s say you started forcing users to register for your service by having them respond to a series of text messages asking them for their name, their email address, their password, and so on. Or you built a neat countdown timer website that visitors could only access on desktop. See how awkward it is when you design a product then throw it in the wrong channel?

Now you know how your users feel when you spin up a Cordova app that features the same home screen as your website, has the same navigation structure, and even re-uses all the same content. And the fact that that’s so easy to do with Cordova, since it’s basically just a web page, means you’re more likely to make such poor product decisions.

But who really cares about frustrated users? After all, you’re using one shared codebase across web, mobile, iOS, Android, Kindle, and airport restaurant kiosk. Now, that’s something you can take to the bank.

Javascript apps are the future, just not built on Cordova

This is not where I convince you that if you want to be doing app development right, you should do it natively, hire separate iOS and Android teams, and kowtow to the powers-that-be at Google and Apple.

Quite the contrary, actually. There are very good reasons companies should build apps using web technologies:

Your users don’t all use one platform

If you want your product to be successful, you need the ability to put it in front of potential users, regardless of whether they use iOS or Android. A cross-platform approach to app development is just good business.

It’s prohibitively expensive for most companies to maintain platform-specific teams

The tech industry wouldn’t settle for a world in which you needed a separate team each with unique skills to make your website great on Chrome, FIrefox, Safari, and MIcrosoft Edge, so why is this tenable for apps? Backwards compatibility issues with Internet Explorer aside, websites generally play pretty nicely on all modern browsers, but iOS apps need to be written in Swift or Objective-C and Android apps in Java. This is unsustainable. It makes sense to want an approach that doesn’t put you out of business.

I’ve gotten pretty tired of iOS and Android “purists,” who scoff at any company trying to build apps with web technologies. They seem to imply there’s something morally wrong with finding fault in the resource model needed to create bespoke native apps. To me, this attitude is fine if you’re into development for the art of it, but if you just care about making great products, “proper” app development is ludicrous.

You’ve already got talented web developers who know HTML, CSS, and Javascript

Obviously it would be great if the crack team who built your website could contribute to app development as well, especially since they likely know a lot about how your product works and how your users interact with it. Teams that become siloed also create more bugs and inconsistencies across the product, since the right hand never knows what the left hand is doing. Great product strategy requires shared product vision and it’s natural to want a core team to work across channels.

React Native is already better than Cordova

Just a few things you get by building your Javascript apps in React Native:

A terrific development experience

Developing apps in React Native lets you use the Chrome developer tools to troubleshoot issues in the console, let’s you view hot code pushes in a phone simulator, and even lets you preserve app and navigation state after code changes in the latest release candidate. It’s already a faster and more pleasant experience than either Cordova or native development.

Fully native animations and transitions

You can create animations and transitions with React Native that actually utilize the phone’s core rendering engine, and the difference in look and feel is incredible. It’s so good in fact, that Facebook has said it’s using React Native components inside the core Facebook app. If you’re going to the trouble of building an app you want users to love, give it the best chance by making it feel awesome.

Easy transferability from React for web

If you’re using React components on your website, or thinking about implementing them soon, it’s very easy to translate them to React Native components. You can even create nearly identical container components for the web and your app that are responsible for data-fetching and then just build separate UIs. This is the Facebook approach, “Learn once, write everywhere.” It’s far more interesting to have a development approach that lets you build for many platforms easily than to have one giant shared codebase with more if blocks than should be allowed to exist.

You’ve got Facebook in your corner

Javascript may end up being the one UI language to rule them all, and it’s no surprise Facebook is betting heavily on it. It makes sense, after all — most developers know some Javascript and with the advent of Node.js, it runs on everything. It’s really hard to imagine a future in which Javascript isn’t the frontend (and maybe backend) language of choice on every platform, and if any company is ambitious enough to make that happen, it’s Facebook. Moreover, Cordova is built by Apache, and PhoneGap is distributed by Adobe. Do either Apache or Adobe strike you as companies you want powering your user experience?

Given that choice, I’ll throw in my chips with Facebook every time.

If you’re interested in learning how to build incredible apps in React Native, sign up at. www.buildreactnative.com to get early access to Build React Native, the definitive tutorial.

Nicholas Alan Brown is a senior product manager at Huge and co-founder of React Native NYC. Find him on Twitter (@nicholasalanb) or LinkedIn.