Year-One Mobile App Maintenance in 2026: Why 15–25% of Build Cost Is the Floor

The Austin cost piece already put a number on the line most boards skip: maintenance and updates consume 15–25% of original development cost every year. On a $50,000 build that is $7,500 to $12,500 in year one before you add a feature, hire a marketer, or touch hosting. That is not a cushion. That is the keep-alive floor — the money required to keep the binary installable, crash-quiet, and legal to upload after the stores move the SDK out from under you.

Operators still hear "maintenance" and picture a backlog of nice-to-haves. That is the wrong ledger. Year-one keep-alive is OS and SDK mandates, plugin and NDK rebuilds, crash response, store metadata, and the person who can still open Xcode when Apple changes the upload gate. Feature work sits above that floor. Confusing the two is how a team spends the retainer on a redesign and then cannot ship a hotfix in October.

This piece is the year-one TCO after launch — not whether an Austin app is the right spend, how long the build takes, Flutter versus React Native versus native, web versus PWA versus store, App Store rejection patterns, or the Play target API 36 clock. Those already exist. The question here is narrower: what does it cost to keep a launched app alive through the first twelve months in 2026, and why the floor does not go to zero because the product is "done."

The 15–25% floor is keep-alive, not a feature backlog

Treat the percentage as a capacity reservation, not a wish list. A $40,000 utility and an $80,000 marketplace do not owe the same dollars. They owe the same shape: someone who can rebuild, resign, upload, and watch Crashlytics when the stores move. The cheap end of the band is a quiet listing with one platform, few plugins, and a founder who can still merge a Gradle bump. The expensive end is two stores, a stale plugin graph, and a team that already staffed the next feature instead of the next SDK.

What the floor buys, and what it does not:

Three-year TCO still doubles the build when you add hosting, services, and launch marketing — the Austin chart already did that math. This article stops at year one after launch. If you cannot name the keep-alive line before you sign the build, you are not buying an app. You are buying a launch party.

Why 2026 does not let you sit still

In a quiet year you could leave a working binary in the catalog and call it done. 2026 is not a quiet year. Apple already closed the upload gate. Play closes the update gate on August 31 and shrinks idle listings that sit too far behind. 16 KB page-size support is a sibling clock on the same NDK graph. Developer identity verification is a third clock that is not a Gradle integer. None of those are feature requests. All of them spend the keep-alive floor.

Budget those as release-train work, not as a Friday bump. The timeline piece already priced honest QA on the way to launch. It did not price the year after the listing goes live. That year is this article.

Apple's upload gate is already live

Apple moved first. Starting April 28, 2026, apps and games uploaded to App Store Connect must be built with the iOS 26 and iPadOS 26 SDK or later — the same floor for tvOS 26, visionOS 26, and watchOS 26. In practice that is an Xcode 26 / iOS 26 SDK pin. Miss it and the package never reaches a reviewer. Existing users can still run last year's binary. You cannot replace it until the toolchain catches up.

That is an upload gate, not a delist. It is the shape most iOS teams already understand, and it is why a "done" app still owes a toolchain sprint in year one. CI that is still on Xcode 16 is not a preference. It is a blocked hotfix. The rejection piece covers what a reviewer does after the binary arrives. This gate is what happens before a reviewer exists.

Price the Apple line as three hours of honesty before you sign a retainer:

• Which Xcode produces the store binary today, and who can bump it.
• Whether the iOS CI image is pinned, or "whatever the Mac has."
• Which native pods or Flutter/RN iOS plugins last documented an iOS 26 SDK build.
• Whether TestFlight still accepts a build from that pin on a real device.

If the shop that built you cannot answer those four, they did not sell you year-one keep-alive. They sold you a launch zip. The hours to find out are cheap. The hours to discover it the week a production crash needs a store binary are not.

Apple will not invoice you for the pin. Your users will, in reviews, the first time iOS 26 changes a permission sheet or a safe-area and you cannot upload. That is why the keep-alive floor exists even when the product owner swore the app was finished in March.

Play's two floors, and the 16 KB sibling

Google's target API requirement is two policies sharing a date. Starting August 31, 2026, new apps and app updates must target Android 16 (API 36) on phone, tablet, foldable, and Android Auto. Wear OS and Android Automotive OS may target API 35. Android TV and Android XR may target API 34. That is the upload floor for the next binary.

The second floor is discovery. Existing apps must target API 35 or higher (phone and Android Auto) to remain available to new users on devices running a newer OS than the app's target. Sit on API 34 or below and Play keeps serving people who already installed you. It stops showing you to everyone else on a newer device. Those are different bills. The Play target API 36 article is the operator checklist for that clock — form factors, the November 1 extension, and what a naive `targetSdkVersion` bump detonates. Do not re-litigate it here. Do put it on the year-one invoice.

Related, and easy to mash into August 31: 16 KB memory page sizes. Google's page-size guide still publishes the November 1, 2025 rule — new apps and updates targeting Android 15 (API 35)+ must support 16 KB pages on 64-bit devices. That upload rule is already live. The Play API 36 piece already separated it from the later February 1, 2027 hard-reject clock for updates that still do not. Do not tell the board they are the same mandate as API 36. Do tell the board that Flutter and React Native cannot hide from it — the engine is NDK. If a plugin is already blocking 16 KB, it is also a year-one risk, because the person who would rebuild it is the same person you need for 36.

A third clock, and a short pointer only: Android developer verification. Starting September 30, 2026, verified-developer registration is required for installs on certified Android devices in Brazil, Indonesia, Singapore, and Thailand, with a 2027 global expansion. That is identity and package-name registration, not a `targetSdk` integer. Do not staff it as a Gradle bump. Do put a calendar reminder on the same year-one sheet as the SDK gates. The dedicated operator write-up of that program is a separate piece; this article will not pretend a paragraph replaces it.

Where year-one money actually goes

On a $50,000 original build, a 20% keep-alive year is $10,000. That is not a round number you drop into a spreadsheet and forget. It is a few concrete sprints. The mix below is illustrative for a two-store production app — not a quote, and not the three-year TCO that already includes hosting and marketing.

Read that against the rest of year-one TCO so you do not double-count. Hosting, third-party APIs, and store revenue share are operating costs. They belong on the Austin three-year chart. They do not replace the keep-alive floor. A $300 Firebase bill does not bump Xcode. A 15% App Store fee does not rebuild a stale `.so`.

The expensive surprise is not the $10,000. It is discovering in week 40 that the mandate sprint is a month because the camera plugin last shipped against API 33. That month was always in the 25% ceiling. You just had not named the plugin. Name it in discovery and the ceiling is a line item. Name it in October and it is a slipped launch of something else — a paywall, a campaign, a board date you already announced.

Two other year-one bills get mistaken for keep-alive and should stay off this line. Monetization plumbing — paywalls, entitlements, store fees — is product work unless the paywall itself cannot upload. Marketing and ASO are acquisition. If you collapse those into "maintenance," you will either starve the SDK gates or you will tell yourself a $40,000 year was the 15% floor. It was not.

Stack choice does not waive the floor

Flutter and React Native do not get a discount on store SDKs. Cross-platform engines are native binaries. Play's target API is a property of the app you upload. Apple's SDK floor is a property of the Xcode that signed it. The stack-cost piece is about when a shared codebase costs more than two native ones. Year-one keep-alive is about whether that graph can still upload after April and August.

A PWA does not dodge this by being "not an app." If year-one distribution is a store listing, you owe the gates. If year-one distribution is a URL, you owe web keep-alive — browser surface, service worker, origin — and you do not get to call it a store binary. Web versus PWA versus store already priced the surface. This article assumes you shipped a listing. The keep-alive floor is the price of keeping that listing honest.

Ask a shop that sold you "write once" four keep-alive questions:

1. Which engine version documents iOS 26 SDK and Android 16 / API 36.
2. Which plugin owns billing, camera, or maps — and when it last shipped a 16 KB-clean `.so`.
3. Who opens the native host when Connect or Play rejects the upload.
4. Whether year-one hours are reserved for that person, or already sold as features.

If they cannot name the plugin, they have not priced the floor. A single codebase can still be the right build. It is never a waiver.

What happens if you skip the retainer

Skipping keep-alive does not freeze the product in amber. It freezes your ability to change it. On Apple, the next crash that needs a store binary waits on Xcode 26. On Play, the next hotfix waits on API 36 — and if you were already below API 35, new users on newer devices already stopped seeing you. Paid UA then buys a store page that says the app is not available on their device. That is not a marketing problem. That is a keep-alive problem you deferred.

The other failure mode is quieter. The binary still installs. iOS 26 or Android 16 changes chrome, back behavior, or a permission prompt. Crash-free sessions fall. Reviews follow. You still cannot upload the fix because the toolchain was the thing you skipped. Rejection patterns are what happen when a reviewer sees a broken or incomplete build. Year-one neglect is how you manufacture that build under time pressure — then pay review twice.

There is a clean version of sitting still: you accept no hotfixes, you are already on the idle Play floor, and you are not buying installs. That is a decision. Write it down. The unclean version is running ads into a listing you cannot patch. That is how keep-alive debt shows up as CAC.

Budget the first year before you ship

Do this in discovery, not in month eleven. The build timeline already told you launch is a phase, not a finish line. Add a keep-alive column to the same sheet.

A shop that quotes a build and waves at "support" without naming Xcode 26, API 36, 16 KB, and who owns the native host is selling a template. Ask which of those clocks they have already run for another listing this year. If they cannot answer, they have not priced year one.

Next steps: price keep-alive with the build

Bring the inventory — original build range, current Xcode and `targetSdk`, plugin list, and whether you plan to sit or ship updates — to the estimate. We will tell you whether year one is a quiet 15% or a dirty 25%, and whether the next mandate is a week of QA or a native-module month.

If the product conversation is still open, start with what the first year actually costs and how long a build takes when the stack is honest. Then put keep-alive on the same sheet as the build. Launch is the starting line. The floor is what keeps the listing from becoming a souvenir.