App maintenance and support services for live apps
We look after live iOS and Android apps under a written support agreement. We work in sprints (short, planned blocks of work), with time set aside for security patches, library updates and OS changes. Critical incidents and zero-day patches go first, routine patches arrive every two weeks, and new features get sprints of their own.
What the support covers
Three kinds of steady work keep a live app patched and current.
We fix security flaws in the app's own code in the sprint time set aside for upkeep. Routine fixes go out in the maintenance window every two weeks. A flaw serious enough to be a critical incident, or one that needs a zero-day patch (an urgent fix for a weakness attackers may already know about), goes ahead of the window instead.
The libraries and SDKs (ready-made code packages) inside an app ship security fixes on their maintainers' schedules, not the app's. We move the app onto those fixed versions and keep its list of packages current. This upkeep is known as dependency hygiene.
We keep the app compatible with new iOS and Android versions. That includes each move to the Android version Google Play requires apps to target (its target API level). It also includes phasing out deprecated features, the ones future OS versions will no longer support, as Apple's guideline 2.5.1 asks.
Building a new app rather than looking after one? Start with mobile app development, or go straight to Android, iOS or cross-platform app development.
Why live apps need work
Both stores keep setting conditions after an app ships, whether or not anyone is maintaining it.
Three store rules keep applying after launch. Google and Apple set them, and their timing, not you.
The current Google Play numbers are on our Android app development page. Building an iOS app to Apple's guidelines from the start is covered under iOS app development.
The support terms
Each kind of work is handled on separate terms under the support agreement.
| Work | When it happens | What it means in practice |
|---|---|---|
| Critical incidents | Ahead of all scheduled work | Response time set in your support agreement |
| Zero-day patches | Ahead of all scheduled work | Handled like a critical incident, not held for the next window |
| Routine patching and OS maintenance | Scheduled window every two weeks | Predictable dates to plan releases around |
| Feature development | Separate, scheduled sprint cycles | Never competes with an urgent security fix |
Before support starts
Settle these four points in writing with any provider before a live app moves onto a support agreement. Then they are decided before the app is down, not during.
Write down the store targets, OS versions, libraries and SDKs the app depends on today. Dependency hygiene and platform updates both start from that list, and a gap in it becomes a gap in the patching.
Put in writing which failures and which flaws count as critical. That label decides what goes ahead of the schedule and which response time applies.
Find out which days the maintenance window falls on; it comes every two weeks. Set them against your own release calendar and busy periods, so your team knows when routine patches and OS maintenance will arrive.
Decide who at your company reports a critical incident, and who approves an emergency patch before it ships. Both names belong in the agreement, with a deputy for each.
Where app support stops
Know which agreement a problem belongs to before you compare providers.
Mobile app maintenance and support is engineering work on the app itself: its code, the packages under it and its fit with each new OS and store rule. The scope is bug fixes, security patches, OS compatibility updates and feature development.
For security work beyond the app, such as log monitoring set-up and incident response for retainer clients, see managed security and compliance services and threat detection support.
App support fixes flaws in the app's own code. Finding and ranking flaws across the servers and cloud behind the app is a separate service, vulnerability management.
What app support cannot promise. Apple and Google make their own review decisions, so no provider can promise that an update will pass store review. What a support agreement can settle in advance is the work: the code changes a new store rule calls for, and a set initial response time when something critical breaks in the live app.
FAQ
Response times, patch windows and store review. For anything else, ask us directly.
SecWiz's app maintenance and support covers bug fixes, security patches, OS compatibility updates and feature development for a live iOS or Android app, under a written support agreement. Critical incidents and zero-day patches go ahead of the schedule, with the response time set in that agreement. Routine patching and OS maintenance run in windows every two weeks, and features are built in separate sprint cycles.
The response time is agreed in writing before support starts, together with what counts as critical, rather than set as one number for every app. Critical incidents and zero-day patches go ahead of routine work. The agreed time measures the first response, not the finished fix, because the time a repair takes depends on what broke. Routine patching and OS maintenance run in scheduled windows of their own.
In scheduled maintenance windows every two weeks. Grouping routine patching and OS maintenance into those windows means updates reach the app on dates your team can plan releases around. A zero-day patch or a critical incident does not queue for the next window. It is handled as critical work, ahead of the schedule, instead.
Not under SecWiz's support model. Feature development is managed in separate, scheduled sprint cycles, so it never competes with an urgent security fix for the same slot. A new screen or integration keeps its own schedule, and the sprint time set aside for patching, dependency hygiene and platform updates is not spent on features when a roadmap deadline gets close.
Because the platforms around it keep moving. Apple warns in its App Store Review Guidelines that new kinds of apps can prompt new rules at any time. The maintainers of the libraries inside an app also publish security fixes of their own. A working app can fall behind both without a single line of its code changing.
No. Apple and Google make their own review decisions, and no provider can make those decisions for them or promise how they will go. What a support agreement can settle in advance is the work: the code changes a new store rule calls for, and a set initial response time when something critical breaks in the live app.
Let's talk
Say which stores the app is in, what it is built with and when its last update shipped. We reply within one working day.