Manu Shukla

Posted on Jul 20 • Originally published at ecorpit.com

Legacy mobile app rewrite or refactor: a 5-test framework for the 2026 store deadlines

#mobiledevelopment

Legacy mobile app rewrite or refactor: a 5-test framework for the 2026 store deadlines

Summary. Two store deadlines are forcing decisions on aging mobile apps this year. Since 28 April 2026, Apple requires that apps uploaded to App Store Connect are built with Xcode 26 or later using an SDK for iOS 26, iPadOS 26, tvOS 26, visionOS 26 or watchOS 26. Google Play requires existing apps to target Android 15, API level 35, or higher by 31 August 2026, with an extension available to 1 November 2026 on request. Neither of these is a reason to rewrite your app, and treating them as one is how a 6-week compliance task becomes an 18-month rebuild. In April 2000, Joel Spolsky called rewriting from scratch "the single worst strategic mistake that any software company can make" after Netscape shipped no version 5.0 and left almost 3 years between major releases. That essay is 26 years old and predates mobile entirely, so it needs testing rather than quoting. Below are 5 tests that decide the question, and the cases where a rewrite genuinely is the cheaper path. Baseline costs are small next to the engineering: the Apple Developer Program is $99 per year and Google Play's service fee runs between 11% and 30% depending on programme and revenue.

The deadline is the trigger, not the reason. Separate those two and the decision gets much easier.

What is actually forcing your hand in 2026

Most teams discover the pressure through a rejected build rather than a roadmap. Here is what the platform owners have published.

Requirement	Platform	Status as published
Xcode 26 or later, with an iOS 26, iPadOS 26, tvOS 26, visionOS 26 or watchOS 26 SDK	Apple	In force since 28 April 2026 for uploads to App Store Connect
Target API level 35 (Android 15) or higher for existing apps	Google Play	Deadline 31 August 2026, extension to 1 November 2026 available on request
Approved reasons declared for required-reason APIs, including those used by third-party SDKs	Apple	In force since 1 May 2024
Age rating responses under the updated system	Apple	Ratings auto-updated; responses were due by 31 January 2026 to avoid submission interruption
Digital Services Act trader status for EU distribution	Apple	In force since 17 February 2025; apps without verified trader status are removed from the EU App Store

Two things stand out. First, none of these requires new product functionality. They are toolchain, manifest and metadata obligations. Second, the required-reason API rule reaches into your dependencies, which is where old apps actually break: an abandoned analytics SDK from 2021 that nobody has permission to update is a harder problem than the SDK floor itself.

That distinction is the whole decision. A build-system obligation is refactor work. A dependency you cannot update, in a codebase nobody understands, is a different conversation.

The Spolsky argument, and where it stops applying

Spolsky's case against rewrites rests on a claim about knowledge, not code. "When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work." His explanation for why teams misjudge this is the sharpest line in the essay: "It's harder to read code than to write it." Engineers read unfamiliar code, find it incomprehensible, and conclude it is bad.

He also separates three complaints teams make about legacy code and shows each has a targeted fix. Architectural problems get solved "one at a time, by carefully moving code, refactoring, changing interfaces". Inefficiency "only affects a small part of the project, which you can optimize or even rewrite". Ugly code is a formatting pass. And the warning that lands hardest with anyone who has scoped a rebuild: "It's important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time."

Joel Spolsky, co-founder of Fog Creek Software and CEO of Stack Overflow from 2010 to 2019, wrote that in April 2000 about desktop software with no app stores, no platform-mandated SDK floors, and no OS vendor able to stop you shipping. Mobile changed three of the assumptions:

A third party sets your deadlines. Netscape chose to take three years. An app that cannot build against the current SDK is removed from distribution on a date it does not control.
The platform surface moves underneath you. Desktop APIs from 2000 largely still work. A mobile app that skipped four OS cycles is carrying deprecated APIs, an obsolete lifecycle model and dependencies whose maintainers have moved on.
The cost of parallel maintenance is higher. Spolsky's advice assumes you keep shipping the old code while improving it. On mobile you are shipping the old code to two stores with independent review processes and independent deadlines.

The conclusion still holds more often than not. It just needs testing against the specifics rather than being applied as a rule.

The five tests

Run all five before deciding. A rewrite needs several of them to point the same way, not one.

Test 1: can you build it today? Check out the repository on a clean machine and produce a signed build with the current toolchain. If that takes more than a day, the problem is your build and dependency graph, not your architecture. Teams routinely misread a broken build as a broken codebase. Fix the build first, then re-ask the question, because the answer often changes.

Test 2: how many of your dependencies are unmaintained? Count the third-party SDKs with no release in 24 months, and separately count those that touch a required-reason API or handle personal data. A short list is a replacement project. A long list, particularly in an app whose native layer is tangled with those SDKs, is one of the genuine rewrite signals.

Test 3: does anyone still understand the revenue path? Identify the code handling sign-in, payment and whatever your core transaction is. If a current team member can explain that path end to end, Spolsky's knowledge argument applies with full force and you should refactor. If nobody can, you are not preserving knowledge by keeping the code, because the knowledge is already gone.

Test 4: what is the change failure rate? Look at the last 12 months of releases. Count how many shipped a regression that needed a hotfix. A codebase where routine changes are safe is not the thing blocking you. A codebase where every change breaks something unrelated is telling you the coupling is real, and that is expensive to refactor incrementally.

Test 5: is the platform requirement structural or superficial? Adopting a new SDK, declaring API reasons and raising a target API level are superficial in the precise sense that they do not change your app's structure. A mandated lifecycle change touches every screen's assumptions about windows and state restoration, which is structural. Superficial obligations never justify a rewrite. Structural ones justify examining the option.

Rewrite, refactor, or strangle

There is a third option that most rewrite-versus-refactor framings omit, and it is usually the right one for a revenue-carrying app.

Approach	When it fits	Main risk
Targeted refactor	Build works, dependencies are current, team understands the core paths, requirement is superficial	Underestimating dependency work hidden behind a clean build
Incremental replacement	Coupling is real but revenue paths are understood; new screens built in the new stack behind the existing shell	Two stacks in one binary for longer than planned, with duplicated state
Full rewrite	Multiple unmaintained dependencies, no institutional knowledge of core paths, high change failure rate, structural platform change	Shipping nothing for the duration while the old app still needs store-deadline maintenance
Do nothing	Genuinely nothing; the deadlines are dated and enforced	Removal from distribution

Incremental replacement is the option that respects Spolsky's argument while acknowledging that mobile deadlines are external. You keep shipping, you keep the tested code paths that work, and you move one surface at a time. The cost is discipline: a half-finished migration that stalls for a year is worse than either pure option, and that is the failure mode to plan against rather than the technical risk.

If the decision is also a stack decision, the React Native versus Flutter hiring framework is the more useful lens than a feature comparison, because the constraint is almost always who you can hire to maintain it in three years.

Where the money actually goes

Platform fees are the smallest line. The Apple Developer Program costs $99 per year. Google Play's service fee runs from 11% to 30% depending on the programme you qualify for and how the transaction is classified. Those numbers are stable and public, and they are not what makes a modernisation expensive.

The cost is engineering time, and it concentrates in three places that estimates routinely miss:

Dependency archaeology. Establishing which SDKs can be updated, which have to be replaced, and what each replacement changes about behaviour. This is slow, unglamorous work and it is where schedules slip.
Regression surface. An app with weak automated coverage has to be re-tested by hand after every structural change. If test coverage is thin, budget the testing before budgeting the refactor.
Parallel maintenance. During any rewrite the old app still needs to meet the same store deadlines. That is two codebases under obligation, not one, and it is the cost that turns an affordable rewrite into an unaffordable one.

Teams comparing build locations should read the trade-offs in our India versus US app development cost breakdown alongside this, because location changes the rate but not the shape of the work.

India-specific considerations

Indian product teams hit this decision with a particular profile: an app built between 2019 and 2022 by an agency that no longer holds the context, often with a native Android base and a thinner iOS build, and a founder who wants a rebuild because the app "feels old".

Three things are worth saying plainly. First, "feels old" is usually a design system problem, and a design refresh over a working codebase is a fraction of a rewrite. Second, the DPDP Act, 2023 changes the dependency question, because an unmaintained SDK collecting personal data is now a compliance exposure and not just technical debt, which moves Test 2 up the priority list. Third, Google Play's 31 August 2026 target API deadline lands during the festive quarter build-up for commerce apps, and shipping a structural migration into peak season is a scheduling mistake independent of the engineering.

Teams running an app that mostly works and needs to keep working should look at mobile app maintenance and support before scoping anything larger.

How we scope this

eCorpIT is a Gurugram-based technology consultancy founded in 2021, assessed at CMMI Level 5 and MSME certified, with partnerships including AWS, Microsoft, Google, Shopify and Kaspersky. Our mobile work covers iOS and Swift and Flutter builds, and a large share of it is modernisation rather than greenfield.

The engagement usually starts as a fixed-scope assessment rather than a build. Senior engineers run the five tests above against your actual repository: a clean-machine build, a dependency audit flagging unmaintained and personal-data-touching SDKs, a walkthrough of the revenue-critical paths, and a release-history review for change failure rate. The output is a written recommendation with the store deadlines mapped against it, and it is deliberately capable of concluding that you should not hire us to rebuild anything.

Where a build follows, we work in the incremental replacement mode described above by default, keeping the app shippable throughout. We design applications aligned with DPDP Act requirements and platform privacy rules, and we work as senior-led, multi-disciplinary teams rather than handing a legacy codebase to whoever is available.

FAQ

Should a store deadline trigger a rewrite?

No. Apple's Xcode 26 SDK floor and Google Play's API level 35 requirement are toolchain and manifest obligations, not product changes. They are refactor work. Treating a dated compliance task as justification for a rebuild is the most common way a short project becomes a long one.

What is the Google Play target API deadline in 2026?

Existing apps must target Android 15, API level 35, or higher by 31 August 2026 according to Google's developer documentation. Developers who need longer can request an extension to continue distributing to all Google Play users until 1 November 2026. Check the primary documentation for your specific app category.

What does Apple require for App Store Connect uploads now?

Since 28 April 2026, apps uploaded to App Store Connect must be built with Xcode 26 or later using an SDK for iOS 26, iPadOS 26, tvOS 26, visionOS 26 or watchOS 26. Separately, approved reasons for required-reason APIs have been mandatory since 1 May 2024.

Is Joel Spolsky's advice against rewrites still valid?

Mostly, with caveats. His knowledge argument holds: rewriting discards tested bug fixes and institutional understanding. But he wrote in April 2000 about desktop software where no platform owner could set your deadlines or stop distribution. Mobile removes those assumptions, so the argument needs testing rather than automatic application.

When is a full rewrite actually the cheaper option?

When several signals align: multiple unmaintained dependencies that cannot be updated, no current team member who can explain the revenue-critical code paths, a high change failure rate across recent releases, and a structural rather than superficial platform requirement. One signal alone is not enough to justify the parallel maintenance cost.

What is incremental replacement?

Building new surfaces in the target stack behind the existing app shell, moving one screen or flow at a time while the app stays shippable. It preserves the tested code paths that work and avoids the period of shipping nothing. The risk is a stalled migration leaving two stacks in one binary indefinitely.

Do unmaintained SDKs matter beyond technical debt?

Yes. Apple has required approved reasons for required-reason APIs, including those used by third-party SDKs, since 1 May 2024, so an unmaintained dependency can block submission. Under India's DPDP Act, 2023, an abandoned SDK handling personal data is also a compliance exposure rather than only an engineering concern.

How much do platform fees add to modernisation?

Very little relative to engineering. The Apple Developer Program is $99 per year and Google Play's service fee runs between 11% and 30% depending on programme and transaction classification. Modernisation cost concentrates in dependency work, regression testing, and maintaining the existing app while the new work proceeds.

How eCorpIT can help

eCorpIT runs the assessment described above as a fixed-scope engagement before anyone writes migration code, so the rewrite-or-refactor decision is made on evidence from your repository rather than on how the app feels. Our senior engineering teams then deliver the chosen path, keeping the existing app compliant with Apple and Google deadlines throughout. We are a CMMI Level 5 assessed, MSME certified organisation based in Gurugram, working with AWS, Microsoft, Google, Shopify and Kaspersky. If you have an aging app and a deadline, talk to us about the assessment.