Capacitor vs Cordova in 2026: Should You Migrate?

01

The old app is not automatically the wrong app

Imagine a field service app used by engineers throughout the day. It was built with Cordova, stores jobs for offline use, takes photographs, reads the device location and sends push notifications. It is not fashionable, but it still reaches the App Store and Google Play and the team knows how to support it.

A request arrives for a new biometric sign-in flow and somebody suggests moving the whole app to Capacitor first. That may be the right direction. It may also turn one feature into a platform migration before the team has checked whether the existing application is actually blocking the work.

Capacitor is the modern default I would examine for a new web-based mobile application. Its development model fits current web tooling and makes the native iOS and Android projects visible parts of the codebase. Cordova, however, is still an active Apache project with current platform releases in 2026.

The useful question is therefore not which name sounds newer. It is whether the current runtime helps or hinders the next few years of delivery.

02

What Capacitor and Cordova actually do

Both tools let a team use HTML, CSS and JavaScript to build an application that can be packaged for mobile platforms. The web application runs inside a native container, while plugins provide access to features such as the camera, files, notifications, location and device information.

That shared idea is why the comparison can look simple. The differences appear in how the native projects are managed, how plugins are designed and how easily a team can work directly with Swift, Objective-C, Java or Kotlin when the web layer is not enough.

Cordova grew around a configuration-led workflow. The command line creates and manages platform projects, and plugins often change native configuration during that process. It remains useful, but years of plugins, build hooks and platform assumptions can make an older project difficult to reason about.

Capacitor treats the iOS and Android projects as source code that belongs to the application. A web developer can use a consistent JavaScript API, while a native developer can open the same projects in Xcode or Android Studio and make a deliberate platform-specific change. That is a small architectural difference with a large effect on ownership.

03

Why Capacitor usually fits new hybrid apps better

Capacitor version 8 is the current documented release in 2026. It can be added to an existing modern JavaScript project or used in a new application, and it supports iOS, Android and the web through one web-focused API model.

The framework used for the interface is a separate choice. A Capacitor application can use Ionic Framework, Vue, React, Angular or another web setup. Capacitor is the native runtime rather than the visual component library.

For a new build, the appeal is practical. The team can keep web code close to current browser standards, install official Capacitor plugins for common device features and add custom native code when a requirement falls outside the shared API. Native and web developers can work in the tools they already understand without pretending the native layer does not exist.

That does not make the application maintenance-free. Apple and Google still change their SDKs, privacy rules, store requirements and background behaviour. A cross-platform runtime reduces duplicated application work, but somebody still has to test the real devices and own the native release process.

04

Cordova is still maintained, so do not migrate for fashion

It is easy to describe Cordova as abandoned because Capacitor has become the common recommendation around modern Ionic development. The current evidence is more balanced. Apache released Cordova Android 15.1.0 in July 2026 and Cordova iOS 8.1.1 in the same month, alongside current plugin updates.

That matters when the existing app is stable. A supported Cordova application with reproducible builds, current platform versions and healthy plugins may continue to serve the business perfectly well. Replacing the runtime creates testing, store submission and operational work even when the interface barely changes.

Staying still is not free either. An old Cordova app may depend on abandoned plugins, hand-edited generated files, an outdated Node.js version or build knowledge held by one developer. The runtime name alone does not reveal that risk. The repository and release process do.

Treat migration as a response to evidence: failing upgrades, poor plugin support, difficult native changes, unreliable builds or a roadmap that the current setup makes expensive. A quieter codebase is a benefit, but it is not a business case on its own.

05

The plugin inventory usually decides the amount of work

Return to the field service app. Its visible screens may move to Capacitor with few changes because the same web code still runs in a WebView. The awkward work is more likely to sit around the camera, file storage, push notifications, deep links, location tracking and any plugin written specifically for the old app.

Capacitor includes a compatibility layer for many Cordova plugins, but compatibility is not universal. A plugin may rely on unsupported hooks, edit native files in a fragile way or behave differently around permissions and application lifecycle events. A package installing successfully is not proof that its important behaviour still works.

List every plugin and classify it before estimating the migration. Prefer an official Capacitor plugin when one covers the requirement. Then consider supported or active community alternatives. Keep a Cordova plugin through the compatibility layer only when its behaviour and maintenance are understood. Custom business-critical plugins deserve their own migration and test plan.

This inventory is also a chance to remove features nobody uses. Carrying an abandoned barcode scanner integration into a new runtime because it appears in package.json is the mobile equivalent of carefully moving an empty filing cabinet.

06

Capacitor vs Cordova at a glance

The table below is not a scorecard. It shows where the two approaches create different kinds of work and which questions a team should investigate.

07

Plan the migration as a sequence of proofs

If the evidence supports moving, do not begin by deleting the working Cordova platforms. Capacitor's own migration guidance recommends using a separate branch, and that is a sensible minimum. The existing release remains the baseline while the new runtime is proved.

First, make the current app build reliably. Record the Node.js version, signing process, platform versions, environment variables and store configuration. A migration becomes much harder when the team cannot tell whether a new failure came from Capacitor or was already present.

Next, add Capacitor and create fresh iOS and Android projects. Move configuration deliberately rather than copying folders wholesale. Install the replacement plugins from the inventory and keep a visible list of features still using Cordova compatibility.

Then test the journeys that cross the web and native boundary. For the field service app, that means permissions, camera capture, files, offline synchronisation, push notification routing, deep links, background and foreground transitions, location behaviour and recovery after the operating system closes the app.

Finally, rebuild continuous integration, signing and store delivery around the new projects. Release to internal testers or a controlled audience before the full rollout. The migration is complete when the team can build, test, release, monitor and support the application, not when the first screen appears in a simulator.

08

When keeping Cordova is the sensible choice

A Cordova app may not need an immediate migration when it has current platform versions, dependable builds, maintained plugins and no roadmap item that requires deeper native work. In that position, the safer investment may be improving tests, documenting releases and removing the riskiest dependencies one at a time.

The answer changes when a store deadline cannot be met, a critical plugin is abandoned, native changes keep disappearing during builds or the app needs capabilities the current structure makes difficult to own. Migration then removes a real delivery constraint rather than satisfying a preference.

A short technical assessment should be able to produce the plugin inventory, build baseline, platform gaps, migration risks and a recommendation. If it cannot explain what the business gains and what must be retested, the team is not ready to estimate the change.

For a new web-based mobile app, start by evaluating Capacitor. For an existing Cordova app, start by evaluating the evidence.

09

Choose the runtime around the next version of the app

Capacitor offers a cleaner fit for modern web tooling and deliberate native development. Cordova still has active releases and can remain a sound home for an application that is current, understood and doing its job.

The decision becomes clearer when the team stops comparing feature lists and inspects the real application. Which plugins carry business-critical behaviour? Can the app be rebuilt today? What changes are coming from Apple, Google and the product roadmap? Who can support the native layer when something goes wrong?

If those answers point towards migration, move in small proofs and keep the working release available until the new path is dependable. If they do not, improve the Cordova application you already own and review the decision when the evidence changes.

If you need an independent view of an existing hybrid app, I can assess the code, plugins, build process and roadmap before a migration budget is committed.