The Cordova Plugin Ecosystem Is a Mess — This Is What We’re Doing About It

A good plugin ecosystem can make or break a platform. Many of the great development successes of the last decade have been built on top of a vibrant plugin community. Node has npm; Ruby has gems; and jQuery has 574 ways to build a carousel.

Unfortunately, that same plugin proliferation has not happened in the Cordova world. Don’t believe me? At the time of this writing, the official Cordova plugins registry lists a mere 262 plugins, 225 of which have less than 1,000 downloads. And it’s worse than just that. The vast majority of 262 plugins have minimal documentation, if any at all. If you’re a Cordova developer, there is no good way of determining if the plugin works at all, and if it does, on what platforms.

Why is it this bad?

In many ways, the Cordova plugin ecosystem is similar to jQuery’s, which has been wildly successful. In each system, developers use plugins to abstract away multiple platforms. In the case of jQuery those platforms are browsers, and in the case of Cordova those platforms are mobile operating systems.

But there’s one crucial difference between jQuery plugins and Cordova plugins, namely, the barrier to entry. For instance the following is a complete jQuery plugin:

$.fn.red = function() {
    return this.css( "color", "red" );
};

This may not be a particularly useful plugin, but it is functional. I can drop this code in my application and use it immediately. The correspondingly simple Cordova plugin is actually very difficult to write. In addition to learning the nuances of how Cordova plugins work, you also have to know how to code on native mobile platforms, at least enough to call methods in the native SDKs.

The entire Cordova plugin development model is a chicken and egg scenario. In order to write code that abstracts you from multiple platforms, you must first write the native code on each of those platforms. A good Cordova plugin runs on each platform Cordova supports, but to write that plugin you must be adept at development for iOS, Android, Windows Phone, and more.

And then there’s maintenance…

Assuming you go through the trouble of implementing a plugin, you’re just getting started, as running on multiple mobile platforms places a huge maintenance burden on Cordova plugin developers. In the jQuery world, browsers change fast, but that rate of change pales in comparison to the crazy world that is cross-platform mobile development, which changes faster than Facebook buys startups. Heck, iOS 8 introduced a new language, not to mention 4,000 new APIs — and that’s one platform.

Why does it matter?

The main reason people choose to build hybrid apps is that they want to leverage their web skills to reach multiple mobile platforms. PhoneGap’s tagline is “Easily create apps using the web technologies you know and love: HTML, CSS, and JavaScript.” But despite being largely web based, a hybrid app still needs access to native code. If you’re using only web technologies, you’re better off building a website.

To summarize, hybrid app developers need to access native APIs, but hybrid developers don’t want to touch native APIs. This is where Cordova plugins are supposed to come in, but the lack of a robust Cordova plugin ecosystem means that hybrid developers have to dig into native code — the very thing they’re trying to avoid.

Why all is not doom and gloom

Although the Cordova plugin ecosystem is a mess, the Cordova library itself happens to be a robust and well written framework. The problem is not the Cordova plugin mechanism, but rather the sheer difficulty of writing cross-platform code.

The core set of Cordova plugins proves that the Cordova system works. For example, the following code is all you need to build a new Cordova project and add the camera plugin:

$ cordova create hello-world
$ cd hello-world
$ cordova plugin add org.apache.cordova.camera

From there you can call navigator.camera.getPicture() to interact with your device’s native camera API. That’s it. And all of the core Cordova plugins are similarly easy to use, actively maintained, and thoroughly documented. The only problem with the core Cordova plugins is that there are only ~15 of them. And there are almost no third-party plugins that you can rely on in production code.

What we’re doing about it

At Telerik we believe Cordova is a spectacular framework for writing mobile apps, and we want to use our expertise in the cross-platform mobile world to help out; therefore, we recently released a Verified Plugins Marketplace. Basically, we created a set of free-to-use plugins that are guaranteed to work, to be maintained, and to be documented.

For instance, the following code creates a new Cordova project using the verified SocialSharing plugin, which lets you use the native share menu on iOS, Android, and Windows Phone devices:

$ cordova create social
$ cd social
$ cordova plugin add https://github.com/Telerik-Verified-Plugins/SocialSharing.git

With the plugin in place, you can use the plugin’s share() API:

document.addEventListener( "deviceready", function() {
    window.plugins.socialsharing.share( "message", "subject" );
});

Next, use the Cordova platform add and emulate commands to see the results on an emulator:

$ cordova platform add ios
$ cordova emulate ios

The result looks something like this:

cordova-ios-sharing

The ease of use is a testament to the Cordova development model. iOS has a native API for invoking the share menu above, but that’s completely transparent to you as a developer; you just call share(). It’s everything a plugin should be.

But it gets way cooler. Because this app is running in an emulator, there aren’t many sharing options (the emulator doesn’t have social networks, SMS, and so forth configured). To see the more robust sharing options, and to run them on multiple platforms, let’s switch to Telerik AppBuilder, as it makes testing plugins on real devices easy.

Adding a Plugin to AppBuilder

If you haven’t heard of AppBuilder before, I like to explain it as a set of power tools built on top of Cordova. The AppBuilder CLI works a lot like the Cordova CLI. For instance, the following example creates a new project and adds the same SocialShare plugin:

$ appbuilder create social
$ cd social
$ appbuilder plugin fetch https://github.com/Telerik-Verified-Plugins/SocialSharing.git

From there, use the deploy command to build and deploy this app to USB-connected iOS and Android devices.

$ appbuilder deploy ios
$ appbuilder deploy android

For Windows Phone deployments, AppBuilder currently does not support appbuilder deploy wp8, but you can run appbuilder build wp8, which displays a QR code that you can scan from your Windows Phone device to install the app.

Now that the app is on your devices, you can add the same call to window.plugins.socialsharing.share() to see how it behaves across platforms.

document.addEventListener( "deviceready", function() {
    window.plugins.socialsharing.share( "message", "subject" );
});

Here’s how the share menu displays on my (left to right) Android, iOS, and Windows Phone devices:

appbuilder-share

This example again showcases the power of Cordova — one line of code to invoke native APIs on three platforms. The Social Share plugin has a number of additional methods that you can experiment with. For instance, here’s a call to the shareViaTwitter() method:

document.addEventListener( "deviceready", function() {
    window.plugins.socialsharing.shareViaTwitter( "AppBuilder rocks!" );
});

To experiment with these method calls, you can run can use appbuilder livesync to push changes to your devices without rebuilding. For details see our guide to Bringing F5 (or Command+R) to Hybrid Mobile Apps.

The shareViaTwitter() methods looks like this on my Android and iOS devices:

appbuilder-twitter-share

To show one more method, here’s a call to shareViaEmail():

document.addEventListener( "deviceready", function() {
    window.plugins.socialsharing.shareViaEmail(
        "Message",
        "Subject"
        [ "to@person.com" ],
        [ "cc@person.com" ]
    );
});

And here’s how that call displays on my devices. (Note that Android and Windows Phone both ask me to pick an app to use, whereas iOS takes me straight to an email, as there are no other options.)

appbuilder-email-share

Wrapping Up

The SocialShare plugin examples show just how well the Cordova plugin model works. You can interact with native APIs on multiple platforms with simple JavaScript method calls. The Cordova plugin ecosystem may be a mess — because of the development and maintenance burden of creating plugins — but the Cordova framework is an increasingly powerful way of building mobile apps.

At Telerik we’re committed to help developers build Cordova apps, and our marketplace of verified plugins is another step in this direction. We want to provide you plugins that just work, which has never been a given for third-party Cordova plugins. If you do Cordova development I encourage you to peruse the marketplace and see what’s available. Want more? You can even suggest plugins you’d like to see added to the marketplace.

Comments