A nonprofit client needed a mobile app for event schedules, volunteer sign-ups, and push notifications — content-driven functionality with no need for intensive native performance, camera access beyond the basics, or complex animations. With a modest budget and a single small team needing to maintain both iOS and Android versions, we built it in Cordova rather than reaching for React Native or native development, a choice we made deliberately rather than by default.
Why this decision needed real justification in 2019
Cordova is not fashionable in 2019 — most of the framework conversation has moved to React Native, and a fair number of developers we talk to at industry events treat hybrid webview-based apps as a dated approach best left behind. We take that skepticism seriously rather than dismissing it, since it is grounded in real, well-documented limitations of the approach for certain kinds of apps. But "not fashionable" and "wrong for every use case" are different claims, and this particular client's needs mapped closely enough onto Cordova's actual strengths that recommending something more fashionable would have meant recommending a worse fit purely for appearance's sake.
What actually mattered for this specific client
- A single small internal team needing to maintain both iOS and Android versions long after we hand the project off, with limited capacity to maintain two genuinely separate native codebases or even two React Native codebases with meaningfully different platform-specific code paths
- Content-driven screens — schedules, sign-up forms, notification lists — with no performance-sensitive interactions like complex gestures, animations, or camera-heavy features that would meaningfully benefit from native rendering
- A modest budget that could not comfortably stretch to native development's typically higher cost, nor to the added complexity React Native introduces around native module bridging for any feature that goes beyond its well-trodden paths
What Cordova actually delivered here
Wrapping a well-built responsive web app in a native shell got the client to both app stores faster and cheaper than a React Native build would have, with one shared codebase to maintain going forward rather than two platform-specific ones or even one codebase with meaningful platform-specific branches. Plugin support for push notifications and basic device APIs was mature enough to cover everything the client actually needed, and the plugin ecosystem's maturity for exactly these common, well-established use cases is one of the underappreciated strengths of a platform that has been around long enough for the easy problems to already have solid, well-tested solutions.
Where we drew a hard line against it
We would not recommend Cordova for anything performance-sensitive or animation-heavy — that is genuinely React Native or native territory now, and no amount of plugin maturity closes that particular gap. A webview's rendering performance for complex, frequently updating UI genuinely lags behind what native rendering or React Native's native-bridged components can deliver, and pretending otherwise to a client with those needs would be doing them a real disservice purely to defend a technology choice out of habit or comfort.
The conversation we now have with every mobile client upfront
Writing Cordova off entirely for every use case would be a mistake, and we now walk every prospective mobile client through the same short set of questions before recommending anything: how content-driven versus interaction-heavy is the app, how many platforms genuinely need first-class support, what is the realistic long-term maintenance capacity on the client's side, and how sensitive is the specific feature set to native-level performance. Most projects answer these questions clearly enough that the right tool becomes obvious fairly quickly, and this client's answers pointed just as clearly toward Cordova as a different client's would point toward React Native or full native development.
Results
The app shipped on budget and on schedule to both app stores, and the client's small internal team has been able to make minor content and configuration updates themselves without needing to come back to us for every small change, which was an explicit goal given their limited ongoing technical capacity. We consider this a genuine success story for a tool that gets dismissed more readily than its actual, still-real strengths for the right kind of project deserve.
The specific plugins that mattered most for this project
The nonprofit's core needs mapped onto a short, well-established list of Cordova plugins: push notifications through a standard notification plugin, a calendar integration plugin for adding event schedules directly to a user's device calendar, and a basic file plugin for downloading printable event materials for offline use. None of these pushed against the edges of what Cordova's plugin ecosystem handles comfortably, which is precisely the kind of well-trodden use case where a mature hybrid framework's plugin maturity genuinely pays off rather than becoming a source of friction.
How we structured the codebase for long-term client maintenance
Knowing the client's own small team would need to make minor updates themselves after handoff, we deliberately kept the app's structure close to a standard responsive website rather than leaning on anything Cordova-specific beyond the minimum needed for native packaging and plugin access. Content updates — new events, updated volunteer sign-up forms — live in a simple, well-documented data structure the client's team can edit directly, without needing to understand Cordova's build and packaging process at all for routine content changes, reserving that more specialized knowledge only for the rarer case of adding an entirely new feature.
App store review experience
Submitting a Cordova app for App Store and Play Store review went more smoothly than we braced for, based on some other agencies' war stories about hybrid apps facing extra scrutiny. Apple's review did flag one initial submission for insufficiently native-feeling navigation patterns, which we addressed by adjusting a couple of transition animations to better match iOS platform conventions rather than the generic web-style transitions Cordova ships with by default — a relatively small adjustment that resolved the review feedback without needing any deeper architectural change.
Comparing actual long-term cost against a React Native estimate
We priced out what an equivalent React Native build would have cost this same client, purely as an internal exercise to sanity-check our recommendation, and the gap was substantial enough to matter for a nonprofit operating on a genuinely constrained budget — not just in initial build cost, but in the ongoing cost of maintaining two platform-specific native module integrations that a React Native approach would likely have needed for the calendar and file-download functionality, versus Cordova's more mature, already-solved plugin equivalents for exactly those needs.