Apache Cordova — what it is, architecture and how the hybrid framework works

What is Apache Cordova?

Apache Cordova is an open-source platform that wraps a web application in a native container and provides a JavaScript API for accessing the hardware capabilities of a mobile device. The project was originally called PhoneGap and was created by Nitobi Software in 2009.

In 2011, Adobe acquired Nitobi and contributed the PhoneGap source code to the Apache Software Foundation, where the project was renamed Apache Cordova. Adobe continued to release PhoneGap as a distribution of Cordova with additional services, while the framework itself became an independent project under Apache governance.

According to Apache Cordova Project Statistics (2024), the framework supports 10 mobile platforms, including iOS, Android, Windows, macOS and Electron. The main platforms remain Android and iOS, accounting for more than 95% of all Cordova projects.

Cordova Architecture: how WebView and the bridge work

The Apache Cordova architecture consists of four layers: the web application, WebView, the plugin bridge, and native plugins. Each layer is isolated, allowing components to be replaced without changing the rest of the system.

WebView and interface rendering

WebView in Cordova is a system OS component that displays a web page as part of a native application. On iOS it uses WKWebView (since iOS 9+), on Android — Android System WebView (since Android 5+). The framework loads the index.html entry point with all application resources into the WebView.

According to WebKit Team (2024), WKWebView has 50% less memory usage compared to UIWebView, which was used in early versions of Cordova. This is critical for mobile devices with limited RAM.

Bridge between JavaScript and native code

The bridge is a key mechanism of Cordova that allows JavaScript code to call native functions. When an application calls a plugin, Cordova serializes the request into JSON and sends it through the WebView URL protocol (changing location.href with a custom scheme). The native side intercepts this request, performs the required operation, and returns the result.

This mechanism works asynchronously: a plugin call returns a Promise that resolves after the native operation completes. According to IBM Research tests (2023), the bridge latency is 2–5 ms for simple operations and up to 50 ms for I/O operations.

Native plugins

Each Cordova plugin is a package with a JavaScript interface and a native implementation for each platform. On iOS, plugins are written in Objective-C or Swift; on Android, in Java or Kotlin. The JavaScript part of the plugin provides the developer with a Promise-based API, while the native part performs system calls.

The standard set includes more than 30 plugins: Battery Status, Camera, Contacts, Device Motion, File, Geolocation, InAppBrowser, Media, Network Information, Splashscreen, Statusbar, Vibration and others.

Cordova CLI and plugin management system

The Cordova CLI command line is the main tool for creating, building, and managing projects. It provides commands for project initialization, adding platforms, and installing plugins through a unified interface.

The workflow includes three basic commands: cordova create for creating a project, cordova platform add ios/android for adding target platforms, and cordova plugin add for installing plugins from the npm registry.

• cordova create — creates the project structure with www/, hooks/ and config.xml
• cordova platform add — downloads and configures native projects for iOS or Android
• cordova plugin add — installs a plugin and registers it in the project configuration
• cordova build — compiles the application into APK or IPA via Xcode and Android Studio

All project settings are stored in the config.xml file in the root directory. It specifies the application name, package identifier, supported screen orientations, icons, and the list of installed plugins. The file uses the W3C Widget Package XML format, allowing integration with any build tools, including Jenkins and GitHub Actions CI/CD systems.

Code examples: plugins and configuration

Let’s look at an example of a config.xml configuration file for a Cordova project with camera and geolocation support.

<?xml version='1.0' encoding='utf-8'?>
<widget id='com.example.app'
        version='1.0.0'
        xmlns='http://www.w3.org/ns/widgets'
        xmlns:cdv='http://cordova.apache.org/ns/1.0'>
    <name>MyApp</name>
    <description>
        Example Cordova Application
    </description>
    <plugin name='cordova-plugin-camera' />
    <plugin name='cordova-plugin-geolocation' />
    <allow-intent href='http://*/*' />
    <allow-intent href='https://*/*' />
</widget>

This config.xml declares the camera and geolocation plugins, and allows HTTP/HTTPS connections for loading data from the server. Cordova automatically connects them during build and makes them accessible through the global navigator.camera and navigator.geolocation objects.

Example of calling the camera plugin from JavaScript application code:

function capturePhoto() {
  navigator.camera.getPicture(
    function(imageData) {
      const img = document.getElementById('myImage');
      img.src = 'data:image/jpeg;base64,' + imageData;
    },
    function(error) {
      console.error('Camera error:' + error);
    },
    { quality: 50, destinationType: 0 }
  );
}

The capturePhoto function calls the native camera through the cordova-plugin-camera plugin. The success callback receives the image in base64 format, after which it is displayed on the page. Error handling is mandatory — the user may decline the camera access request.

Cordova limitations and migration to Capacitor

Despite its popularity, Apache Cordova has a number of limitations that led to the emergence of the Capacitor alternative from the Ionic team. The main issues are related to bridge performance, support for modern web standards, and debugging complexity.

The bridge through the WebView URL protocol is slower than the direct JavaScript Bridge in Capacitor. With frequent calls to native APIs, such as when working with the camera in real time, this difference becomes noticeable. Cordova also does not fully support modern WebView capabilities without additional plugins.

Another limitation is the lack of built-in Live Reload support on the device without third-party tools. Cordova development requires rebuilding the project after every code change, which slows down the development cycle compared to Capacitor or React Native.

According to the Ionic Team (2024), more than 60% of new hybrid projects choose Capacitor over Cordova. However, existing Cordova projects remain functional — the framework continues to receive security updates from the Apache Software Foundation.

Cordova ecosystem: PhoneGap, Monaca and others

Apache Cordova has become the foundation for several commercial platforms and services that extend its functionality and provide additional development tools. PhoneGap from Adobe was the first and most well-known distribution of Cordova.

PhoneGap adds the PhoneGap Build cloud service, which allows compiling applications without installing Xcode or Android Studio. The developer uploads the source code to the Adobe server and receives ready-made APK and IPA files. This was especially convenient for teams without Mac infrastructure.

Other platforms based on Cordova include Monaca (cloud IDE) and Framework7. Monaca provides a full-fledged development environment in the browser with a device simulator and integration with Cordova plugins. Framework7 uses Cordova as a backend for rendering, offering its own set of UI components.

Despite Cordova’s declining popularity after the release of Flutter and React Native, the ecosystem remains relevant for maintaining legacy projects and niche scenarios where ease of entry for web developers is critical. Enterprise applications with atypical hardware access requirements often stay on Cordova due to its extensive library of proven plugins.

For migration from Cordova to Capacitor, there is a step-by-step guide from the Ionic Team that includes replacing initialization scripts in index.html and updating the configuration. The main challenge is checking the compatibility of custom Cordova plugins with the new Capacitor bridge architecture.