Overview

Cordova is an open-source mobile development framework. It allows you to use standard web technologies such as HTML5, CSS3, and JavaScript for cross-platform development, avoiding each mobile platforms' native development language. Applications execute within wrappers targeted to each platform, and rely on standards-compliant API bindings to access each device's sensors, data, and network status.

Use Cordova if you are:

  • a mobile developer and want to extend an application across more than one platform, without having to re-implement it with each platform's language and tool set.

  • a web developer and want to deploy a web app that's packaged for distribution in various app store portals.

  • a mobile developer interested in mixing native application components with a WebView (browser window) that can access device-level APIs, or if you want to develop a plugin interface between native and WebView components.

Basic Components

Cordova applications rely on a common config.xml file that provides information about the app and specifies parameters affecting how it works, such as whether it responds to orientation shifts. This file adheres to the W3C's Packaged Web App, or widget, specification.

The application itself is implemented as a web page, named index.html by default, that references whatever CSS, JavaScript, images, media files, or other resources are necessary for it to run. The app executes as a WebView within the native application wrapper, which you distribute to app stores. For the web app to interact with various device features the way native apps do, it must also reference a cordova.js file, which provides API bindings.

The Cordova-enabled WebView may provide the application with its entire user interface. It can also be a component within a larger, hybrid application that mixes the WebView with native application components. Cordova provides a plugin interface for these components to communicate with each other.

Development Paths

As of version 3.0, you can use two basic workflows to create a mobile application. While you can accomplish the same thing using both workflows, certain tasks are better suited to using one workflow over the other. For this reason, you should understand both workflows so that you can use the best tool for the best situation.

The two main workflows that are supported are the Web Project Dev workflow and the Native Platform Dev workflow.

Web Project Dev

You can think of the first workflow as the Web Project Dev workflow. You should use this workflow when you want to create a Cordova application that runs on as many mobile operating systems as possible with as little platform-specific development work as possible. This workflow came into existence with Cordova 3.0 and the creation of the Cordova Command-line Interface (CLI). The CLI abstracts away a lot of the functionality of lower-level shell scripts that take care of the details involved with building your app, such as copying your web assets into the correct folders for each mobile platform, making platform specific configuration changes, or running specific build scripts to generate application binaries. You can read more about the Web Project Dev workflow in The Command-line Interface. Please note that often when people speak of the "CLI," they are talking about this Web Project Dev workflow.

Native Platform Dev

The second workflow can be thought of as a Native Platform Dev workflow. You should use it when you want to focus on building an application for a single platform and are interested in changing the lower-level platform details. While you can still use this workflow to build cross-platform apps, the lack of tools to abstract away the various build steps will make it more difficult. For example, you will have to use Plugman to install the same plugin once for each platform that you want to support. The benefit to using this Native Platform Dev workflow is that it gives you access to the lower-level shell scripts to build and test the application, so if you are hacking on the native side of things, this workflow is the most efficient way to test your changes. This workflow is also appropriate if you want to use the CordovaWebView as a small part in a larger native application (See the Embedding WebViews guide.) You can read about this workflow in the different Shell Tool guides, for instance, Android Shell Tool Guide and iOS Shell Tool Guide.

When first starting out, it might be easiest to use the Web Project Dev workflow to create an application. (To install the CLI, see The Command-line Interface.) Depending on the set of platforms you wish to target, you can rely on the CLI for progressively greater shares of the development cycle:

  • In the most basic scenario, you can use the CLI simply to create a new project that is populated with default configuration for you to modify.

  • For many mobile platforms, you can also use the CLI to set up additional project files required to compile within each SDK. For this to work, you must install each targeted platform's SDK. (See the Platform Guides for instructions.) As indicated in the Platform Support table, you may need to run the CLI on different operating systems depending on the targeted platform.

  • For supporting platforms, the CLI can compile executible applications and run them in an SDK-based device emulator. For comprehensive testing, you can also generate application files and install them directly on a device.

At any point in the development cycle, you can switch to using more of the Native Platform Dev workflow. The platform-specific SDK tools provided may provide a richer set of options. (See the Platform Guides for details about each platform's SDK tool set.)

An SDK environment is more appropriate if you want implement a hybrid app that mixes web-based and native application components. You may use the command-line utility to initially generate the app, or iteratively thereafter to feed updated code to SDK tools. You may also build the app's configuration file yourself. (See The config.xml File for details.)