Maintenance & modernization
Mobile app maintenance for live iOS and Android apps
Apps stop working even when nobody touches them. Operating systems change every year, the stores raise their requirements, and SDKs get retired. Comtau takes over existing iOS, Android and cross-platform apps, stabilizes them, keeps them compliant and modernizes them step by step.
Illustrative example - not a client project
Why apps break
Apps age even when nobody changes them
Mobile app support services aren't mainly about bugs in your code. It is about keeping up with a platform that moves on a calendar you don't control.
- 01
Yearly OS releases
Every autumn, new iOS and Android versions change permissions, background rules and UI behaviour. Apps need testing against the betas in summer.
- 02
Store requirements
Google Play raises the target API level every year. Apple adds privacy and SDK requirements. Missing a deadline blocks your next update.
- 03
Retired SDKs and APIs
Payment, push, maps and analytics vendors retire old versions. When they do, features fail quietly for users.
- 04
Expiring credentials
Certificates, push keys and API tokens expire on schedules that are easy to forget until notifications stop arriving.
Monitoring
Finding problems before your reviews do
Maintenance relies on data from the field. We set it up during the audit if it is missing, and every release goes out gradually, as described in how apps reach the stores.
Crash reporting
Crashes grouped by cause, version, device and OS. The most frequent ones go to the top of the queue.
Performance
Startup time, freezes and Android "app not responding" rates tracked per release.
Platform calendar
OS betas, store deadlines, SDK retirements and certificate expiry dates tracked in one place.
Store reviews
Reviews and ratings read alongside crash data. A sudden change after a release often appears there first.
Illustrative values
Maintenance scope
What our mobile app maintenance services cover
A clear boundary keeps mobile application maintenance services predictable. Anything outside it is planned and estimated as a separate piece of work.
Included in maintenance Ongoing
- Testing against new OS versions and betas
- Dependency, SDK and framework updates
- Store compliance: target API, privacy declarations, policy changes
- Crash and performance monitoring, with fixes
- Certificate, key and token renewals
- Regular maintenance releases to both stores
Planned separately Scoped
- New features and redesigns
- Migration to another framework
- Major backend or integration changes
- Support for new device types, such as tablets or watches
Response times and support hours are agreed in the contract, not assumed.
App takeover
Taking over an app another team built
We don't change anything significant until we know what we have. Each step has a concrete result, and you decide on the next one.
Access
Source code, build setup, signing credentials, store accounts, backend and third-party services.
OutcomeAccess checklist, gaps namedAudit
Build the app, review code, dependencies, crash data, store status and security basics.
OutcomeAudit report with prioritiesStabilize
Fix the crashes that matter, unblock store updates, renew what is expiring.
OutcomeA stable, publishable releaseMaintain
A regular rhythm of OS testing, updates, monitoring and releases.
OutcomeMaintenance calendarModernize
Replace the riskiest parts step by step, when and if it pays off.
OutcomeModernization roadmap
Audit results
Every part of the app gets a verdict
The audit ends with a list of decisions you can act on, not a long report. Each part of the app is marked to keep, fix, upgrade or replace, with the reason and a rough size.
- Keep: works and is maintainable as it is.
- Fix: defects or crashes with a known cause.
- Upgrade: outdated but replaceable in place.
- Replace: blocks updates or costs more to keep than to rebuild.
Modernization & migration
Common migration paths
Mobile app modernization services and mobile app migration services usually start from one of these situations. The approach is incremental, and the app stays in the stores throughout.
| From | To | Typical approach |
|---|---|---|
| Xamarin (end of support) | .NET MAUI, native Swift and Kotlin, Flutter or React Native | Assess how much C# logic is worth keeping, then move screen groups behind a stable API. |
| Java and XML views on Android | Kotlin and Jetpack Compose | File-by-file Kotlin conversion; new and changed screens in Compose alongside existing views. See Android. |
| Objective-C and UIKit on iOS | Swift and SwiftUI | Swift for new code with full interoperability; SwiftUI screens introduced feature by feature. See iOS. |
| Older React Native | Current React Native on the New Architecture | Upgrade in steps, replace unmaintained libraries, then enable the new architecture. See React Native. |
| Hybrid WebView app | Native or cross-platform | Rebuild the most-used flows first and keep web content where it still serves well. See cross-platform. |
| Outdated Flutter | Current Flutter and Dart | Version upgrades, null-safety and package replacements, guarded by tests. See Flutter. |
Scroll sideways to see the full table.
Questions
Frequently asked questions
Why did our app suddenly stop working?
Usually because something around it changed, not the app itself. Common causes:
- a new iOS or Android version altered behaviour the app relied on;
- a third-party SDK or API was retired;
- a certificate or key expired;
- the backend changed without the app being updated;
- the store started enforcing a new requirement.
A takeover audit starts by finding which of these it is.
What does mobile app maintenance include?
Ongoing maintenance means keeping the app working, secure and publishable. That covers:
- OS release testing and fixes;
- dependency and SDK updates;
- store policy compliance, including target API levels and privacy declarations;
- crash monitoring and bug fixes;
- certificate renewals;
- regular releases.
New features are planned separately, so maintenance stays predictable. The included and excluded lists above show the split.
Can you take over an app another company built?
Yes, and it is one of the most common starting points. We begin with access: source code, build and signing setup, store accounts, backend and third-party services. Then we audit the app and stabilize it before changing anything significant. If some access can't be recovered, such as signing credentials, we explain the options.
How much does app maintenance cost?
It depends on the app's size, how many platforms and dependencies it has, how far behind it is today and how quickly you need issues handled. An app that is already up to date costs far less to maintain than one that has missed several OS releases. We suggest a scope after the audit, once we know the app's actual state, rather than quoting a flat rate in advance.
Should we rewrite the app or modernize it gradually?
Most of the time, gradually. A rewrite stops feature work and carries the risk of a big switch-over. Incremental modernization replaces the riskiest parts first while the app stays in the stores. A rewrite makes sense when the framework itself is end-of-life, the code can't be built any more, or the product has changed so much that little of the old app still applies.
Xamarin support has ended. What are our options?
Microsoft ended support for Xamarin in May 2024, so Xamarin apps no longer receive updates for new OS and store requirements. The main paths are .NET MAUI, which is closest for C# teams and reuses much of the logic, native Swift and Kotlin, Flutter, or React Native. The right choice depends on your team and how much of the code is worth keeping. The migration table above summarizes the trade-offs.
Have an app that needs a new owner?
Tell us what the app does, what's going wrong and what access you have. We'll suggest how to start: usually with a takeover audit.
- Tell us what the app does and what access you have.
- We don't change anything significant until we know what we have.
- You get an audit report with priorities.