What happens to an app without support
A website can run on the same server for years without updates. A mobile app can’t, because it depends on an environment that keeps changing:
- a new iOS or Android release changes how permissions, notifications and background processes work — and some features stop working;
- the app stores raise their build requirements, and an outdated app can’t be updated until it’s brought up to date;
- third-party libraries and services (payments, maps, analytics) drop support for older versions;
- new screen sizes and phone models appear, and the interface starts to break on them.
The longer an app goes without updates, the more it costs to “unfreeze” it: instead of a few small changes, you have to update everything at once.
Who needs ongoing support and who can get by with one-off work
Ongoing support is essential if the app generates revenue or your customers or employees rely on it: a store, a delivery service, a loyalty program, a dealer portal. Any outage here costs you orders and reputation.
A one-time update may be enough if the app plays a supporting role and rarely changes — for example, a reference guide or an event app. In that case, it’s worth checking it once a year against new store requirements and OS versions.
Website support works differently — see our page on website maintenance and support.
Engagement models
- Hourly, on request. Works for stable apps with occasional tasks. The downside: there’s no reserved time, so urgent tasks go into the queue.
- Monthly block of hours. A fixed amount of time for updates, fixes and small improvements. Easy to budget, with predictable response to incidents.
- Support plus development. On top of technical maintenance, we regularly ship new features according to your product roadmap. Best for apps that are actively growing.
We agree on the specific model, scope and response times for your app and put them in the contract.
If another team built your app
Sometimes you need to take over an app from a vendor who no longer works on it. The most important thing at the start is to make sure you have everything you need: the current source code, access to the Apple and Google developer accounts, the Android signing keys, and access to the server and third-party services.
A lost signing key or a developer account registered in the vendor’s name are the worst surprises. They can be resolved, but it takes time. That’s why our first step is always to audit access, and only then do we start on tasks.
How we ship updates without risk
The worst thing that can happen to an app is a release that makes it crash for users at scale. Unlike a website, you can’t quickly “roll back” a mobile version: the fix has to go through store review again. So we release every update carefully:
- first, we distribute the build to your team via TestFlight and Google Play internal testing;
- we test key user flows on several real devices running both older and newer OS versions;
- we use staged rollouts so the new version reaches only a portion of users first;
- we watch crash reports during the first hours after release and halt the rollout if something goes wrong.
For critical changes, such as switching payment providers, we add a mechanism in advance that prompts users to update to the new version.
Technologies we work with
We support native apps built with Swift and Kotlin, as well as cross-platform apps built with Flutter and React Native. For cross-platform projects, we pay special attention to updating the framework itself and its plugins, since that’s where technical debt most often piles up. Learn more about the “one codebase, two platforms” approach on our cross-platform app development page.
We support the backend together with the app: if the backend goes down or slows down, users see the problem in the app.
What we need from you
- Access to your App Store and Google Play developer accounts with admin rights, or the ability to add us to your team.
- Source code or repository access, signing keys and build configuration.
- Access to the server, database and connected services.
- A list of known issues and feature requests, if you have one.
How to measure support quality
Good support shows up mainly as an absence of problems. Look at the crash-free session rate, how quickly critical bugs get fixed, store ratings and reviews, and whether the app is updated for new requirements on time. We include these metrics in our reports so you see results, not just a list of hours.
To keep an eye on the server and uptime, we set up dedicated monitoring so we learn about problems before your users do.
Common mistakes app owners make
- Registering developer accounts in the vendor’s name. If the relationship ends, your app effectively stays in someone else’s hands.
- Letting updates pile up for years. Jumping several framework and library versions at once is more expensive and riskier than regular small steps.
- Ignoring store reviews. Users are often the first to report a crash on a specific phone model, and their complaints are free testing.
- Adding features without checking stability. A new section won’t save an app that crashes at checkout.
What affects the cost
- Code condition: how outdated the libraries are and how much technical debt has built up.
- Platforms: one cross-platform app or two separate native apps.
- Backend: whether it’s included in support and how complex it is.
- Response requirements: how fast incidents need to be handled and whether weekend coverage is needed.
- Development scope: technical maintenance only, or regular new features as well.
FAQ
Can you take over an app that has no documentation? Yes. We write the documentation ourselves during the audit, although any existing docs help us get started faster.
What if the app was removed from the store? We identify the reason from Apple’s or Google’s notice, fix the violation and resubmit the app for review.
Does an app need updates if nothing in it has changed? Yes. Even without new features, it has to be rebuilt for current store requirements and tested on new OS versions.
Can support turn into rebuilding the app? Yes. If the audit shows that maintaining the old code costs more than rewriting part of it, we’ll present both options with their pros and cons.
Why Promodex
Promodex has been around since 2015, and post-launch support is a standard part of our work, not an add-on. Our team of 30+ includes developers, designers and marketers, so alongside technical support we can help refresh your app’s design or promote it. All work is done by our in-house team with no outsourcing, and terms are transparent: you know what’s being done, why, and what it costs.
