Share

As we’ve built out Ionic, we’ve gotten a ton of questions about Cordova and PhoneGap. These range from confusion with the naming (are Cordova and PhoneGap the same thing?), to a misunderstanding of the goals and capabilities of these projects.

A quick history lesson

PhoneGap proper was created around 2009 by a startup called Nitobi as an open source way to access the “native” environment through an embedded Web View in a native app. The goal of the project was to make it possible to build the bulk of a mobile app experience with pure web technologies like HTML5, CSS, and Javascript, but still be able to call into native code when necessary.

In 2011 Adobe purchased Nitobi and with it the rights to the PhoneGap brand, and the open source core was donated to the Apache Software Foundation under the name Cordova.

A rose by any other name

So what is the difference between Cordova and PhoneGap? Adobe uses a helpful analogy: Cordova is to PhoneGap as Blink is to Chrome. PhoneGap is Cordova plus extra Adobe stuff.

At first, the differences between Cordova and PhoneGap were minimal. But Adobe always had plans to build out a proprietary set of services around the PhoneGap ecosystem, and has started to execute on that plan with PhoneGap Build.

So, when you start a new hybrid app project, you can either decide to use Cordova proper, or enter into Adobe’s ecosystem and use the PhoneGap distribution of Cordova.

Note: Ionic uses Cordova proper at the core, we do not use PhoneGap at all (though it can be used just fine).

You don’t know what I’m capable of!

At its core, Cordova offers a simple but powerful API to call Javascript functions that map to native code or plugins. This means you can transfer any kind of data from native land into web land.

This is something people don’t always realize. Cordova is capable of pretty much anything you need to do on mobile. It’s a powerful low-level API that comes with a set of pre-made, simple plugins to do things like access the camera or compass.

So when someone says that Cordova can’t do the same things other native apps can do, they are wrong. The only limitation is what plugins are currently available, and your ability or interest in building custom ones for your app.

Part technology, part dream

So if Cordova can do anything native apps can do, why doesn’t it seem like it? For that, we have to look at the vision of the project.

Adobe has always said that the big goal of Cordova is to make itself obsolete. Basically, that Cordova’s feature APIs would eventually be implemented by browser vendors, making the project less necessary.

Take, for example, the Geolocation API. While GPS on mobile was made popular with the iPhone, mobile browsers didn’t support it well until later. So, Cordova had a bridge for that, through a navigator.geolocation Javascript API that they expected to become the standard in the future. Cordova uses the native browser implementation when available, or uses the bridge when it’s not.

The same thing can be seen today with the navigator.camera API. This is a very simple API for getting a picture from a device’s camera. You might imagine browsers offering this as a standard in the future.

So, the vision for the core plugins of Cordova is to offer simple functionality that would fit into the API of the browsers of the future, one day making the Cordova implementation obsolete!

One size fits all?

I personally disagree with that vision. While I think we should be working toward a better, more standard browser API, we should also be enabling the creation of really custom and creative hybrid apps. To do that, we need more generic native-to-browser plugins and APIs in Cordova.

This is the difference between the existing navigator.camera.getPicture() API and a theoretical navigator.camera.getPhotos(start, count, size). The first only lets you grab one photo through a hard-coded UI you have no control over, and the latter leaves it up to you to build the experience, merely streaming the data from the native layer to your Javascript.

Luckily, Cordova has a high quality plugin API, we just need more great plugins that expose data from the native layer, not just hard coded features or UIs. While the default plugins are very simple and easy to use, they don’t scale well when you want to build something really custom (like the Instagram app).

This is one of the big goals of Ionic: to provide a broader set of more generic Cordova plugins to enable the creation of more complex and custom apps. It won’t be easy, but we’ve already started on this quest and will be releasing a lot of interesting demos in the coming months really showing the capabilities of Cordova.

Readers Digest

Let’s recap:

Cordova is the community powered version of PhoneGap, which is Adobe’s productized version and ecosystem on top of Cordova. Ionic uses Cordova not PhoneGap for our core tools.

Cordova is both a low-level native app to browser API, and a set of default plugins that provide simple features to your Cordova apps in the spirit of simple browser APIs.

Cordova can do pretty much anything a native app can do, it just needs the right plugins that send the right data to your web code. We need more developers building these generic plugins, and we will continue to see more of them over time.

Oh, and Cordova is awesome and we love it here at Ionic!

Signup for the Ionic Newsletter to get the latest news and updates!

J T

Iam also looking to starting my app build on phonegap but was sceptical about the differences it poss as against the native in terms of performance and user interface.
Since its an Adobe project, i fear too it will become obselete much like the out going adobe suite.

http://www.mobilepundits.com/ Aabharan

I did a fair amount of experimentation with phone gap/Cordova a couple of years ago. What really killed me wasn’t so much perf as places where i want or need native UI.

Andreas

I am looking for a developer who already uses ionic and he is intrested on experimenting on an excisting application which was developed only for android. The app is about weather and uses a pro weather api for the data shown plus other stuff that already exists or I would like to add. The point is that the budget is low! So, take this as your chance to earn some money (we can discuss this in private) and gain new experiences that this app developement will bring to your knowledge, plus that your name will be mention as the core developer of the app, at least in use with the the platforms of iOs and windows 8. That means that you will be able to use the app name also as a reference for your work! Just add me on skype and we can discuss about it. My skype name is mobilo.2013 and I am living in Athens Greece (gmt +2 )

http://kout.com/#/arkanciscan Jesse

I’ve built a couple of Hybrid apps, and while I certainly understand the desire for better-than-web-standard apis, the apps I’ve built also function as standard web apps because I avoid using Cordova plugins that define APIs that aren’t available in the browser. I’ve got absolutely no interest in debugging Obj-C or Java, which tends to be necessary when you use a lot of plugins. To me, Cordova is nothing but a shiv that gives Javascript access to features that native WebViews don’t yet supply.

Lexx YungCarter

Couldn’t agree more!

Vijay Naidu

Excellent Article. You saved me a lot more time. I guess same for many of them to searching and find things. So, worth to spend a minute to leave comment 🙂 Thanks Max

David Land

Really helpful, thanks you! This kind of historical context is always so hard to find in this industry so it’s really nice to have it all summarized so well in one place.