Softomate Solutions maintains mobile applications for UK businesses across a range of sectors. In almost every new client conversation we have about maintenance, the same pattern emerges: the business built the app, celebrated the launch, and treated the development budget as the end of the investment. Then, six to eighteen months later, things started going wrong in ways they did not anticipate. This guide explains why ongoing maintenance is not optional for production mobile apps, what it genuinely costs in the UK, and how to plan for it before you find yourself in crisis.
A mobile app is not a website that you can leave unchanged for years. It is software that depends on a runtime environment, iOS or Android, that changes significantly at least once a year and multiple times throughout the year. Your app also depends on the APIs of third-party services, the cloud infrastructure it runs on, the security landscape of the time it was built, and the evolving expectations of users who compare your app to every other app they use daily. Each of these dependencies changes constantly, and your app must keep up.
The most predictable maintenance driver is operating system updates. Apple releases a major iOS update every September, alongside the new iPhone hardware. Google releases major Android updates annually. Both companies release minor updates, known as point releases, three to six times per year. Each update can introduce changes that affect how your app functions: deprecated APIs that your app relied on may be removed, new security requirements may mandate changes to how your app handles data, and new UI conventions may make your app feel outdated by comparison to updated system apps.
Since iOS 14, Apple has introduced a succession of major changes that required app updates regardless of whether the developer added any new features: AppTrackingTransparency for user tracking consent introduced in iOS 14, privacy nutrition labels requiring accurate data disclosure as an ongoing requirement, privacy manifests requiring justification for certain API usage introduced in iOS 17, and account deletion mechanisms required since 2022. Each of these policy changes required app owners to update their apps or face removal from the store. None of them were optional.
Google Play has followed a similar pattern. Android target API level requirements force apps to keep pace with Android development: from 2023, new apps must target Android 13 at API level 33, and updates to existing apps must meet the same requirement. Failing to meet the current target API level means the app cannot be updated via Google Play, which in practice means it becomes unmaintainable. Google also enforces ongoing policy compliance and conducts post-publication scans that can suspend apps found to violate policies introduced after the app was first published.
Beyond OS updates and store policy changes, several technical processes require ongoing attention to keep a production app in good health.
Security patches are a continuous requirement. Mobile apps inherit security vulnerabilities from their dependencies: the third-party libraries, SDKs, and frameworks used during development. A React Native app has npm dependencies; a Flutter app has pub.dev dependencies; a native iOS app has CocoaPods or Swift Package Manager dependencies; a native Android app has Gradle dependencies. Security vulnerabilities in these dependencies are discovered and disclosed on an ongoing basis. Failing to apply security patches leaves your app and its users exposed to known vulnerabilities, which is a breach of your UK GDPR obligations as a data controller.
The Facebook and Meta SDK has been a particularly common source of forced updates for UK apps: multiple privacy-related changes to the SDK required all apps using it for analytics or login to update their integration within defined timescales or face App Store policy violations. Stripe's iOS and Android SDKs require regular updates for PCI compliance. Firebase SDKs require updates for compatibility with new Android and iOS versions. Each of these is a genuine, recurring maintenance event, not a theoretical risk.
Performance degradation is a subtler but real maintenance challenge. As data volumes grow, queries that ran quickly with a small database become slow with a large one. As user numbers grow, backend infrastructure that handled early traffic may require scaling. As device hardware evolves, rendering approaches that were optimised for older hardware may perform poorly on newer devices. Monitoring performance continuously and addressing degradation before it becomes visible to users is the difference between an app that retains users and one that accumulates negative reviews.
Analytics acting on user behaviour data is a maintenance driver that many businesses do not think of as maintenance. Once your app is live with real users, you have data about how they use it: where they drop off, which features they use most and least, how long they spend in each section, and what they search for that returns no results. Acting on this data by improving the UI, removing confusing steps, and adding missing functionality is what keeps engagement high and prevents the slow attrition of users who simply lose interest.
The annual cost of maintaining a production mobile app in the UK market is typically 15 to 25 per cent of the original build cost. For a mobile app that cost ยฃ80,000 to build, the realistic annual maintenance budget is ยฃ12,000 to ยฃ20,000. For an app that cost ยฃ150,000, the annual maintenance budget is ยฃ22,500 to ยฃ37,500. These are minimum figures for competent, proactive maintenance; apps that require significant feature development in addition to routine maintenance will cost more.
Breaking this down by maintenance category helps with budget planning. OS update compatibility, keeping the app working correctly with new versions of iOS and Android, costs approximately ยฃ4,000 to ยฃ10,000 per year for a moderately complex app. This covers the testing and code changes required after each major OS release plus any API deprecation remediation. Store policy compliance updates cost approximately ยฃ2,000 to ยฃ6,000 per year, covering the recurring policy changes that both stores introduce. Security patching, updating dependencies and addressing disclosed vulnerabilities, costs approximately ยฃ2,000 to ยฃ5,000 per year. Bug fixes reported by users or caught by monitoring cost approximately ยฃ3,000 to ยฃ8,000 per year for a typical app. Backend infrastructure costs covering cloud hosting, monitoring services, analytics platforms, and third-party service fees run approximately ยฃ6,000 to ยฃ24,000 per year depending on usage volumes and the services used.
Feature development, improvements driven by user feedback, and new platform capabilities are separate from pure maintenance. Most UK businesses find that they want to invest in new features once the app is live and they understand what users actually need. A separate feature development budget of ยฃ15,000 to ยฃ40,000 per year is realistic for an app that is being actively improved rather than merely maintained.
Our mobile app development service includes a post-launch planning session as part of every project delivery, covering the first twelve months of maintenance requirements and costs before the client's budget cycle begins. Businesses that plan for maintenance from the start of the project are significantly better positioned than those who discover the need after launch.
The consequences of neglecting mobile app maintenance are predictable and escalating. In the first six months after launch, an unmaintained app usually still functions adequately. The first evidence of neglect typically appears in user reviews, which accumulate complaints about minor bugs, slow performance, or features that have stopped working correctly. Ratings decline gradually as dissatisfied users who expected an update are instead met with silence.
Between six and eighteen months, OS update incompatibilities begin to emerge. A new version of iOS or Android changes behaviour in a way your app was not built to handle. A feature that worked on the previous OS version stops working on the new one. Users on new devices encounter crashes or visual glitches that users on older devices do not. Review ratings decline more sharply. Your support inbox fills with reports of the same broken behaviour. The cost of fixing these issues has increased compared to addressing them proactively because the problems have accumulated and the codebase has drifted further from the current environment.
After eighteen to twenty-four months without maintenance, the risk of App Store removal becomes real. Apple and Google enforce minimum target API levels, and apps that have not been updated to meet current requirements cannot be updated by their developers. Apple has a practice of removing apps from public App Store visibility if they have not been updated within a defined period and do not respond to requests to update them. Google Play has similar enforcement against apps failing to meet current target API requirements. Once an app is removed from the stores, reinstating it requires rebuilding it to current standards, which is typically more expensive than the maintenance that would have prevented the removal.
In 2022 and 2023, several UK businesses experienced exactly this sequence. Apps built in 2019 and 2020 that were never updated had their iOS versions removed from the App Store when Apple's policy enforcement caught up with them. Rebuilding these apps from scratch cost those businesses ยฃ40,000 to ยฃ100,000, significantly more than the three to four years of maintenance would have cost. For businesses that use their app as a client-facing service tool for booking, loyalty, or account management, App Store removal immediately removes the app from devices of users who reinstall it and from all potential new users.
A well-structured mobile app support contract protects your interests and sets clear expectations about what your maintenance provider will do, how quickly, and at what cost.
Service Level Agreement defines how quickly the provider will respond to different categories of issue. A typical SLA structure for a UK business app distinguishes between critical issues where the app is down or a core feature is completely broken for all users, high priority issues where a significant feature is broken for some users, medium priority issues where a feature is impaired but users can work around it, and low priority issues covering minor bugs or cosmetic problems. Response times of one to four hours for critical, one business day for high priority, and three to five business days for medium and low priority are standard for a professionally managed support contract. Response time is distinct from resolution time; resolution depends on the complexity of the fix.
Code ownership and access should be explicit. You should retain ownership of all code and access to all repositories and credentials. A maintenance provider who holds your code without giving you independent access has leverage over you that is commercially and legally inappropriate. Ensure the support contract reaffirms the IP assignment from the original development contract.
How updates are handled should be described. Who is responsible for proposing and scheduling OS compatibility updates? Does the maintenance provider monitor Apple and Google announcements and proactively identify required changes? Proactive monitoring is significantly more valuable than reactive support because it catches required changes before they become urgent.
What is included versus what is charged additionally should be completely explicit. A support contract typically includes monitoring, bug fixes up to a defined effort threshold, and OS compatibility updates. Feature development, significant new integrations, and design changes are typically charged additionally. If the boundary between bug fix and feature development is unclear in the contract, it will be disputed in practice.
Termination and handover provisions should specify what happens if you wish to move to a different maintenance provider. You should receive all source code, documentation, credentials, and configuration details in a structured handover. An exit clause that requires reasonable notice and a defined handover process prevents you from being held hostage by your maintenance provider.
Both stores publish compliance deadlines for apps to meet new policy requirements. These deadlines are not optional. Missing them results in the inability to submit updates for target API level requirements, or active removal from the store for substantive policy violations. Tracking these requirements is a specific skill that experienced mobile maintenance providers treat as a core part of their service.
Apple's App Store policy changes are communicated through technical documentation updates, developer news announcements, and direct email to registered developers. The 2023 introduction of privacy manifests required apps to include manifest files declaring the reason for using certain APIs including file timestamp APIs, system boot time APIs, disk space APIs, active keyboard APIs, and user defaults APIs. Apps submitted without these manifests began receiving warnings in 2023 and hard rejections from May 2024. This change affected tens of thousands of apps globally, including many UK business apps whose developers were not monitoring Apple's policy communications.
Google Play's annual target API level requirements are published well in advance, typically eighteen months before the deadline. The 2024 requirement that all new apps and updates target Android 14 at API level 34 was announced in 2023. Apps that missed this deadline cannot submit updates through Google Play, which effectively makes them unmaintainable. Tracking these requirements and planning the necessary code changes well before deadlines is straightforward if someone is responsible for doing it. When no one is responsible, deadlines are missed.
UK businesses operating apps that process personal data also have ICO obligations to consider. The Information Commissioner's Office expects organisations to maintain the security of their data processing operations, which for mobile apps includes applying security patches, keeping dependencies updated, and responding promptly to disclosed vulnerabilities in components the app uses. An app that is not being actively maintained is, from the ICO's perspective, an app whose security cannot be assured. In the event of a data breach involving a long-neglected app, the failure to maintain basic security hygiene would be a significant aggravating factor in any ICO investigation.
A maintenance roadmap transforms reactive fire-fighting into proactive management. A good roadmap for a UK business mobile app covers twelve to eighteen months and includes planned activity across the following categories.
Operating system compatibility planning: identify the dates of the next major iOS and Android releases, typically September for iOS and August to October for Android, allocate a testing and remediation sprint in the month following each release, and budget accordingly. For UK businesses whose apps serve customers on current-generation devices, full compatibility with the current and previous iOS and Android major versions is the standard expectation.
Store policy compliance calendar: subscribe to Apple Developer news and Google Play Policy centre updates. Assign someone in your team or in your maintenance provider to review these updates monthly and flag required actions. Translate compliance deadlines into development tasks with lead times that allow testing before submission.
Dependency audit schedule: review all third-party SDKs and libraries quarterly. Identify known vulnerabilities using tools such as npm audit for React Native projects or pub.dev's security advisories for Flutter projects. Apply patches within a defined SLA based on severity. This is the mobile equivalent of server patch management and should be treated with the same discipline.
User feedback review cadence: review App Store and Google Play reviews weekly. Identify recurring themes in negative reviews. Triage reported issues against your support SLA. Ensure that user-reported bugs enter the development backlog and receive priority proportionate to their severity and frequency. An app with a 3.8 rating on the App Store is losing potential users to competitors with better ratings every day; the cost of fixing the issues driving that rating is almost always lower than the ongoing cost of poor store visibility.
Performance and infrastructure review: review your backend infrastructure monthly for cost efficiency and quarterly for capacity adequacy. Monitor error rates, API response times, and crash rates using tools such as Sentry, Firebase Crashlytics, or Datadog. Set alert thresholds that trigger immediate attention rather than discovering performance problems in user reviews.
A structured maintenance approach transforms mobile app ownership from an unpredictable cost into a planned, manageable investment. Our software development team offers both reactive support and proactive maintenance retainers, and we recommend the latter for any app that is operationally important to the business it serves. Our web application development clients benefit from the same proactive infrastructure monitoring as our mobile clients, with unified dashboards covering all their digital properties.
Mobile app maintenance in the UK typically costs 15 to 25 per cent of the original build cost annually. For an app that cost ยฃ80,000 to build, budget ยฃ12,000 to ยฃ20,000 per year for competent proactive maintenance. This covers OS compatibility updates, store policy compliance, security patching, bug fixes, and backend infrastructure costs. Feature development beyond maintenance is an additional budget item. Businesses that do not budget for maintenance almost always spend more correcting neglect than proactive maintenance would have cost.
Production mobile apps require updates several times per year at minimum. Apple releases a major iOS update annually in September plus three to six point releases. Google releases major Android updates annually plus multiple security and feature updates. Both stores introduce policy changes with compliance deadlines throughout the year. A realistic expectation for a maintained business app is six to twelve updates per year, comprising a mix of OS compatibility releases, security patches, bug fixes, and policy compliance updates. Apps that go more than three to four months without an update are accumulating maintenance debt.
An unmaintained app deteriorates predictably. In the first six to twelve months, minor bugs accumulate and user reviews decline. Between twelve and twenty-four months, OS update incompatibilities emerge: features that worked on previous iOS or Android versions break on new ones. After two years, the risk of App Store removal becomes real: Apple removes apps that have not been updated within defined periods and fail to meet current target API requirements. Google enforces similar minimum target API levels. Rebuilding an app that has been removed from the stores for non-compliance typically costs ยฃ40,000 to ยฃ100,000 for a complex app, far exceeding the maintenance cost that would have prevented it.
A mobile app support SLA should define response time commitments for different issue severities: one to four hours for critical issues where the app is down or a core feature is completely broken, one business day for high-priority issues covering significant feature failures for some users, and three to five business days for medium and low priority issues. It should specify monitoring responsibilities including who tracks App Store and Google Play policy announcements and who monitors backend error rates, what is included in the base retainer versus charged additionally, code ownership and repository access provisions, and termination and handover procedures. An SLA that does not distinguish between issue severities or that is silent on proactive monitoring is not a professional maintenance contract.
Under UK GDPR, data controllers are required to implement appropriate technical measures to protect personal data. For mobile apps, this means applying security patches to address known vulnerabilities in the app's dependencies, keeping server-side infrastructure updated, maintaining access controls, and monitoring for data breaches. An app that is not being maintained cannot be said to have appropriate technical measures in place, because vulnerabilities disclosed after the app was last updated remain unaddressed. The ICO's expectation is that security measures are maintained on an ongoing basis, not just at the point of initial deployment. In the event of a breach involving an unmaintained app, the failure to apply basic security hygiene would be a significant aggravating factor in any regulatory investigation.
More from the blog
Let us help
Talk to our London-based team about how we can build the AI software, automation, or bespoke development tailored to your needs.
Softomate Solutions Limited
Deen Dayal Yadav
Online
