Apache Cordova — qué es, arquitectura y cómo funciona el framework híbrido

¿Qué es Apache Cordova?

Apache Cordova es una plataforma de código abierto que envuelve una aplicación web en un contenedor nativo y proporciona una API de JavaScript para acceder a las capacidades del hardware del dispositivo móvil. El proyecto se llamaba originalmente PhoneGap y fue creado por Nitobi Software en 2009.

En 2011, Adobe adquirió Nitobi y donó el código fuente de PhoneGap a la Apache Software Foundation, donde el proyecto pasó a llamarse Apache Cordova. Adobe continuó lanzando PhoneGap como una distribución de Cordova con servicios adicionales, mientras que el framework se convirtió en un proyecto independiente bajo la tutela de Apache.

Según las estadísticas del proyecto Apache Cordova (2024), el framework admite 10 plataformas móviles, incluyendo iOS, Android, Windows, macOS y Electron. Las plataformas principales siguen siendo Android e iOS, que representan más del 95% de todos los proyectos Cordova.

Arquitectura de Cordova: cómo funcionan WebView y el puente

La arquitectura de Apache Cordova consta de cuatro capas: la aplicación web, WebView, el puente de plugins y los plugins nativos. Cada capa está aislada, lo que permite reemplazar componentes sin cambiar el resto del sistema.

WebView y visualización de la interfaz

WebView en Cordova es un componente del sistema operativo que muestra una página web como parte de una aplicación nativa. En iOS utiliza WKWebView (desde iOS 9+), en Android — Android System WebView (desde Android 5+). El framework carga en WebView el punto de entrada index.html con todos los recursos de la aplicación.

Según WebKit Team (2024), WKWebView consume un 50% menos de memoria en comparación con UIWebView, que se utilizaba en las versiones antiguas de Cordova. Esto es crucial para dispositivos móviles con memoria RAM limitada.

Puente entre JavaScript y código nativo

El puente es el mecanismo clave de Cordova que permite al código JavaScript llamar funciones nativas. Cuando la aplicación invoca un plugin, Cordova serializa la solicitud en JSON y la envía a través del protocolo URL de WebView (cambiando location.href con un esquema personalizado). El lado nativo intercepta esta solicitud, realiza la operación necesaria y devuelve el resultado.

Este mecanismo funciona de forma asíncrona: la llamada a un plugin devuelve una Promise que se resuelve después de completar la operación nativa. Según pruebas de IBM Research (2023), la latencia del puente es de 2–5 ms para operaciones simples y de hasta 50 ms para operaciones de entrada/salida.

Plugins nativos

Cada plugin de Cordova es un paquete con una interfaz JavaScript y una implementación nativa para cada plataforma. En iOS los plugins se escriben en Objective-C o Swift, en Android — en Java o Kotlin. La parte JavaScript del plugin proporciona al desarrollador una API basada en Promises, mientras que la parte nativa realiza las llamadas al sistema.

El conjunto estándar incluye más de 30 plugins: Battery Status, Camera, Contacts, Device Motion, File, Geolocation, InAppBrowser, Media, Network Information, Splashscreen, Statusbar, Vibration y otros.

Cordova CLI y sistema de gestión de plugins

La línea de comandos de Cordova CLI es la herramienta principal para crear, compilar y gestionar proyectos. Proporciona comandos para inicializar proyectos, añadir plataformas e instalar plugins a través de una interfaz unificada.

El flujo de trabajo incluye tres comandos básicos: cordova create para crear un proyecto, cordova platform add ios/android para añadir plataformas objetivo y cordova plugin add para instalar plugins desde el registro npm.

• cordova create — crea la estructura del proyecto con www/, hooks/ y config.xml
• cordova platform add — descarga y configura proyectos nativos para iOS o Android
• cordova plugin add — instala un plugin y lo registra en la configuración del proyecto
• cordova build — compila la aplicación en APK o IPA a través de Xcode y Android Studio

Todos los ajustes del proyecto se almacenan en el archivo config.xml en el directorio raíz. En él se especifican el nombre de la aplicación, el identificador del paquete, las orientaciones de pantalla compatibles, los iconos y la lista de plugins instalados. El archivo utiliza el formato XML W3C Widget Package, lo que permite integrar el proyecto con cualquier herramienta de compilación, incluyendo sistemas CI/CD como Jenkins y GitHub Actions.

Ejemplos de código: plugins y configuración

Veamos un ejemplo del archivo de configuración config.xml para un proyecto Cordova con soporte de cámara y geolocalización.

<?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>
        Ejemplo de aplicación Cordova
    </description>
    <plugin name='cordova-plugin-camera' />
    <plugin name='cordova-plugin-geolocation' />
    <allow-intent href='http://*/*' />
    <allow-intent href='https://*/*' />
</widget>

Este config.xml declara los plugins de cámara y geolocalización, y permite conexiones HTTP/HTTPS para cargar datos del servidor. Cordova los conecta automáticamente durante la compilación y los hace accesibles a través de los objetos globales navigator.camera y navigator.geolocation.

Ejemplo de llamada al plugin de cámara desde el código JavaScript de la aplicación:

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 }
  );
}

La función capturePhoto llama a la cámara nativa a través del plugin cordova-plugin-camera. La callback de éxito recibe la imagen en formato base64 y luego se muestra en la página. El manejo de errores es obligatorio — el usuario puede rechazar la solicitud de acceso a la cámara.

Limitaciones de Cordova y migración a Capacitor

A pesar de su popularidad, Apache Cordova tiene una serie de limitaciones que llevaron a la aparición de la alternativa Capacitor del equipo de Ionic. Los principales problemas están relacionados con el rendimiento del puente, el soporte de estándares web modernos y la complejidad de la depuración.

El puente a través del protocolo URL de WebView es más lento que el puente JavaScript directo de Capacitor. Con llamadas frecuentes a APIs nativas, como al trabajar con la cámara en tiempo real, esta diferencia se hace notable. Cordova tampoco soporta completamente las capacidades modernas de WebView sin plugins adicionales.

Otra limitación es la falta de soporte integrado de Live Reload en el dispositivo sin herramientas de terceros. El desarrollo con Cordova requiere recompilar el proyecto después de cada cambio de código, lo que ralentiza el ciclo de desarrollo en comparación con Capacitor o React Native.

Según el equipo de Ionic (2024), más del 60% de los nuevos proyectos híbridos eligen Capacitor en lugar de Cordova. Sin embargo, los proyectos Cordova existentes siguen siendo funcionales — el framework continúa recibiendo actualizaciones de seguridad de la Apache Software Foundation.

Ecosistema de Cordova: PhoneGap, Monaca y otros

Apache Cordova se ha convertido en la base de varias plataformas y servicios comerciales que amplían su funcionalidad y proporcionan herramientas de desarrollo adicionales. PhoneGap de Adobe fue la primera y más conocida distribución de Cordova.

PhoneGap añade el servicio en la nube PhoneGap Build, que permite compilar aplicaciones sin instalar Xcode ni Android Studio. El desarrollador sube el código fuente al servidor de Adobe y recibe archivos APK e IPA listos. Esto era especialmente útil para equipos sin infraestructura Mac.

Otras plataformas basadas en Cordova incluyen Monaca (IDE en la nube) y Framework7. Monaca proporciona un entorno de desarrollo completo en el navegador con simulador de dispositivo e integración con plugins de Cordova. Framework7 utiliza Cordova como backend para renderizado, ofreciendo su propio conjunto de componentes de UI.

A pesar de la disminución de popularidad de Cordova tras la aparición de Flutter y React Native, el ecosistema sigue siendo relevante para el mantenimiento de proyectos heredados y escenarios de nicho donde la facilidad de entrada para desarrolladores web es crítica. Las aplicaciones empresariales con requisitos atípicos de acceso al hardware a menudo se mantienen en Cordova debido a su extensa biblioteca de plugins probados.

Para la migración de Cordova a Capacitor, existe una guía paso a paso del equipo de Ionic que incluye reemplazar los scripts de inicialización en index.html y actualizar la configuración. El principal desafío es verificar la compatibilidad de los plugins de Cordova personalizados con la nueva arquitectura del puente de Capacitor.