A client who already had a browser-based ordering system asked if we could get them into the app stores without commissioning a full native rewrite. Budget was the deciding factor, they'd priced out a native app from another shop earlier in the year and the number was well outside what this project could justify, especially for a first attempt at seeing whether an app store presence would even move the needle for their business. PhoneGap turned out to be exactly the right tool for that specific ask, letting us package the existing HTML, CSS and jQuery app almost as-is and ship it through Apple's and Google's app stores instead of building two separate native codebases from scratch.
Why we reached for PhoneGap instead of a rewrite
The existing ordering system was already a reasonably well-built single-page app, jQuery for interactivity, a REST-ish PHP backend, nothing exotic. A full native rewrite would have meant maintaining three codebases going forward, the existing web app, an iOS app, and an Android app, each needing the same bug fixes applied three times whenever the menu logic changed or a pricing rule shifted. PhoneGap's pitch, wrap what you've already built in a native shell and ship the same code everywhere, matched this client's actual constraints far better than starting over would have.
What worked well
- Most of our existing HTML, CSS and jQuery carried over with very few changes, the bulk of the porting work was actually just testing, not rewriting.
- Device APIs we actually needed, camera access for a barcode-style feature that scans a loyalty card, were available through PhoneGap plugins without us having to write any native code ourselves.
- One codebase deployed to both the App Store and Google Play, which the client cared about a lot more than we expected going in, they'd assumed two separate apps would be needed and were pleasantly surprised it wasn't.
- Local storage for offline order drafts worked essentially the same as it had in the browser version, so a feature we'd already built for spotty wifi in cafes carried over for free.
What didn't
Performance on some list-heavy screens is noticeably behind a native app, scrolling isn't as smooth, and we had to simplify a couple of animations that felt fine on desktop but janky wrapped in a WebView. The menu screen in particular, which renders dozens of item cards with images, needed real optimization work, lazy-loading images below the fold and trimming a CSS transition that looked fine on a laptop but stuttered visibly on an older Android device the client's staff still used. For this client's needs, that tradeoff was worth it. For something more performance-sensitive, a game, or anything with continuous animation, we'd think harder about it before reaching for the same approach.
The build and signing process, our first real headache
Nobody warned us how much of the actual work would be certificates and provisioning profiles rather than code. Getting an iOS build signed correctly through Xcode, with the right provisioning profile matched to the right App ID and the right distribution certificate, took most of a day the first time, mostly spent re-reading Apple's documentation and re-generating profiles after small mismatches. Android's signing process was more straightforward, a keystore file and a couple of command-line steps, but losing that keystore would mean never being able to update the app under the same listing again, so we're now keeping three separate backups of it in places that don't depend on any one laptop surviving.
Where this approach breaks down
We wouldn't reach for PhoneGap if a client needed anything approaching native performance, background location tracking that needs to survive the OS aggressively killing backgrounded apps, or deep platform-specific UI conventions that a WebView wrapped in native chrome can't convincingly fake. It's a genuinely good fit for exactly the shape of problem this client had, an existing content-driven or form-driven web app that mostly needs an icon on a home screen and access to a device API or two, and a poor fit for anything where the interaction itself needs to feel native rather than merely function.
What we'd do differently next time
We'd budget real time for device testing across a wider range of Android versions specifically, iOS fragmentation turned out to be far less of a problem than Android's, where WebView behavior genuinely differs between manufacturer skins and OS versions in ways that are hard to predict without a physical device in hand. We'd also start the certificate and signing process earlier in the project timeline rather than treating it as a final step, since it's the part most likely to eat an unplanned day right when a client is expecting to see the app live.
Getting through app store review the first time
Apple's review process rejected our first submission, not for anything code-related, but because the app's icon didn't meet their sizing requirements for one of the required resolutions and because we'd left placeholder screenshots in the submission that were clearly just resized browser screenshots rather than actual device mockups. Neither issue took long to fix, an afternoon at most, but it added most of a week to the timeline once we accounted for the resubmission queue, a lesson we've since carried into every mobile project: budget calendar time for at least one review round-trip, even when the underlying app is solid, because review criteria cover packaging and presentation just as much as functionality.
Push notifications, added after launch
The client came back a month after launch wanting push notifications for order status updates, something we hadn't scoped into the original PhoneGap wrapper. Getting a push notification plugin wired up meant registering the app with Apple's push notification service and Google's equivalent separately, generating and managing yet another set of certificates, and writing a small bit of PHP on our existing backend to actually send the notification when an order status changed. It worked, but it was a genuinely separate mini-project layered onto the original wrapper rather than a small add-on, and we now flag push notifications as their own line item on any mobile quote rather than assuming it's a quick follow-up.
What ongoing maintenance actually looks like
Six months in, maintaining this app has turned out to mean two different things: normal client feature requests, same as any web project, plus periodically updating the PhoneGap wrapper itself as new iOS and Android versions ship and occasionally break something in how the WebView renders or how a plugin behaves. That second category is new to us, a web app doesn't need updating just because a browser released a new version, but a wrapped app can start behaving oddly on a new OS release even when we haven't touched a line of our own code, and we've had to build a habit of testing against new OS betas before they go final rather than waiting for a client to report something broken.
Would we recommend this to another agency
We've fielded this question from a couple of other small shops since finishing this project, and our honest answer is yes, specifically for a client with an existing, reasonably well-built web app and a limited budget who mainly wants app store presence and a couple of device APIs, camera, push notifications, geolocation. We'd steer a different client, one starting from scratch with no existing web app and a bigger budget, toward evaluating native development directly instead, since the calculus that made PhoneGap the right call here, an existing codebase to leverage, was the whole reason it won out, and that calculus doesn't hold for every mobile project.
The client conversation this changed
Perhaps the biggest shift is in how we now pitch mobile presence to a client who already has a decent web app. Before this project, "get into the app stores" felt like it automatically meant a much bigger budget conversation. Now it's a genuine spectrum, wrap-and-ship for a client who mainly wants presence and a device API or two, versus a full native build for a client whose product genuinely depends on native-grade performance or platform-specific interaction. Being able to lay out that spectrum honestly, tradeoffs included, rather than defaulting every client toward the more expensive option, has made these early mobile conversations feel a lot less like a sales pitch and more like an actual technical recommendation.