Rebuild or Update Your Old App? How to Decide in 2026, and What Each Costs

Whether to rebuild or update an app is the question most businesses with an app more than two years old are facing in 2026. Google Play now requires Android 16 targets, Apple requires Xcode 26, and both have more rules due in early 2027, so an app that sat untouched cannot ship even a bug fix until it is brought up to date. This guide shows how to tell whether an update will do, when a rebuild is cheaper, and what each costs on our published price sheet.

The short answer: update when the foundation is sound

Update your app when its framework and core libraries can still be brought to current versions and the code is in reasonable shape. Rebuild when the framework itself is too old to upgrade, when the update would cost a large share of a new build, or when the app no longer does what the business needs. Most apps fall clearly on one side once someone looks inside them.

The rest of this guide explains why 2026 forced this decision on so many businesses, how to tell which side you are on, and what each path costs on our published price sheet.

Why 2026 forced the question

Both app stores raised their minimums in 2026, and an app that was left alone for 18 months or more now fails at least one of them. We list each rule with its source in our app store deadlines guide. The ones that matter for this decision:

• Google Play, August 31, 2026: new apps and updates must target Android 16 (API 36). Apps targeting Android 14 or lower are hidden from new users on newer Android versions. The extension some teams took ends November 1, 2026.
• Google Play, February 1, 2027: updates to apps with native code that do not support 16 KB memory pages cannot be released.
• Apple, April 28, 2026: uploads must be built with Xcode 26 and the iOS 26 SDK. Since September 9, 2026 they must also target iOS 13 or later.
• Apple, April 2027: uploads must be built with the iOS 27 SDK.
• Texas now, California from January 1, 2027: apps with users there must read and respect app store age signals, as explained in our age verification laws guide.

None of these break an installed app overnight. What they do is stop you from shipping anything new, including a fix for a crash or a security problem, until the app is brought up to date. That is the moment the update or rebuild question arrives, usually at the worst possible time.

What it costs to do nothing

Doing nothing has a cost even though it does not show up on an invoice. The stores' own numbers show what happens to apps that fall behind.

• Fewer new users on Android. An app targeting Android 14 or lower is only available to devices running Android at or below that level. Every new phone sold runs a newer version, so the audience that can install it shrinks each month.
• Removal risk on iOS. Apple removed 72,271 apps from the App Store under guideline 4.0 in 2025, and describes this in its transparency report as "ongoing cleanup for outdated apps". Total removals doubled from 82,509 in 2024 to 166,899 in 2025.
• No way to ship a fix. If a payment provider changes its API or a security issue appears, you cannot release a patch until the build meets current rules. The update you were avoiding becomes urgent, and urgent work costs more.
• Review friction. Apple rejected 23% of submissions in 2025 by our calculation from its transparency report, and performance issues such as crashes were the largest category. An old codebase rebuilt in a new Xcode for the first time in years is a prime candidate. See our app store review statistics.

Signs an update is enough

An update is enough when the gap between your app and current requirements is a version gap, not a design gap. These are the signs we look for in an audit.

• The app was built with a framework that is still maintained, such as current native Swift or Kotlin, React Native or Flutter, and its version can be upgraded step by step.
• The main SDKs (payments, analytics, maps, login, push notifications) still have supported versions.
• The app has a backend that is still running and documented, even loosely.
• There are automated tests, or at least a list of the main flows someone can test by hand.
• You have the source code, the build setup and admin access to both store accounts.
• The features still match what customers use. The analytics show the main flows getting used.

An update in this situation is a sequence: raise the framework and SDK versions, change the target levels, fix what the new Android 16 and iOS 26 behaviours break, test on current devices and submit. Our maintenance team does this routinely.

Signs you need a rebuild

A rebuild is the cheaper option when updating would mean replacing most of the app anyway. These are the signs.

• The framework is several major versions behind, and the upgrade guide for each step involves rewriting navigation, state handling or most screens.
• The app was made with a builder or framework that is no longer maintained, so there is no upgrade path at all.
• Key SDKs have been discontinued, and their replacements work differently enough that the features using them must be redesigned.
• The app has native code that cannot be rebuilt for 16 KB page sizes without replacing libraries nobody maintains.
• The code is undocumented, untested and the original developer is gone, so every change is a guess.
• The business has moved on: half the screens are unused, and the thing customers want is not in the app.

A rebuild is also a chance to fix the decisions that made the old app hard to maintain. That usually means a current cross-platform framework for both stores, a clean backend API and automated tests from the start. Our native vs cross-platform guide covers the choice.

A simple decision scorecard

Score each line from 0 to 2. It is a rough guide, not a formula, but it makes the conversation with a developer much faster.

0 to 4: update. 5 to 8: get an audit, because it could go either way and the answer is in the code. 9 to 12: plan a rebuild, and update only if you need to ship a fix in the meantime.

What each option costs on our price sheet

An update is maintenance work, and a rebuild is priced like a new build. Both use the same price sheet that our app cost calculator runs on. All prices are in CAD.

A one-off catch-up update for an app that has missed a year or more of maintenance is quoted after an audit, because the work depends entirely on how far behind the framework and SDKs are. That is why we do not put a single number on it here.

A worked example, using the sheet rather than any real client: an iOS and Android app that cost $18,000 to build would, at 15 to 20% a year, carry roughly $2,700 to $3,600 a year in maintenance. Skipping two years of that does not save the money. It usually moves it into one larger catch-up job, or into a rebuild if the gap gets too wide.

The rule of thumb we use: if a fixed quote to update comes in at more than about half the price of a rebuild on the same sheet, the rebuild is usually better value, because you end the project with a current codebase instead of an old one that has been patched.

Costs people forget in either path

• The backend. An old app often talks to an old server. If the server needs work too, include it. Our backend team can assess both together.
• Store account ownership. If the developer accounts are in a former contractor's name, transferring the app is a separate task. Sort it first.
• Data migration. A rebuild that keeps existing users must keep their accounts, history and purchases working.
• New store requirements on resubmission. Age rating questions, privacy details, account deletion and age signals all apply the next time you submit, whichever path you take.
• Testing time. Target changes alter behaviour. Budget real testing on current devices, especially tablets and foldables for Android 16.

What a proper audit checks

Before you accept any quote for an update or a rebuild, ask what the developer looked at. A useful audit covers these points and puts the findings in writing.

• Current target API level on Android and the Xcode and SDK version used for the last iOS build
• Framework version and the upgrade path to current
• Every third-party SDK, its version, and whether it is still supported
• Native code and 16 KB page size status
• Crash rate and the top crashes from the store consoles
• Backend hosting, versions and who has access
• Store account ownership, certificates and signing keys
• Store compliance items: privacy details, account deletion, age rating, age signals
• Which features people actually use, from analytics

If a developer quotes without looking at these, the quote is a guess. Our questions to ask an app development company help you tell the difference.

How to move forward this month

1. Open Play Console and App Store Connect and note each app's target level, last release date and any warnings.
2. Confirm you have the source code and admin access to both store accounts.
3. Score the app on the scorecard above.
4. Get a written audit and fixed quotes for both paths if you scored 5 or more.
5. Whichever you choose, put maintenance on a schedule afterwards so 2027's rules are routine releases.

For context on why keeping an app current is worth it at all, our mobile app statistics and is it worth building an app guides set out the numbers.