Mobile App Maintenance Costs: The Annual Line Items and the Store Deadlines Behind Them

Your app's bill after launch is made of three kinds of lines, and each one is estimated differently. There are published fees you can look up in dollars before you pay them, usage-based lines that grow with your user count, and lines you pay nobody for at all. Those last ones are engineering hours that Apple and Google impose on you at dates fixed well in advance. The third kind is what catches app owners off guard, because it never arrives as an invoice. It arrives as an app that quietly stopped reaching new users.

This page breaks down all three. Every figure and every date comes from the page of the company that set it, with the access date, and wherever no figure is published you will find that stated plainly.

Published fees: what you pay Apple and Google

These are the clearest lines in the budget, because the companies publish their prices. Pay them from the company card in the company's name rather than from a developer's personal account, so the account stays yours if the team changes.

Apple's annual line deserves a calendar reminder more than anything else on this page, because the penalty for forgetting it is heavier than most people expect. Apple states plainly that when an Apple Developer Program membership expires your apps are no longer available for download, you cannot submit new apps or updates, and you lose access to Certificates, Identifiers and Profiles, while the apps keep working for anyone who already installed them. Recovery is possible: renew after expiry and free apps become downloadable again within 24 hours, paid apps once you accept the Paid Applications Agreement again, with no resubmission. An expired Enterprise membership stops downloads and leaves the software running for only 90 days for those who already have it, as long as the certificates and provisioning profiles stay valid that long.

The administrative translation: tie the renewal to a company card and to two people who know the date, not to an employee account that may leave before it arrives.

There is also a full waiver of Apple's fee that few people know about. Apple grants it to nonprofit organizations, accredited educational institutions and government entities, on conditions: you have to be a legal entity, not an individual or a one-person business, and none of your apps may be selling digital goods or subscriptions. The waiver is not permanent either. The account holder confirms continued eligibility at every annual renewal, and the fee returns if eligibility lapses. A nonprofit in Egypt or Jordan running a donations app should put this question to its accountant before paying.

The dates that pull your app off the store if you ignore them

This is where a "working" app and a maintained one part ways. Maintenance is not a commercial decision you defer to next year, because both stores enforce a minimum that ratchets upward annually, and anything that does not move with it drops out of distribution quietly, without a direct warning reaching the business owner.

Read the second row again, because it is the sly one. Your app is not deleted, and it keeps running for everyone who already installed it. What happens is that it becomes unavailable to new users on devices running a newer version of Android than your app's target level. Installs decline gradually while your dashboard shows no fault at all, and the app opens perfectly well on your own phone. Apps targeting API level 34 or lower only appear on devices running a version equal to or older than the level they target.

The only exception Google lists is permanently private apps, restricted to the users of one organization for internal distribution. An in-house warehouse app never published to the store is out of scope; an ordering app your customers use is fully in scope.

On Apple's side, the Xcode 26 requirement carries a consequence that never shows up on an invoice: Xcode 26 requires macOS Sequoia 15.6 at minimum. If the Mac your team builds on is too old to run that release, the real line in your budget is not developer hours but a machine or a cloud build subscription.

These deadlines repeat every year on the same logic at a higher level. Treat them as a fixed entry in your operating calendar, not as an emergency.

What "raising the target level" actually costs

Changing a number in a config file takes a minute. What takes weeks is that the app behaves differently once the number changes. The Android 16 behavior changes documentation lists what applies exclusively to apps targeting API level 36, and four of those items translate directly into testing and rework hours:

• Edge-to-edge display became mandatory. The attribute that used to opt out of it is deprecated and disabled, which means reviewing every screen where a button or field can hide behind a system bar.
• Back navigation changed. `onBackPressed` is no longer called and the old back key event is no longer dispatched, so any screen that intercepts back to ask "leave without saving?" needs rewriting or an explicit opt-out in the manifest.
• The `elegantTextHeight` attribute is deprecated, and Google's documentation explicitly says to adjust layouts so text renders consistently in Arabic and several other scripts. This one concerns you more than most if your interface is entirely Arabic: line height can shift, breaking cards and buttons that were built to the old measurements.
• Orientation and resizability restrictions are now ignored on large screens, so an app that used to force portrait will open in landscape on a tablet or a foldable.

Those are four lines in a documentation page, and dozens of screens on your side that need to be opened and tested one at a time. This is where the annual maintenance hours come from, not from fixing bugs that users report.

The lines billed by usage

These grow with how much the app is used rather than with the passage of time, so estimate them from expected transaction volume rather than a flat monthly figure.

Hosting and backups. Providers publish their prices. DigitalOcean bundled Droplet plans start at 4 USD per month, and the line people forget is backups: the provider prices them at 20% of the Droplet cost for weekly and 30% for daily. A 24 USD server with daily backups is a 31.2 USD server. Before you pick a provider, check whether your contract or your sector requires hosting inside your own country. That is an architectural decision that is hard to reverse, and we covered it in our guide to app development costs in Saudi Arabia.

Notifications and crash monitoring. Many people assume these carry a bill, and they do not. Google's Firebase pricing page lists Cloud Messaging and Crashlytics at no cost on both plans. Strike them from your estimate rather than paying for an anxiety with no basis.

Maps. This one changed materially. Since 1 March 2025, Google replaced the single 200 USD recurring monthly credit with a free monthly usage cap per individual service, and the cap varies by tier. Geocoding, for instance, sits in the Essentials tier with 10,000 free requests a month. If your budget was built on the old credit, your arithmetic is a year and a half out of date.

Verification messages. Here a real difference between Arab markets deserves an explicit budget line. Twilio publishes the outbound message price to Egypt at 0.3959 USD per segment and to Saudi Arabia at 0.1949 USD. The same verification message costs roughly twice as much in Egypt as in Saudi Arabia. If your app sends a code at every sign-in for ten thousand users a month, the gap between a design that asks for the code once and one that asks every session is a budget line the size of a salary.

TLS certificates. The certificate itself is available free from well-known issuers, but its lifetime is shrinking. The CA/Browser Forum requirements cut the maximum validity of a subscriber certificate to 200 days from 15 March 2026, then 100 days from 15 March 2027, then 47 days from 15 March 2029. Renewing by hand once a year was workable; renewing by hand eight times a year is not. The line here is not the price of the certificate but the hours to set up automated renewal once, which is far cheaper than an outage on the day a forgotten certificate expires.

Obligations with no fee attached, and real hours behind them

Nobody invoices you for these, but each one entered policy on a known date, and each one means work on an app that is already live:

• Account deletion. Apple has required since 30 June 2022 that any app supporting account creation also let users delete the account from inside it. Google requires deletion to be available both in-app and through an external web resource whose link goes into Play Console, and states plainly that freezing an account does not count as deletion. The work here is an interface, a real deletion path in the database and a page on your website.
• The Data safety form and the privacy policy. The form is mandatory for every published app, including those on testing tracks, and an inaccurate description risks blocked updates or removal from the store. The practical trap is that the form also describes what third-party libraries collect, so adding a new analytics tool in an ordinary update can make the form inaccurate without anyone noticing.
• Approved reasons for certain APIs on Apple's side. Since 1 May 2024 you must declare approved reasons for a listed set of APIs used by your code or by the third-party SDKs you depend on, or the upload is rejected.
• Store forms that became recurring. A recent example: Apple asked developers to answer the new age rating questions by 31 January 2026 to avoid an interruption when submitting updates. Filling in store metadata stopped being a one-off launch task.

Set aside hours each year to review these forms, because any one of them is enough on its own to block an urgent update on the day you need it.

What changes when your app serves more than one country

An app serving Cairo alone and an app serving Cairo, Riyadh and Dubai are not the same maintenance line, and the difference is not only translation:

Compliance in particular is the line that turns from a legal footnote into engineering hours. If your app issues tax invoices in Saudi Arabia you are inside the Fatoora integration regime, and we explained what changes inside the system itself in phase two of e-invoicing; Egypt has its own separate system, covered in connecting your system to Egyptian e-invoicing.

There is also a date that concerns anyone distributing an APK directly to customers, a common practice in our markets. Google starts on 30 September 2026 requiring that an app be registered by a developer whose identity it has verified before that app can be installed from a participating store onto a certified device in Brazil, Indonesia, Singapore or Thailand, and says it will expand this globally in 2027. Apps from developers who have not completed verification and registration will not be available for new installation in the countries covered. The Arab region is not in the first phase, but the global expansion is announced, and verification needs company documents that take time, so start it before it becomes urgent.

The line with no published price: the maintenance team

Everything above has an official page behind it. The team's fee does not, and we will not invent one.

First, a note on a figure you will meet on the first page of search results: that annual maintenance amounts to 15% to 20% of the app's build cost. We went looking for the origin of that number and found it circulating between company blogs that attribute it to research houses without a link to any published report you can open and verify. We will not use it as the basis of a budget. A percentage of an old number tells you nothing about your app; the count of your external integrations, the number of platforms you support and the size of your user base tell you a great deal.

The factors that actually move this line:

• The number of external integrations. Every payment gateway, shipping service and accounting link is another party that changes its interface on its own schedule, and you follow.
• The number of codebases. A single build running on both platforms means applying a fix once rather than twice, unlike two separate native codebases; we compared the options in Flutter versus React Native.
• The response time you require. A team that replies within a business day and a team that replies within two hours around the week are two entirely different lines.
• Usage volume. An app with a hundred users and one with a hundred thousand share the same code and do not share the same monitoring load.

Instead of asking "how much is maintenance?", ask for a contract that answers five questions. What counts as a bug fix inside the agreement and what counts as a new development request? What response time is committed to, and during which hours? Is the annual target level upgrade inside the agreement, or priced separately each year? Who owns the store accounts and the server? And how many hours a month are included, and what happens to unused ones? The answers separate two offers that look identical on price.

The budget worksheet

Copy this table and fill it from your own quotes and invoices. The empty columns matter most, because they expose the lines nobody knows who pays.

If a maintenance quote leaves "annual target level upgrade" blank or marks it "case by case", ask about it before you sign. That is the line with a date on it, and it comes around every year whether you add features or not.

If you have a live app and want to know where it stands against these dates before you build next year's budget, Snaabble's mobile app development services usually start by reviewing the existing code and your two store accounts, and a line-item table like the one above comes out of it with your own numbers in it.

Frequently asked questions

What is the budget difference between the Apple Developer Program and the Apple Developer Enterprise Program?

The first costs 99 USD a year and is what you need to publish on the App Store. The second costs 299 USD per membership year and exists for internal distribution to your own employees, not for public release. The difference also shows at expiry: when an Enterprise membership lapses, downloads stop and the software keeps running for only 90 days for people who already have it, as long as the certificates and provisioning profiles stay valid.

Is a personal Google Play developer account enough for a commercial app?

Technically yes, but Google requires personal accounts created after 13 November 2023 to meet specific testing requirements before the app can go live on the store, plus proof of access to an Android device. Registering as an organization skips those steps and keeps ownership of the account with the company rather than with one person.

Do developer account fees include the store's commission on sales?

No. The account fee is a flat administrative line with nothing to do with sales. The store commission is taken only from digital purchases and subscriptions made inside the app, and it has its own rates and conditions. Anything delivered outside the app, such as a meal, a shipment or an appointment, is paid through an ordinary payment gateway and the stores take nothing from it. We broke those rates down in our guide to app development costs in Saudi Arabia.

Sources

All pages below were accessed on 21 September 2026.

• Google: Meet Google Play's target API level requirement
• Google: Behavior changes: apps targeting Android 16 or higher
• Apple: Upcoming Requirements
• Apple: SDKs and system requirements
• Apple: Apple Developer Program fee waiver
• Apple: Apple Developer Enterprise Program
• Apple: Offering account deletion in your app
• Google: Get started with Play Console
• Google: Understanding Android developer verification
• Google: Google Play User Data policy
• Google: Provide information for Google Play's Data safety section
• Google: Firebase pricing
• Google: Google Maps Platform March 2025 changes
• Twilio: SMS pricing for Egypt and for Saudi Arabia
• DigitalOcean: Droplets pricing
• CA/Browser Forum: TLS Baseline Requirements