Hey @matheusccastro, glad to see you here 
Capacitor and Cordova both follow the webview approach, allowing the same web code to run on native platforms with little effort.
The main reasons to migrate are features and maintenance. Cordova itself still gets updates, but the ecosystem depends heavily on plugins, and many of them are abandoned, deprecated, or not updated with the latest native APIs. A clear example is RevenueCat’s Cordova plugin for cross-platform payments, which is being deprecated in favor of its CapacitorJS version. This will happen more often, and Capacitor ensures plugins evolve and integrate better with the latest native features.
Some key differences:
- Native projects: Cordova generates them as build artifacts (changes can be overwritten). Capacitor treats them as independent projects that you keep and commit.
- Plugins: Cordova relies on an old plugin ecosystem, while Capacitor plugins are modern, Promise-based, easier to write, and actively maintained.
- Web support: Capacitor APIs often work in the browser too (PWA support). For example, camera or file management plugins run both natively and on the web, with dedicated implementations for each in a single module.
- Developer experience: Capacitor encourages direct use of Xcode/Android Studio, integrates more smoothly with modern SDKs, and provides typed, well-documented APIs.
- Features & Maintenance: Both Capacitor core and its plugin ecosystem are actively updated with new features and support for the latest native APIs. This matters because it lets you rely more on the open source community instead of maintaining your own core and plugin forks and have experts on each of them.
Meteor moving to CapacitorJS is one of the smoothest integrations possible. CapacitorJS feels like the natural successor to CordovaJS, with built-in compatibility for Cordova plugins. This makes the transition simple for existing native Meteor projects, though it’s recommended to migrate to modern Capacitor alternatives over time.