There's been some understandable confusion among our clients about the difference between PhoneGap and Apache Cordova, given that PhoneGap is Adobe's distribution built on top of the open-source Cordova project underneath, a distinction that matters to us as developers but means very little to a client who just wants to know why their app's documentation sometimes says one name and sometimes the other.
Practically, for the apps we maintain, the CLI tooling around Cordova has matured a lot this year, plugin management in particular is far less fragile than it was when we first wrapped a client's app, back when adding a plugin sometimes meant manually editing native project files afterward to make sure the plugin's own native code was actually wired in correctly. The command-line plugin add and plugin remove commands now handle that wiring reliably enough that we've stopped double-checking native project files by hand after every plugin change, a habit that used to be mandatory and now feels like unnecessary caution.
We've shifted our new projects to using the Cordova CLI directly rather than Adobe's PhoneGap Build service, mostly for faster iteration during development, PhoneGap Build's cloud compilation step added a genuine wait, upload, queue, compile, download, that a local Cordova build skips entirely, and for a project in active development that difference adds up across dozens of test builds a day. We're still comfortable recommending PhoneGap Build specifically for a client without a local build environment set up who wants to compile occasional updates themselves without installing Xcode or the Android SDK, it remains a genuinely useful service for that narrower case, just not our own default anymore.
One small operational change worth mentioning: we've started pinning specific Cordova platform and plugin versions in each project's configuration rather than always pulling the latest, after a plugin update on one project silently changed a default behavior in a way that broke camera capture on one specific device model, a problem that took a confusing afternoon to trace back to an unannounced plugin update rather than anything we'd changed ourselves.
The underlying WebView approach and its performance tradeoffs haven't changed, wrapping a WebView in a native shell is still fundamentally the same technique it always was, with the same rough edges around scrolling performance and animation smoothness we've written about before. But the day-to-day developer experience genuinely has improved, for the better, and that's made hybrid app maintenance feel like a meaningfully less fragile part of our work than it did when we started down this path.
We've also started keeping a short compatibility note per client project now, which Cordova version, which pinned plugin versions, tested against which physical devices, since the confusion around naming turned out to be a small preview of a bigger ongoing challenge, keeping track of which combination of tooling versions a given client's app was actually built and tested against as both the tooling and the devices in the field keep changing under us. It's a small amount of extra documentation, but it's already saved us from a guessing game more than once when revisiting an older client's app after months away from it.