Quick Answer
App maintenance in Canada typically costs 15 to 25 percent of the original build cost per year, and the floor is not optional. Apple and Google both force code changes on a fixed schedule, so an app with no maintenance budget is an app with an expiry date. The fixed fees are small. The engineering time to stay compliant is the real number.
Summary
- Budget 15 to 25 percent of build cost per year for an app in active use. A simple app with no backend sits at the low end. Anything with accounts, payments or integrations sits at the top.
- Store fees are trivial. Apple’s Developer Program is published at 99 USD per year and Google Play charges a one-time 25 USD registration fee. Verify both before you budget, as published rates change.
- The real cost is forced compliance. Google Play requires apps to target Android 16 (API level 36) by August 31, 2026 for new apps and updates. Apple has required builds made with Xcode 26 and the iOS 26 SDK since April 28, 2026.
- Skipping maintenance does not break your app immediately. It quietly blocks your ability to ship any update, then blocks new installs on current devices.
- Retainers beat hourly for anything revenue-generating, because the expensive failures are the ones nobody was watching for.
Table of Contents
- What does app maintenance actually cover?
- What does app maintenance cost in Canada?
- Why the app stores force you to pay for maintenance
- What happens if you stop paying for maintenance?
- How to budget: retainer, hourly or in-house
- Common mistakes Canadian businesses make
- Frequently asked questions
What does app maintenance actually cover?
App maintenance is four separate jobs that get billed as one line item. Corrective work fixes what broke. Adaptive work keeps the app compatible with new operating systems, devices and third-party services. Preventive work reduces future failure: dependency upgrades, test coverage, monitoring. Perfective work is small improvement, the polish and minor features that keep an app feeling current.
Most disputes between a business and its developer come from assuming maintenance means only the first category. It does not. If you scope a maintenance agreement around bug fixes alone, you have bought the cheapest quarter of the work and left the expensive three quarters unassigned. That gap is where apps quietly die. Before you sign anything, decide what the agreement covers and write it down, the same way you would for a website maintenance plan.
The four categories, with examples
| Category | What it looks like | Typical share of effort |
|---|---|---|
| Corrective | Crash on a specific device, payment failing on retry, login loop | Lowest, and spiky |
| Adaptive | New OS release, SDK deadline, payment provider API version change | Highest and non-negotiable |
| Preventive | Dependency upgrades, certificate renewals, monitoring, backups | Steady, cheap, usually skipped |
| Perfective | Copy changes, new screen, small UX fixes from user feedback | Whatever budget is left |
Adaptive work is the category that makes app maintenance structurally different from website maintenance. A WordPress site that nobody touches for two years still loads. A mobile app that nobody touches for two years cannot be updated at all, because the store will reject the build. This is the single most important thing to understand before you commission a custom app build: the ongoing cost is not a service upsell, it is a condition of staying in the store.
What does app maintenance cost in Canada?
Budget 15 to 25 percent of the original build cost per year. On a build in the low five figures that is a few hundred dollars a month of real engineering attention. On a build in the six figures it is a part-time developer. Published vendor guides quote anything from a few hundred to several thousand dollars a month, which is true and useless, because the number is driven by what your app depends on rather than by its size.
Why the percentage rule misleads
The percentage rule works as a budgeting anchor and fails as an estimate, because two apps built for the same price can carry very different maintenance loads. The variables that actually move the number:
- Number of external dependencies. Every SDK you embed is someone else’s release schedule applied to your app. Analytics, push, crash reporting, payments, maps, auth. Five SDKs is five upgrade paths.
- Whether you run a backend. An app that talks only to the device has no server bill, no database migrations and no uptime obligation. An app with accounts and sync has all three.
- Native versus cross-platform. Two native codebases means two sets of OS deadlines. A single cross-platform codebase halves the compliance surface but adds a framework upgrade path of its own.
- Payments and regulated data. Anything touching card data, health information or personal data under Canadian privacy law carries review and documentation cost that has nothing to do with features.
- How good the original build was. Test coverage, documentation and clean dependency management are maintenance costs paid up front. A cheap build is a loan against the maintenance budget.
The fixed costs, and what they are not
These are the published store and infrastructure fees. They are the smallest part of the bill and the part everyone fixates on. Treat these as published rates and verify them before you commit, since both stores change terms.
| Line item | Published cost | Notes |
|---|---|---|
| Apple Developer Program | 99 USD per year | Recurring. Lapse it and your apps come off the store. |
| Google Play Console | 25 USD one time | Registration only, not annual. |
| Backend hosting | Varies by load | Zero for a device-only app. The dominant infra line once you have accounts. |
| Push, crash reporting, analytics | Often free at small volume | Free tiers end exactly when the app succeeds. |
| Code signing and certificates | Included in the programs | The cost is the renewal you forgot, not the fee. |
Add GST or HST on Canadian-supplied services, and remember that both store fees are billed in US dollars, so the exchange rate is a real line in a Canadian budget. None of this is the expensive part. The expensive part is hours.
A worked example, clearly hypothetical
Take a hypothetical Calgary service business with a booking app on iOS and Android, built cross-platform, with user accounts and card payments. In a year with no new features it still needs: one framework major upgrade, two OS compatibility passes, one payment SDK version bump, certificate and key renewals, and roughly a dozen small fixes reported by users. That is not a feature roadmap. That is the cost of standing still, and it is why “we will just maintain it ourselves later” rarely survives contact with the first SDK deadline.
Why the app stores force you to pay for maintenance
Both stores set a moving floor. You do not choose when to do this work. They do.
Google Play: the target API level deadline
Google Play requires new apps and app updates to target a recent Android version. For mobile phone and tablet apps the requirement moved to Android 15 (API level 35) on August 31, 2025, and moves to Android 16 (API level 36) on August 31, 2026. Wear OS and Android Automotive have their own thresholds on the same 2026 date.
The consequence is specific and often misread. Missing the deadline does not remove your app. It means you can no longer publish updates, and existing apps that target an older level stay available only to devices running an Android version at or below that target. Users who already installed it keep it and can reinstall. New users on current devices stop seeing it. Google has indicated extensions can be requested into November 2026 through Play Console, so check the current policy page rather than relying on a summary.
Apple: the SDK minimum
Apple sets a build-time requirement instead of a runtime one. Since April 28, 2026, apps submitted to the App Store must be built with Xcode 26 or later and an SDK for iOS 26, iPadOS 26, tvOS 26, visionOS 26 or watchOS 26. Separately, from September 9, 2026, iOS and iPadOS apps uploaded to App Store Connect must target iOS 13 or later as a minimum deployment target.
In practice that means your developer’s toolchain has to be current before a single line of your code changes. If your app was last built two Xcode versions ago, the first submission after a long gap is not a quick fix. It is an upgrade project: new Xcode, new SDK, dependency versions that match, and whatever broke in between.
The pattern to plan around
- Annual OS releases. Apple ships a major iOS version each autumn. Android ships a major release each year. Two forced compatibility passes per year is the baseline.
- Store deadlines land in late summer. Google’s target API dates sit at the end of August. Budget the work in Q2, not the week before.
- Deprecations arrive with notice and no mercy. Payment providers, auth providers and map SDKs all sunset versions on their own timelines.
This is the same discipline that keeps a web stack alive, and the reason a recovery plan matters more than a backup. The failure mode is identical: nobody noticed the slow problem until it became an emergency.
What happens if you stop paying for maintenance?
Nothing, for a while. That is exactly what makes it dangerous. The decay runs in a predictable order.
- Months 0 to 6. The app works. Small bugs accumulate. Nobody is alarmed.
- Months 6 to 12. A new OS version ships. Specific screens misbehave on new devices. Reviews start mentioning it.
- Month 12 and on. A store deadline passes. You can no longer publish an update, which means you can no longer fix anything either.
- Beyond. New installs stop on current devices. A third-party SDK sunsets its version and a feature such as payments or push stops working outright.
- The restart. Getting back to a shippable state costs more than the maintenance you skipped, because you are now upgrading several years of dependencies at once with no working build to test against.
If you lapse your Apple Developer Program membership, the consequence is faster: paid membership is what keeps your apps on the store. That is a calendar reminder, not a strategy, and it is the cheapest risk on this entire page to eliminate.
How to budget: retainer, hourly or in-house
Pick based on what the app does for the business, not on what feels cheapest this quarter. If the app takes bookings or payments, downtime has a price and you want someone accountable before something breaks. If the app is a convenience, hourly is defensible.
| Model | Best when | Risk |
|---|---|---|
| Monthly retainer | App generates revenue or handles bookings, payments or customer data | You pay in quiet months, which is the point |
| Hourly or ad hoc | Internal tool, low stakes, no payments, few dependencies | Nobody owns the calendar, so deadlines get missed |
| Prepaid block of hours | Predictable small changes, budget needs to be fixed | Hours get spent on features, compliance gets deferred |
| In-house developer | App is core to the product and the roadmap is continuous | Only viable at a real salary line, and bus-factor of one |
The maintenance agreement checklist
- Does it explicitly include OS compatibility updates and store deadline compliance, or only bug fixes?
- Who holds the Apple and Google developer accounts? These should be in your business’s name, not your agency’s.
- Who holds the signing keys and the Play app signing enrolment?
- What is the response time for a crash that blocks payments, in writing?
- Is monitoring included, or are you the monitoring?
- Does it include a stated number of store submissions per year?
- What happens to the code, the repository and the credentials if you leave?
That last point is the one people learn the hard way. Settle ownership of the code, the accounts and the keys in the original contract, not in the exit conversation. We wrote a full breakdown of who owns the code when you hire an app developer in Canada, and the same logic applies to every credential in the chain.
Common mistakes Canadian businesses make
- Budgeting the build and not the year. The build is a project. The app is an obligation. Price both before you start.
- Letting the agency hold the developer accounts. Convenient on day one, leverage against you on day four hundred. Get your own Apple and Google accounts and add the developer to them.
- Treating the free tier as the price. Push, analytics and crash reporting are free until the app works, then they are a bill.
- Building native twice without a reason. Two codebases doubles the compliance surface. If you are not shipping platform-specific features, you are paying twice for the same deadlines.
- Confusing an app with a website. A large share of businesses that commission an app needed a fast mobile site. Read mobile app versus mobile website before you commit to a decade of store deadlines.
- Deferring the first post-launch release. The longer the gap between your last successful submission and your next one, the more expensive the next one is. Ship something small every quarter just to keep the pipeline proven.
- No single owner. If no named person is responsible for the August store deadline, it will be missed. Put it in a calendar with an owner.
Pros and cons of a maintenance retainer
Pros
- Someone else is tracking the store deadlines, which is the only part of this you cannot do yourself.
- Fixed monthly cost is easier to defend in a budget than an unpredictable emergency invoice.
- Preventive work actually happens, because the hours are already allocated.
- Response times become contractual rather than aspirational.
Cons
- You pay in months where nothing happens, which feels like waste until the month where something does.
- Poorly scoped retainers get consumed by feature requests, leaving compliance undone.
- It can mask a deeper problem: if the app has no users, the right answer is to sunset it, not to maintain it.
Frequently asked questions
How much does it cost to maintain an app per year in Canada?
Plan on 15 to 25 percent of the original build cost annually for an app in active use. A device-only app with no backend and few dependencies sits at the low end. An app with accounts, payments, a server and multiple third-party SDKs sits at or above the top end. Store fees themselves are published at 99 USD per year for Apple and 25 USD one time for Google.
Do I have to update my app every year?
Effectively yes, if you want to keep shipping. Google Play requires new apps and updates to meet a target API level that moves each August, reaching Android 16 (API 36) on August 31, 2026. Apple requires submissions to be built with a current Xcode and SDK, which has meant Xcode 26 and the iOS 26 SDK since April 28, 2026. An app that goes two years without a release is not a maintained app, it is an upgrade project waiting to happen.
What happens to my app if I miss the Google Play deadline?
Your app is not deleted. You lose the ability to publish updates, and the app stays available only to devices running an Android version at or below its target API level. Existing users keep it and can reinstall it. New users on current devices will not be able to install it. Extensions have been available through Play Console in past cycles, so check the current policy.
Is app maintenance cheaper than website maintenance?
No, it is usually more expensive per year, because app maintenance is mandatory on someone else’s schedule. A neglected website keeps serving pages. A neglected app loses the ability to be updated. If you are comparing the two, our breakdown of website maintenance costs in Canada is the right baseline.
Can I maintain the app myself to save money?
You can own the accounts, the monitoring and the release calendar yourself, and you should. The toolchain upgrades, SDK migrations and store submissions need someone who does them regularly. The cheapest realistic split is: you hold the developer accounts and the keys, you own the deadline calendar, and a developer does the quarterly work.
Does a cross-platform app cost less to maintain?
Usually yes, because one codebase faces both stores instead of two. The trade is that you inherit the framework’s own upgrade cycle on top of Apple’s and Google’s. It is a reduction in surface area, not an escape from the deadlines.
When should I sunset an app instead of maintaining it?
When the annual maintenance cost exceeds what the app contributes, and a mobile web experience would serve the same users. Run that comparison honestly once a year. Keeping a dead app alive out of sunk cost is the most common waste in this category.
The bottom line
App maintenance is not a service you can decline. It is the cost of keeping a shippable build, and the deadlines belong to Apple and Google. Price it at 15 to 25 percent of build cost per year, own your developer accounts and signing keys, put the August store deadline in a calendar with a name attached, and ship something small every quarter so the release pipeline never goes cold. Businesses that do those four things never have an emergency. Businesses that skip them pay for the same work later at a premium.
Get a straight answer on what your app will cost to run
We scope the build and the year it lives in, not just the build. If you have an app that has gone quiet, or you are about to commission one and want the ongoing number before you sign, tell us what you are working with. Start with the intake form and we will come back with a scoped maintenance plan and the deadlines that apply to your stack. You can also see how we structure app development engagements.
