Why apps need ongoing maintenance
A website can sit unchanged for years. A mobile app can't. It runs on operating systems that change every year, it ships through stores that update their rules regularly, and it depends on SDKs that deprecate old versions. Even if you add no features, the app needs work to keep running and to stay listed.
Good mobile app maintenance is mostly predictable work done on a schedule. The goal is that nothing about the next OS release, store deadline or SDK sunset surprises you.
Preventive
OS compatibility work, dependency upgrades, certificate renewals and target API changes, done before they become urgent.
Corrective
Fixing bugs and crashes reported by monitoring, store reviews or your support desk, prioritized by severity.
Adaptive
Responding to outside changes: a payment provider retiring an API version, a new store policy, a backend migration.
Improvement
Small enhancements, performance work and usability fixes based on analytics and user feedback.
The annual OS release cycle
Apple typically previews the next iOS at WWDC in June and releases it in September. Google publishes Android betas through the first half of the year, and in recent years has moved its major release earlier. We plan around both cycles.
- 1
Beta testing
When betas arrive, we install them on test devices, run your app's critical flows and log anything that breaks or behaves differently.
- 2
Impact report
You get a short report: what breaks, what needs updating for new privacy or permission rules, and which new features might be worth adopting.
- 3
Compatibility release
We ship fixes before or shortly after the public OS release so users who update right away are not hit by issues.
- 4
Toolchain and target updates
Apple periodically requires new submissions to be built with a recent Xcode and SDK, and Google Play requires apps to target a recent Android API level by an annual deadline. We schedule these changes so they never block an urgent release.
SDK and dependency upgrades
A typical app pulls in dozens of libraries: analytics, crash reporting, payments, maps, authentication, UI components. Each has its own release schedule and end-of-support dates. Falling several major versions behind turns a routine update into a project.
- We keep an inventory of every dependency, its current version and any known deprecation dates.
- Security patches are applied promptly; major upgrades are batched into planned releases.
- Framework upgrades for Flutter, React Native or Kotlin are scheduled regularly instead of skipped. Our Flutter specialists handle the Dart and plugin side when the app is built on Flutter.
- Unmaintained libraries are flagged, and we propose replacements before they become a blocker.
Crash monitoring and support SLAs
We set up or take over crash and performance monitoring with tools such as Firebase Crashlytics, Sentry or Datadog, plus alerting on spikes in crash rate, API errors or failed payments. Monitoring tells us something is wrong; an SLA defines how quickly we respond.
| Severity | Typical meaning | What the SLA defines |
|---|---|---|
| Critical | App unusable, data loss, payments failing, security issue | Response time, coverage hours (business hours or extended), escalation contacts, hotfix release path |
| High | Key feature broken for many users, no workaround | Response time and target for a fix or workaround |
| Medium | Feature degraded or workaround available | Response time; fix scheduled into the next planned release |
| Low | Cosmetic issues, minor bugs | Logged and prioritized in the backlog |
Actual response times and coverage hours are agreed in your contract and depend on the retainer level. Faster response and wider hours of coverage require more people on standby, so they cost more. We help you pick the level your business really needs rather than defaulting to the highest tier.
Store policy changes and compliance updates
Apple and Google change their requirements regularly, often with fixed deadlines. Recent examples include in-app account deletion for apps that support account creation, Apple's privacy manifests and required-reason API declarations, and Google Play's Data safety form. Missing a deadline can block updates or, in some cases, remove the app from the store.
We monitor policy announcements, tell you which ones affect your app, and make the changes. If your app handles health, financial or children's data, we also review whether a policy change affects the obligations you manage with your legal team.
Performance tuning
Performance tends to degrade quietly as features pile up. We review the metrics that matter most to users and to store rankings:
Startup time
Deferring non-essential SDK initialization and trimming work on the main thread at launch.
Stability
Crash-free sessions and Android ANRs (app not responding), which Google Play Console reports and uses in its quality signals.
Battery and network
Reducing background work, polling and oversized API payloads that drain battery and data plans.
App size
Removing unused assets and libraries, and using platform features such as Android App Bundles to deliver smaller downloads.
Support retainer structures
There is no single right model. The choice depends on how much feature work you expect alongside maintenance.
| Model | How it works | Good fit for |
|---|---|---|
| Essential care | A fixed monthly block of hours for OS updates, dependency upgrades, monitoring and minor fixes | Stable apps with little new feature work |
| Maintenance plus improvements | A larger monthly allocation shared between upkeep and a prioritized backlog of small enhancements | Apps that need steady, incremental change |
| Dedicated support engineer or team | Named engineers allocated to your app, often with an agreed SLA | Business-critical apps or several apps under one contract |
Unused hours, rollover rules and how emergencies outside the retainer are billed should be written into the agreement. Our page on contract and engagement options explains how these models compare. If you need specific platform skills on your side, you can also add an Android engineer to your team instead of a retainer.
Taking over an app from another vendor
Many maintenance engagements start with an app someone else built. A careful handover protects you from losing access or knowledge. We start with a short code and infrastructure audit, then work through this checklist with you and, if possible, the previous vendor.
- Admin access to the Apple Developer and Google Play Console accounts, held by your organization.
- Full source code with history, including any private packages or forks.
- Signing certificates, provisioning profiles, the Android upload key and confirmation of Play App Signing status.
- Backend, cloud, domain and DNS access, plus environment variables and secrets stored securely.
- Third-party accounts: analytics, crash reporting, push notifications, maps, payments.
- Build and release instructions, CI/CD configuration, and a list of known issues.
The audit report covers code quality, test coverage, dependency health, security concerns and a prioritized list of fixes. If it shows the app needs more than maintenance, we will say so and outline options through our modernization service. You can request a takeover audit before signing a longer agreement.