Our app is stable and we have not changed a feature all year. Do we still need to pay for maintenance?

First separate two things: "the features have not changed" and "the environment has not changed." Features can sit untouched for a year, but phone operating systems, store review rules, and the login and payment services you depend on keep moving, and none of them wait until you are ready. The core of maintenance is having someone responsible for checking and adjusting when the environment shifts, not continually adding features. If the budget really is tight, keep at least two things: a compatibility check before every major OS release, and someone who reads and acts on the store's notification emails. Everything else can be commissioned case by case, but do not leave the app with nobody looking after it.

Our original developer has stopped working on the app. Is it hard for a new vendor to take over maintenance?

How hard it is depends on what you are holding. If the source code, the developer accounts, the signing certificates, and the admin accounts for push notifications and analytics are all in the company's name, and there are basic build instructions, a new vendor can usually start maintaining the app after a period of review. The worst case is when accounts sit under the former vendor or an individual, or when the source code is stuck on a development toolchain from years ago, so the new team has to spend time upgrading the project until it even compiles before any change can be discussed. Before the handover, ask the new vendor to audit the code and accounts and assess whether continuing maintenance or partially rewriting makes more sense.

When should we consider taking the app off the store instead of maintaining it?

It deserves a serious look when usage is already low, the core functions can be replaced by the website or another channel, and simply keeping up with OS updates takes considerable effort every year. Retiring an app is not a failure; it puts resources back into channels that work better. It still needs a plan, though: announce it in the app and on your website in advance, offer an alternative channel, decide how user data is kept or deleted, settle refunds and termination for any subscriptions, and keep the accounts and source code in case you need them later. Do not leave the app sitting in the store to decay on its own; that usually does more damage to the brand than retiring it deliberately.

App Maintenance and OS Updates After Launch

Many owners breathe a sigh of relief on launch day, assuming that from here on it is just a matter of adding a feature now and then. A year later, customer service starts hearing “it won’t open on my new phone” and “login just keeps spinning,” or a notice arrives from the store saying the app does not meet a new policy and must be fixed by a deadline or be removed. That is when it becomes clear that app maintenance after launch matters far more than anyone expected beforehand.

The biggest difference between an app and a website is that an app runs on someone else’s platform. Apple and Google release a new operating system every year, adjust their review rules, and retire old development tools, and your app has to move with them. An app nobody looks after does not stay where it is. It breaks a little at a time.

What follows covers what app maintenance actually maintains, how to deal with OS updates and store policy, why SDKs and libraries need upgrading, how to design a forced-update mechanism, what happens when maintenance stops, and what a maintenance contract should cover.

How app maintenance differs from website maintenance

Website maintenance is mostly about the server, the content management system, and plugin updates; for that side, see the Website Maintenance Cost and Contract Guide. App maintenance differs in a few fundamental ways:

Users decide whether to update. When a website changes, everyone sees the new version on refresh. When an app changes, some users always stay on an old version, so the backend has to support several versions at once.
Every release goes through review. Even a small fix has to be resubmitted, the wait is unpredictable, and an urgent fix cannot go live instantly the way it can on a website.
The platform holds the power. When store policy changes, apps that do not comply are blocked from updating or removed, and the owner has no room to negotiate.
Devices and OS versions are extremely fragmented. Android especially has a huge number of combinations of brands, screen sizes, and system versions, and problems often appear only on particular models.

So the point of app maintenance is not “is anything broken?” but keeping the app in step with an environment that never stops moving.

Annual OS updates: keeping compatibility

Both iOS and Android follow a fixed annual rhythm for major versions, and developer betas are released before the official version. That window is when whoever maintains the app should do their homework.

What to do before and after each major version

Run a pass during the beta. Install the current app on the beta OS, walk through the core flows — login, main features, payment, push notifications — and record anything abnormal.
Check for changes to permissions and privacy rules. New versions often tighten how location, camera, photo library, notification, and tracking permissions are requested, so existing code may be blocked by the system or see its prompts appear at a different moment.
Check the interface. New screen sizes, system fonts, dark mode, and gesture areas can all cover a button or cut off text.
Watch crash reports after the official release. Users upgrade gradually, so keep a close eye on error reports in the first few weeks after release.
Decide the minimum supported version. Very old OS versions have few users and are expensive to test. Revisit every year whether to raise the minimum supported version, and tell users in advance.

Development tools have to be upgraded too

Beyond the phone OS itself, the stores periodically require newly submitted apps to be built with newer development tools and a newer target OS version. That means even if you have not changed a single feature, wanting to release a new version can force you to upgrade the entire project’s build environment first. On a project that has not been touched in years, this step often stalls, because old libraries are incompatible with new tools and a whole chain of things has to be upgraded together.

Store policy changes: the most overlooked removal risk

Apple and Google update their store policies from time to time. Common directions include:

More detailed privacy disclosure, such as declaring what data the app collects and why.
Account rules, such as requiring apps that offer sign-up to let users request account deletion inside the app.
Changes to the rules on subscriptions, in-app purchases, and links to external payment.
Additional review requirements for apps aimed at children or dealing with health or finance.
Identity verification and updated contact details for the developer account itself.

These changes are usually announced through notification emails sent to the developer account, with a deadline to comply. The most common disaster is that the account is registered to the inbox of a former employee or a previous vendor, nobody sees the notice, and the company only finds out once the app has been blocked from updating.

Practical advice: register developer accounts with a shared company email address, keep at least two administrators, and assign one person to check the message center in the store console every month. For full pre-launch preparation, go back to the App Store Launch Checklist; the policy and data-declaration items in it need to be revisited regularly during maintenance as well.

Library and SDK upgrades: the invisible dependency chain

Modern apps are almost never written from scratch. They combine many third-party components: login, push notifications, maps, payments, analytics, advertising, crash reporting. Each is an external dependency, and these dependencies will:

Stop supporting old versions. When a provider announces that an old SDK stops working after a certain date, that feature in older app versions simply stops working.
Change along with system rules. When the OS tightens permissions, the SDK needs an update to keep working.
Turn out to have security vulnerabilities. When an old library is found to have a vulnerability, the only fix is to upgrade.
Shut down or be renamed. If a provider merges, changes direction, or ends the service, the app has to switch to another solution.

Upgrading an SDK is not as simple as swapping a part. New versions often change how they are used, so code has to be adjusted and retested. If upgrades are put off for a long time, by the time one is forced you often have to jump several major versions at once, and the engineering work swells noticeably. That “the longer you wait, the more it costs” accumulation is, at heart, technical debt.

Rule of thumb: during maintenance, keep a dependency list showing each third-party component’s purpose, current version, provider, and whose name the account is under. Checking which ones need upgrading around every major OS release is much safer than one big move a year later.

Forced-update mechanisms: build them in before launch

Because users can choose not to update, sooner or later you will reach a point where an old version has to be retired: the backend API changed, the old version has a serious bug, or the old version’s payment SDK has stopped working. If the app has no mechanism for this, all you can do is watch older versions break.

Two common update prompts

Recommended update: a prompt tells the user a new version is available, and they can choose to do it later. Suitable for ordinary feature releases.
Forced update: when the app detects a version below a threshold, the screen shows only “Please update to continue” and links to the store. Suitable for security fixes or when the backend is no longer compatible.

What to watch when designing it

Keep the threshold on the backend. The minimum version number should be returned by the server rather than hard-coded in the app, so it can be changed at any time without another review.
Build it into the very first version. A forced-update mechanism only works on versions that already contain the code. If the first release did not include it, you can never reach those earliest users.
Do not overuse it. Forcing an update for every small release annoys users and drags down ratings. Reserve forced updates for cases where they are genuinely necessary.
Explain the reason in the prompt. “To keep your account secure, please update to the latest version” gets followed more readily than a bare “Please update.”
Keep a compatibility window on the backend. Even when retiring an old version, try to have the backend support both the old and new API for a while to give users a buffer.

The real risks of stopping maintenance

Some owners think, “The app works now, so let’s skip maintenance for the moment.” In the short run you may not notice a difference, but the risk builds up step by step:

New phones or new OS versions start showing problems, customer service receives complaints, and nobody can fix them.
A third-party service stops working, for example login or payment suddenly fails, usually at the least convenient moment.
The store restricts or removes the app. Existing users may still be able to use it, but new users can no longer download it.
Security vulnerabilities go unaddressed. If the app handles personal data or transactions, the consequences go beyond the technical.
Restarting gets more expensive. A project that has been idle too long needs time just to recover its build environment before the first bug can be fixed.

The more hidden cost is to the brand. The store’s review section fills up with “won’t open” and “garbage app” ratings, and even after the problems are fixed, those reviews shape new users’ first impressions for a long time.

What a maintenance contract should cover: an owner’s checklist

An app maintenance contract that only says “maintenance services will be provided” says almost nothing. Use this list to check your existing contract or to discuss terms with a vendor:

Scope: Does it include compatibility checks and fixes for major OS versions? Does it include adjustments required by store policy changes?
SDKs and libraries: Are version upgrades of third-party components part of maintenance, or a separate job?
Response times: How quickly will ordinary issues and urgent issues (such as users being unable to log in or pay) receive a response and a proposed fix?
Release process: Who submits builds for review? If a submission is rejected, who fixes and resubmits it?
Account ownership: Are the developer accounts, signing certificates, and push and analytics accounts in the company’s name?
Source code delivery: After each release, is the source code delivered at the same time or stored in a repository the company can access?
Monitoring and reporting: Is there a crash reporting tool? Who reviews it regularly and reports proactively?
What is out of scope: How are new features and interface redesigns quoted and scheduled?
Termination: When the contract ends, which documents and accounts are included in the handover?

That last point is especially important. The maintenance vendor may change too, and whether the handover goes smoothly depends on whether the account and source code items on this list were actually carried out. For planning and prioritizing new features, see Your Product Roadmap After Launch.

Make maintenance a routine, not firefighting

Good app maintenance should be a calendar with a steady rhythm, not something you call someone about when it breaks:

Monthly: review crash reports and store reviews, and check the store console for messages and policy notices.
Quarterly: review third-party dependencies for end-of-support announcements and decide whether to upgrade.
Around each major OS release: run compatibility checks on the beta, monitor after the official release, and reassess the minimum supported version.
With every release: update the dependency list and make sure the source code and build instructions are updated alongside it.

The benefit is that the maintenance workload becomes predictable, and owners can budget resources ahead of time instead of being chased by one emergency after another.

If your app has been on the store for a while and you are not sure where it stands on compatibility and dependency risk, NETVANA can start with a maintenance review: checking OS compatibility, third-party SDK versions, account ownership, and the forced-update mechanism, then recommending a maintenance scope based on what we find. All software work is quoted after a consultation, so tell us about your app’s current state. What our maintenance and development services include is listed in the software services overview.

Further reading: For the materials and policy declarations to prepare before launch, see the App Store Launch Checklist. For how maintenance on the website side should be contracted, read the Website Maintenance Cost and Contract Guide. To understand why putting off upgrades gets more expensive, see Technical Debt Explained for Business. For prioritizing features after launch, read Your Product Roadmap After Launch. And for handing over accounts and source code when you change maintenance vendors, see Source Code Ownership and Project Handover. As you keep shipping updates, the store page should change along with them; see App Store Optimization (ASO). SDK upgrades are part of security as well; see Mobile App Security Basics.