Almost every long-running Meteor app we assess has a web tier someone still understands and a mobile tier nobody has opened in years. The mobile tier is Cordova: meteor add-platform ios android, a mobile-config.js file, a handful of plugins, and a build that last succeeded on a laptop that has since been recycled.
It is a genuinely good piece of engineering for what it was. One codebase, native shells, and hot code push — shipping a JavaScript fix to phones without waiting on review was a real advantage in 2016, and it is still a real advantage. But the Cordova tier ages differently from the rest of the app, because its deadlines are set by Apple and Google rather than by you. This is the audit and the decision framework we use when a client says "and there's also a mobile app."
Why the mobile tier ages faster
Three clocks run independently of your product roadmap:
- Store SDK requirements. Apple and Google both periodically raise the minimum SDK/API level an app must build against to be accepted for a new submission. These deadlines are announced, they arrive annually-ish, and missing one does not remove your app — existing installs keep working — but it does mean you cannot ship an update until you catch up. That is the failure mode to avoid: an urgent fix you are unable to deliver.
- The native toolchain. Xcode versions, Android Gradle Plugin versions, and JDK versions all move, and each has its own compatibility window with whatever
cordova-ios/cordova-androidversion your Meteor release pins. A build that worked is not a build that works. - Plugin abandonment. Cordova plugins have the same maintenance profile as Atmosphere packages, and often worse. A plugin that stopped getting releases in 2019 is frequently the specific thing blocking a target-SDK bump.
Note what is not on that list: your Meteor application code. The JavaScript usually still runs fine. The problem is almost always the shell around it.
Audit before you decide anything
Write these down before forming an opinion. Most of it takes an afternoon.
- Current store status. Both listings: last successful submission date, current target SDK/API level, and any pending store warnings in App Store Connect and the Play Console. This tells you whether you have a deadline problem now or a deadline problem later.
- Install base and versions. How many active installs, on which app versions, on which OS versions? This is the single most decision-relevant number and it is almost always smaller than the team assumes. We have audited "our mobile app" tiers with a few hundred monthly actives and a five-figure annual maintenance cost implied.
- Whether the build reproduces. Can anyone, today, produce a signed build from a clean checkout on a current machine? Until that is true you have no options at all, only hopes.
- Signing credentials. Who holds the iOS distribution certificate and provisioning profiles, the Play upload/app signing key, and the store account ownership? Lost Android signing keys used to be terminal; Play App Signing makes recovery possible but not painless. This is the one audit item that can independently sink a plan, so check it first.
- The plugin list. Everything in
mobile-config.jsplus thecordova-plugin-*entries in.meteor/cordova-plugins. For each: last release date, whether it still builds against the target SDK, and whether you still use the feature. - Native capability inventory. Which device APIs does the app actually touch — camera, push notifications, biometrics, background location, in-app purchase? Push and IAP are the two that make an exit meaningfully harder; the rest usually have web equivalents now.
- Hot code push posture. Is HCP enabled, and is it actually used? An app that has been silently serving a JS bundle from three years ago to a native shell from five years ago is a configuration worth knowing about.
Hot code push deserves its own paragraph
Hot code push is the best feature of Meteor's Cordova integration and the one that needs the most care. The native container loads your client bundle from the server, so a JavaScript deploy reaches phones without a store review.
Two things to be deliberate about:
- Version skew is now permanent. A device may run any bundle you have ever shipped against any native shell it happens to have. If a JS change starts calling a plugin API that old shells lack, you break those users silently. Feature-detect plugins rather than assuming them, and keep a minimum-native-version check in the client so you can refuse gracefully.
- Store policy has limits. Both stores allow remotely updating interpreted code within the published purpose of the app; what they do not allow is materially changing what the app does without review. Ordinary bug-fix and UI HCP is within long-standing practice. Shipping a whole new product surface through HCP is not a position we would advise defending.
If you keep the Cordova tier, treat HCP as a supported release channel with its own compatibility policy — not as a way to avoid ever touching the native build again. The avoidance is what produces the five-year-old shell.
Meteor 3 and the mobile tier
The Meteor 3 upgrade and the Cordova question interact, and it is worth separating them.
The Fibers-to-async conversion is a server-side change. It does not, by itself, touch your Cordova client code — the client was always async. What does change is the surrounding versions: a newer Meteor release pins newer cordova-ios and cordova-android versions, which is simultaneously the thing that lets you meet current store SDK requirements and the thing most likely to break an abandoned plugin.
So the practical sequencing is: do the server async work first, because it is on the critical path for platform support anyway, and treat the Cordova rebuild as a distinct workstream with its own inventory. Trying to debug a Gradle failure in the same week you are chasing a missing await is how both jobs take twice as long. Verify current Cordova platform support against the Meteor changelog for the release you are targeting rather than trusting a blog post — including this one — because those pins move release to release.
The four honest options
Once you have the audit, the choice is usually clear. We have recommended each of these.
Keep and maintain. The app has real usage, needs native capability, and the plugin list is short and alive. Budget a recurring native-maintenance slot — a few engineer-days a couple of times a year to bump target SDKs, toolchains, and plugins ahead of deadlines. This is cheap when scheduled and expensive when it becomes an emergency. Most teams' actual problem is that this slot was never in anyone's plan.
Keep the shell, modernize inside it. The native container stays as-is, deliberately minimal, while the client inside it gets whatever work the web app is getting. Reasonable when the shell is only there for push notifications and an icon on the home screen.
Retire the mobile app, keep mobile users. If the install base is small and the native capabilities are thin, a good responsive web experience plus a PWA install path covers most of it. This is a real option in 2026 in a way it was not in 2016 — though be clear-eyed that iOS web push and installability still carry caveats, so confirm the specific capabilities you need rather than assuming parity. Retire it properly: ship a final HCP-eligible update that tells users where to go, keep the listing up long enough for that message to land, and do not simply let the app rot into a broken login screen.
Replace the shell. Move the native container to something currently maintained — React Native or Expo, or a thin Capacitor wrapper if you mostly want the existing web client in a modern shell. Capacitor is the lower-effort path and is often the right one, because it preserves the "our web client, in an app" model without the Cordova toolchain. If you are already planning a strangler migration off Meteor, sequence the shell replacement after the web client has moved, not before; doing both at once means debugging two unfamiliar systems through each other.
What we would not do
We would not rewrite a working mobile app natively because the Cordova build is intimidating. And we would not leave it alone, either. The bad outcome is neither keeping nor leaving — it is the app that stays in the store, unbuildable, until a security fix or a store deadline turns a planned afternoon into an unplanned month.
Start with whether the build reproduces and who holds the signing keys. Those two answers determine which of the four options you actually have.