Go Cordova-free before Capacitor 9

The headline feature of Capacitor 9 is that Cordova becomes optional. Today, every Capacitor app carries a Cordova compatibility layer so that old cordova-plugin-* packages keep working. From Capacitor 9, an app with no Cordova plugins can leave that layer out entirely. Ionic forecasts Capacitor 9 for the end of November 2026, and 9.0.0-alpha.7 landed on 18 September.

You do not have to remove Cordova plugins to upgrade. But most apps carry two or three that were added years ago and never revisited, and this is the right moment to replace them. It means a smaller app, fewer build warnings, and plugins that are actually maintained.

1. Find every Cordova plugin

The Capacitor CLI lists both kinds of plugin:

npx cap ls

Also check package.json directly, because some come in as dependencies of other packages:

npm ls --all 2>/dev/null | grep -iE "cordova-plugin|phonegap-plugin|@awesome-cordova-plugins"

@awesome-cordova-plugins/* (formerly @ionic-native) are only TypeScript wrappers. Each one points to a real Cordova plugin underneath, which is the thing to replace.

2. Replace each plugin

Most common Cordova plugins have a direct Capacitor replacement:

APIs differ slightly. Capacitor plugins return promises instead of taking success and error callbacks, and option names are not always identical. A typical change:

// Before: Cordova
navigator.camera.getPicture(onSuccess, onError, {
  quality: 80,
  destinationType: Camera.DestinationType.FILE_URI,
});

// After: Capacitor
import { Camera, CameraResultType } from '@capacitor/camera';

const photo = await Camera.getPhoto({
  quality: 80,
  resultType: CameraResultType.Uri,
});

If a plugin has no replacement, look for a maintained community plugin in the Capawesome or Capacitor Community organizations, or write a small local plugin. A focused local plugin is often less code than the Cordova plugin it replaces.

3. Remove the old plugin completely

npm uninstall cordova-plugin-camera @awesome-cordova-plugins/camera
npx cap sync

Then clean up what Cordova leaves behind:

• Preferences for the old plugin in capacitor.config.ts under cordova.preferences.
• Permission strings in Info.plist and AndroidManifest.xml that no other plugin uses. App Review asks about permissions you declare but do not use.
• Any deviceready listeners. Capacitor plugins are ready when your app loads.

4. Do it one plugin per release

Each replacement changes native code, so each needs a store build and real-device testing. Batching all of them into the Capacitor 9 upgrade means debugging five changes at once. A calmer order:

1. Replace one or two plugins per native release over the next two months.
2. Finish the Swift Package Manager migration, which Capacitor 9 and the end of CocoaPods Trunk both push you toward.
3. Upgrade to Capacitor 9 when it is stable, as its own release. See what changes in Capacitor 9.

5. Keep web and native releases apart

Plugin replacements are native changes and must go through the stores. The JavaScript that calls the new plugin, however, is web code, and it will need adjustments after real users hit edge cases: a permission prompt at the wrong moment, a changed file path, a different error shape.

With OtaKit, those follow-up fixes ship over the air. The CLI compares your web build with the native plugins in the store build before it releases, so a bundle that calls a plugin users do not have yet is stopped at upload, not discovered as a crash. Bump runtimeVersion with each native release that changes the plugin set, and OtaKit keeps old and new shells on the right bundles automatically.