PhoneGap and Cordova app migration
PhoneGap was shut down by Adobe in 2020, and Apache Cordova, the open-source project underneath it, is maintained by a small community whose plugins are the first thing to break when Apple and Google raise their requirements, as both did in 2026. The web application inside the shell is usually fine. Solve With Software keeps that code, replaces the shell with Capacitor, rewrites or replaces the plugins that have no equivalent, and gets the app shipping through the stores again, in stages, on a fixed price from the assessment.
Free · 1 hour · no obligation
Where PhoneGap and Cordova stand
PhoneGap is over. Adobe closed it and PhoneGap Build in 2020, so any app that was built through PhoneGap Build has had no build pipeline for years. Cordova, the Apache project PhoneGap was built on, still exists and still releases, but it's a small community keeping it going, and the plugin ecosystem it depends on has thinned to the point where the plugin your app needs is often unmaintained.
The stores are the forcing function. Since April 2026 App Store uploads need Xcode 26; from August 2026 Google Play updates need to target Android 16. An old Cordova plugin that was written against a much older platform often can't be built for those targets, so the app can't ship a fix, however small.
What carries over
The app. A PhoneGap or Cordova app is HTML, CSS and JavaScript in a native wrapper, and that web code doesn't care what wrapper it's in. Screens, logic, data handling and the backend it talks to all survive. Often the web code is jQuery Mobile or an early framework, which dates it but doesn't stop it working.
What doesn't carry over is the wrapper and the plugins. Camera, geolocation, file access, push, barcode scanning: each one was a Cordova plugin, and each needs a Capacitor equivalent, a rewrite, or a decision that the app no longer needs it.
The paths
Move the shell to Capacitor. Capacitor is the maintained wrapper made by the Ionic team, and it's designed to take an existing web app. The web code moves as it is, each Cordova plugin is mapped to its Capacitor equivalent (many exist) or rewritten, and the app builds with current Xcode and current Android tooling. The right path when the web app does its job and the business wants it as it is.
Move the shell and modernise the web code. Same as above, then the web app itself brought forward from jQuery Mobile or whatever it was to a current framework, screen by screen. The right path when the app has a future and the old web code is holding it back.
Rebuild in Flutter. When the app is small, or when a wrapped web app was the wrong fit for what it does: heavy camera or maps use, offline work, anything where the shell was always the weak point. The backend and the design carry across. We build in Flutter, so the assessment compares it on cost.
The assessment reads the app and the plugin list and prices each path as a fixed number.
The accounts and keys you need to own
Old apps are the ones most likely to have lost track of these. Apple Developer account, certificates and profiles. Google Play account, the upload key, and whether Play App Signing holds the signing key. If PhoneGap Build did the signing, the keys were uploaded there, and where they are now is a question. The backend account. Push certificates. The assessment establishes each before anything else, because without them no build ships.
Your data
Behind an API or a hosted backend, and it stays where it is, in an account you own. Nothing reaches your users until it has proven itself somewhere else: a build tested against a staging backend, released to a test group through TestFlight and the Play internal track, then to the store.
What it costs
The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a PhoneGap or Cordova app it inventories the plugins and their Capacitor equivalents, checks the accounts and keys, and prices the shell migration and the rebuild as fixed numbers. What drives the price and the payment terms each have a page.
The risks of waiting
An app that can't ship a fix. That's the position of most PhoneGap apps today, because the build pipeline is gone and the plugins can't meet the store targets that arrived in 2026. After that: a phone operating system update that breaks a plugin, a lapsed developer account, and keys that were in PhoneGap Build and nowhere else.
How we approach it
Keys and accounts first, then the shell, then the plugins one at a time, then the web code if it needs it. Marc Allington has built and wrapped web applications for mobile and builds mobile apps in Flutter now. Everything we build runs in your own accounts, with full source code and ownership transferring to you on final payment.
The technical checklist for a PhoneGap or Cordova takeover
| Check | Why it matters |
|---|---|
| PhoneGap Build or local Cordova, and which Cordova version | PhoneGap Build means no pipeline and possibly no keys; the version sets the migration distance. |
| Plugin inventory, and which have Capacitor equivalents | The migration's real cost. |
| The web code: framework, version, and does it run in a browser on its own? | If it runs in a browser, the shell can be swapped under it. |
| Apple and Google accounts, keys, Play App Signing | Without them no build ships; PhoneGap Build may have held them. |
| Backend and push | Where the data and notifications live, and in whose account. |
| Store status: last release, current targets | How far from shippable it is today. |
| Device features used: camera, location, files, scanning | Each is a plugin decision. |
| Tests | Usually none. The safety net comes first. |
Each answer goes into the report with its stage and a fixed price.
Questions
What people ask before they book.
Our PhoneGap app still works on people's phones. Why change it?
Because you can't change it. Without a build pipeline that meets the current store requirements, no fix, however small, can be shipped. It works until the next phone update breaks something, and then it doesn't.
Do we lose the app and start again?
No. The web code inside the shell carries over as it is. Capacitor is designed to wrap an existing web app, and the plugins are the only part that has to change.
PhoneGap Build had our signing keys. Are they gone?
Possibly. If Play App Signing was enabled, Google holds the Android signing key and the upload key can be reset. Apple certificates can be reissued from the developer account. Establishing what exists is the first job.
Would a rebuild in Flutter be better?
For a small app, or one where the wrapped-web approach was always the weak point, sometimes. The assessment prices both. Keeping the web code and swapping the shell is usually cheaper when the app does its job.
How long until we can ship an update?
It depends on the plugin list and whether the keys exist, which the assessment measures. The shape is the usual one: a Capacitor build in the test tracks within about six weeks, then stages, each priced before you commit.
Start with a free consultation
An hour on your system, online or by phone. From there we size the assessment, from £395 + VAT, and give you an exact price before you commit.
Want the numbers first? See how pricing works.
Written by Marc Allington, founder. .