Is Apache Cordova suitable for building progressive web apps (PWAs)?

Cordova doesn't build PWAs; it wraps an already-built PWA into a native shell for app store distribution. The two solve different problems: a PWA runs from a URL in any modern browser, while Cordova packages that same kind of web code into an installable binary.

When does wrapping an existing PWA with Cordova make sense?

If a PWA already exists and the goal is a listing in Apple's App Store, wrapping it in Cordova is a reasonable path, since Apple doesn't accept a bare web URL as an app submission the way Google Play does through Trusted Web Activity. Wrapping also opens access to native-only APIs, such as Bluetooth or background location, that a browser sandbox won't expose to a web app no matter how PWA-compliant it is.

When does it not make sense?

Building the PWA itself is a different job, and Cordova doesn't help with it. Service workers, the manifest.json install prompt, and the Web Push API are all implemented by the browser, not by Cordova's WebView wrapper. Cordova apps typically load their content over the file:// protocol, and service workers generally won't register there without extra configuration, such as app-bound domains on iOS, so building the PWA layer inside a Cordova project tends to fight the tooling rather than use it.

What's the practical takeaway?

For Android-only distribution, Trusted Web Activity wraps a PWA using the device's real Chrome engine and needs no separate WebView runtime, which is closer to what most teams actually want. Cordova earns its place mainly on iOS, where Apple requires a bundled native app rather than a web link, so it functions as a distribution wrapper around a PWA that was built with standard web tooling first.

Updated: August 12, 2026