A delivered app has a limited shelf life. Every year brings a new operating system release, the stores raise their minimum SDK, third-party libraries update underneath you, and the behaviour of external services quietly changes. App maintenance and updates is the service that keeps a product alive — crash monitoring and bug fixing, compatibility work for new Android and iOS versions, incremental feature development and a regular release rhythm. At PBDP we run it with a written service level and clear numbers: what is monitored, how fast we respond, and what you receive in reporting each month.

Why maintenance needs its own budget

Because most of the changes are outside your control. When Google or Apple lifts the minimum target level, your previous binary can no longer be submitted; when a bank or payment provider deprecates an SDK, the money flow in your app stops; when a library is found to be vulnerable, the patch cannot wait for the next planning cycle. Add ordinary software wear: queries that slow down as data grows, screens that break when content changes shape, and support answers written for assumptions from version one. A maintenance plan turns those unavoidable costs from incidents into scheduled work — the same role that website maintenance and support plays on the web side.

What you receive

• Crash and health monitoring: error reporting installed and configured, events grouped, alert thresholds set, and a weekly view of which versions are failing.
• Prioritised bug fixing: three severity levels with defined response and resolution times, from critical outage to cosmetic issue.
• Operating-system compatibility: new Android and iOS target levels, permission changes, display characteristics and background behaviour, applied to your cross-platform codebase or native clients.
• Library and SDK upgrades: replacing deprecated packages, controlling dependency versions, and keeping bank, SMS and map integrations working.
• Feature and content sprints: small capabilities added, funnels corrected and screens redesigned through app UI/UX design.
• Server and panel care: service monitoring, backups, query optimisation and hardening, delivered with server management and optimisation.
• Monthly analytics report: active users, uninstall rate, store rating and consumed effort, with priorities proposed for the next month — backed by continuous technical support and measurement through web analytics and reporting.

The support process, week by week

1. Entry audit: code condition, dependency versions, technical debt and store account access reviewed and handed over as a written report.
2. Service level and channels: response targets, ticket channel, on-call rota and the person on your side who signs off changes are agreed.
3. Monitoring rollout: crash reporting, analytics events and server alerts switched on so we hear about failures before your users do.
4. Triage and prioritisation: every report enters one queue and is classified; critical items are handled immediately, the rest join the two-week sprint.
5. Staged release: the build goes to a percentage of users, and only after the crash rate holds does it roll out fully, submitted through app store publishing and ASO.
6. Monthly review: metrics, spend and the next priorities are walked through in a short session, then the following sprint is committed.

Engagement models and version support policy

Three models work in practice. A guaranteed-hours retainer gives a monthly block of engineering time for fixes and small improvements, which suits products growing steadily. A fixed sprint assigns a defined capacity to the product and ends with a release every two weeks — usually the better choice when rivals are shipping too. An on-call model covers systems that must be available around the clock. In every case the version policy is explicit: which releases are supported, when older ones are retired, and what sits outside scope. Security is part of the package rather than an upsell; each quarter, permissions, certificates and server-side code are re-examined through penetration testing so a single unpatched weakness does not sit in a live product for years.

Frequently asked questions

Another agency built our app — will you still support it?

Yes, with one extra step: an incoming audit. We review project structure, code quality, dependencies and store access, then report which areas create risk for future updates. Where the technical debt is heavy we propose a phased rebuild so the product keeps shipping while it is being stabilised.

How is maintenance cost calculated?

By the number of published channels, the traffic your services carry, the service level you require and the expert hours the product consumes each month. You receive the figure in writing before contracting, and the monthly report shows exactly where each hour went. Automated monitoring is what turns spend from reactive firefighting into planned work.

How far back do you support old versions?

Our default policy covers the two most recent releases unless the data says otherwise. If a significant share of your users is still on older builds, we adjust the policy and design a gradual upgrade path inside the app instead of forcing people to reinstall.

If you operate an app that makes you nervous every time a new OS ships, contact PBDP for a short health and release-risk audit; the products we support are listed in our portfolio.