What is included in the monthly retainer?

A block of engineering hours spent on the health of the app: OS release testing, dependency and SDK updates, target API levels, store policy changes, crash and error monitoring, small feature and copy changes, and release management. We agree the priorities for each month with you and report the hours used.

What is billed separately from the retainer?

New feature areas, redesigns, framework migrations, security audits, backend infrastructure work, and rescue of an app that was already failing before the retainer began. Those are quoted as their own piece of work so the retainer stays focused on keeping the shipped app healthy.

How fast do you respond when the app breaks in production?

We agree a response window per severity before the retainer starts. Something that stops the app launching or breaks a payment path is acknowledged within two business hours, and a store rejection is picked up the same working day. Fix time depends on the cause, and a fix that needs a new store build also waits on Apple's or Google's review.

Can you maintain an app another team built?

Usually yes. We start with an access and code review, then run the app to see what it does. If there is no source access, no working build path, or a framework nobody maintains any more, we say so before you commit to a monthly fee.

Do we need a retainer if the app rarely changes?

Sometimes a smaller block of hours suits better, and we will offer that instead. Apple and Google still move every year, so an app that never changes still needs somebody to keep it installable and reviewable. A simple single-platform app with stable dependencies needs far less than one with payments, push, and analytics.

Mobile App Maintenance & Support

Ongoing mobile app support: OS release work, dependency and SDK updates, store compatibility, crash monitoring, and small feature changes.

See our work:

Voice VPN - Fast VPN. Vasilkoff Ltd in-house project→Easy VPN Free→Camera Filters→

An app that passed review last year is not the app the stores accept this year. Apple releases a new iOS version each autumn, Google raises the Play Store target API level every year, and the libraries under your build change on their own timelines. It appears later, as a rejected upload, a crash on the newest iPhone, or a sign-in that fails because a provider changed an endpoint.

Support moves that work onto a calendar. We hold the codebase, ours or one we took over, and spend an agreed block of engineering time each month keeping the app installable, reviewable, and fixable.

The yearly platform rhythm

Mobile support follows a calendar you do not control. iOS ships a major version most Septembers, followed by point releases that break things the beta never showed. Google publishes a new Android API level each year and ties Play Store submissions to a target level, so an app that ignores the deadline stops being publishable. Permission prompts, background execution limits, and battery rules change in between.

Third-party software adds its own noise. A networking library, an analytics SDK, and a payment provider each move on separate schedules, and any one can require changes in your code to stay supported. Vendors also retire SDK versions, so when a provider drops its older iOS SDK you move on their schedule.

That rhythm is why we plan platform work into the months where it lands rather than treating support as a task list.

What a retainer covers

The monthly block pays for work on the app you already ship:

OS release work: testing against the beta, building with the current SDK, and fixing what the new version breaks.
Dependency and SDK updates, including version pins and the calling-code changes each upgrade needs.
Store compatibility: target API levels, privacy declarations, permission justification, and the review questions a policy change brings.
Crash and error monitoring: we read the crash queue and server logs, group what affects users, and fix it.
Release management: builds, version numbering, store submission, staged rollout, and release notes.

Small feature and content changes fit inside the same block. We agree priorities monthly and report the hours used.

Who this fits

A retainer suits an app that people use and that earns money or carries risk: subscription products, booking and delivery apps, and internal tools a field team depends on. It fits teams with no mobile engineer on staff, and product owners who want platform work handled without hiring for it. For a one-off experiment with no users, we will suggest a block of hours rather than a monthly fee.

Where the project starts

We take support work from three states, and the first month looks different in each.

A plain idea means the app has not been built yet. Support becomes a planning decision: we choose dependencies that are actively maintained, set SDK targets with the yearly calendar in mind, and install crash reporting before the first release.

An existing conventional codebase is a working app built with normal practices, by your team or another agency. We review access and code, run the app, agree what we can support, and clear the update backlog already in place.

An AI or vibe-coded prototype is an app assembled quickly with AI coding tools where nobody tracked SDK versions, dependency pins, or store requirements. The product idea is worth keeping, so we inventory the codebase and run a stabilization pass as the first month.

How the engagement runs

We begin with an access and code review, since scope depends on how far behind the app has drifted. The first month clears the backlog: pending updates, store requirements already in force, and monitoring gaps. After that the work settles into a monthly cycle where you send priorities, we plan them into the block, and we report the hours used. Production problems interrupt the plan, which is what the response window is for, and we adjust the block size when the quarterly numbers say it is wrong.

Response times, and what we promise

Response time and fix time are separate commitments. We agree a window per severity before the retainer begins:

App fails to launch, or a payment or login path is broken: acknowledged within two business hours.
Store rejection, or a broken flow affecting part of your users: acknowledged the same working day.
Cosmetic items: scheduled into the monthly block in priority order.

Fix time depends on the cause. A configuration or backend fix can be quick, while anything needing a new binary waits on store review. Overnight alerts are triaged when someone is on shift, and we say whether round-the-clock cover can be staffed.

What is billed separately

The retainer keeps a shipped app healthy. Work that changes what the app is belongs in its own project:

New feature areas and screen sets, scoped and quoted separately.
Platform migrations, such as moving a large app to a current framework, handled under mobile SDK and API version upgrades.
Security audits and hardening, backend changes, and new services or database work.
Rescue of an app that was already unstable when the retainer started.

What a retainer does not cover

An unsupported app stays expensive under any arrangement. When a framework nobody maintains is the root cause, the monthly block keeps absorbing emergencies, and we will say when a rebuild costs less.

The monthly block is finite, and monitoring catches what ships rather than every crash, because devices and networks misbehave on their own. Cover outside working hours, and any commitment to a fixed fix time, must be agreed and staffed in advance. Store review outcomes depend on policy compliance rather than on our wishes.

What it costs

Retainer work runs at our flat rate of $39 per hour. The monthly block is sized to the app: the number of platforms, the integrations in the build, and how much your roadmap changes it.

A single-platform app with stable dependencies and no payments usually needs a few hours a month, plus whatever the autumn OS release adds. An app on both stores with payments, push notifications, and analytics needs noticeably more, and a first month clearing a backlog is a short project measured in weeks. The pricing page sets out the hourly rate and the monthly capacity plans from $2,699 for teams that need sustained engineering across a product line.

If the review shows the app should be rebuilt instead, the effort lands near the mobile MVP typical order of $4,800 to $8,500 across four to six weeks, and we will say so rather than patch a failing foundation.

Proof

Voice VPN is our own Flutter VPN with native integrations for Android Services and iOS NetworkExtension. Background execution, network entitlements, and permission rules move with each OS release on both platforms, so this project runs the maintenance rhythm this page describes on a live product.

Easy VPN Free is an open source Android VPN built on OpenVPN and the VPN Gate network, published in 2017 and later retired as modern deep packet inspection made its transport ineffective. It proves we will tell a client when maintenance has stopped being the right spend.

Camera Filters is a native iOS photo editor with real-time filter previews. Camera and photo library access is the most tightly reviewed permission area on iOS and changes wording almost every cycle, which is the screen-level work a retainer covers.

Related services

Mobile apps development for new builds in iOS, Android, and Flutter
Mobile SDK and API version upgrades when a target SDK change or a stale dependency tree needs its own project
Mobile app bug fixing and performance for crash, launch time, and battery work beyond the monthly block
App analytics and crash reporting to set up the monitoring this retainer depends on
API development and integration when an app depends on a backend contract that also needs upkeep

Next step

Send us the app, the stores it is live on, and how often it changes. We will say what state it is in and what the first month would involve.

Contact us with the app details, or run the maintenance situation through the Vasilkoff.info estimator for an initial scope and cost range.