Custom-Developed App Not Updated for Two Years Crashes on New Phones: Fix or Rewrite?

It is common for custom-developed apps that haven't been updated for one or two years to crash on new phones in 2026. In most cases, the code isn't too “old” to run — rather, the external environment has changed: system APIs, vendor ROMs, third-party SDKs, and app store rules. Before jumping to a full rewrite, run a three-step self-check to categorize the problem, then decide between compatibility maintenance, partial refactoring, or a complete rewrite.

The core decision is simple: does the app still have ongoing value, and can this problem be filled in through an upgrade? Most projects can be solved with compatibility upgrades, and the percentage that truly needs a full rewrite is not high.

One or Two Years Without Updates: Crashes Often Come from External Environmental Changes

In the 2026 development landscape, iOS and Android are still adjusting APIs, permission policies, and background mechanisms, while phone manufacturers are also changing memory management and notification rules. As long as old code hits a single deprecated interface, it may exit directly on a new model — the code hasn't “spoiled” by itself.

• Deprecated system APIs or behavior changes: old networking, location, and file access methods no longer apply, and permission-related crashes tend to appear after forced upgrades.
• Third-party SDK shutdown: payment, push, map, and analytics SDKs often set deactivation schedules for old versions, so commercial features will behave abnormally after a certain date.
• App store rules: new submissions generally require a higher targetSdk level; even if the old package is installable, releases and updates can be stuck in review.
• Certificates and server resources: expired push certificates, changed payment callback domains, or servers still using old TLS can make the app open but unable to function.

Don't Talk About Rewriting Yet: Take Two or Three Days for a Check-Only Self-Inspection

Before deciding whether to spend money on repair or a rewrite, spend two or three days on an inspection. The goal is to classify crashes into three categories: system compatibility, certificates/resources, and code aging. Misclassification can easily lead to rework later. Note that this round adds no new features; you only inspect, not modify.

1. Run the main flows on 5 to 8 mainstream phone models from the past year. Cover high-, middle-, and low-end devices, and especially go through login, home page, order placement, payment, push messages, and album upload. If crashes are concentrated on certain system versions, it is mostly a compatibility issue; if all models crash, you should be more suspicious of backend interfaces or internal code logic.
2. Check the compile configuration and SDK versions. Inspect minSdk, targetSdk, and dependency library versions, with special attention to payment, push, map, and login SDKs. Any item officially marked as “not supported” should be listed as a first-round upgrade.
3. Check certificates, accounts, domains, and server TLS. Many old apps don't really crash — they just fail to respond at login or don't receive SMS verification codes. Inspect push certificates, payment callback addresses, and server HTTPS settings item by item; doing so eliminates quite a few “fake crashes.”

On an actual delivery engagement, we had a logistics client whose app hadn't been updated in two years. Crashes were concentrated on new device models, and the original development team was no longer available. There was only a two-week window before a major sales promotion. We did not do a full evaluation; we only took the three device models with the largest crash contributions from backend analytics, upgraded the login, payment, and message flows into a runnable version, and shipped it. Core transactions recovered, but a few niche models still had occasional crashes – scheduled for the next release. If we had chosen a full rewrite at that time, based on our experience range it would have taken at least 3 months, missing the promotion and costing much more.

Three Approaches in the Typical Range: Patch Maintenance, Partial Refactoring, and Full Rewrite

After the self-check, depending on user volume, business stability, and code maintainability, there are typically three ways to proceed. The criterion is not how old the code is, but whether a redo can bring real new value.

• Compatibility maintenance upgrade: Suitable when users are still active, the business hasn't changed much, the code can still compile, and the issues are limited to system adaptation. The approach is to update SDKs and targetSdk, then run regression tests on new devices. In our experience range, the delivery cycle is commonly 3 to 6 weeks, and the cost is about 10% to 30% of the original build fee.
• Partial refactoring: Suitable when one main chain fails repeatedly and every feature addition requires patching old code. Rewrite only core paths such as payment, login, and ordering, while other modules receive compatibility treatment. Costs mostly range from 30% to 60% of the original build fee, and the cycle is shorter than a full rewrite, but data migration and API compatibility cannot be omitted.
• Full rewrite: Only when the code cannot compile, the original SDK has no upgrade path, the original development team is unreachable, and the business has to be sustained long-term. The focus of a rewrite is not changing the UI, but rebuilding the data model and interface boundaries. Historical data migration and integration with internal systems are common delay points — don't estimate the schedule only by page count.

When You Shouldn't Rush to Fix It

The above steps are appropriate for apps that have real users and a stable business process and are merely concerned about compatibility on new phones. Under the following situations, technical maintenance may not be the first priority.

• Should be fixed right away: The app still has daily activity, core login or payment flows are blocked on new devices, and the source code, certificates, and backend account are all available.
• Worth observing for now: Crashes are limited to a few low-end models or niche system versions with a small user share. Record them and reassess the priority monthly.
• No need to rush technical maintenance: When the app has little long-term retention, operations content is no longer updated, and the business direction hasn't been validated, first validate product value with a minimum viable version. Don't spend money on an old package that nobody uses.

Another boundary: if the original code can no longer be compiled and the third-party SDKs and backend APIs are also completely unavailable, a prerequisite for compatibility upgrades no longer exists. In that case, re-sort the business requirements and replace the whole app — don't try to keep it on life support. If a small-step upgrade can solve the problem, don't do a full rewrite. If only one core chain keeps failing, consider partial refactoring. Before a full rewrite, think clearly about how data will be migrated and how old users will transition.

FAQ

Will a custom app that hasn't been updated for two years be taken down from the app market?

Users who have already installed it are usually not immediately affected, but most app stores restrict new submissions and updates for apps with old targetSdk versions. Existing users still being able to use the app doesn't mean new users can find and install it normally.

For an old app that crashes, should I stay with the original development company or change teams?

When source code, certificates, and documentation are complete, getting a quote from the original team tends to be more convenient. If the original team is unreachable or documents are missing, then find a team with experience maintaining similar apps to do a technical evaluation. Don't switch teams and start from scratch based on a hunch.

Roughly how long does it take to fix an old app once?

When it's only system adaptation, SDK updates, and regression tests on new devices, the usual range is 3 to 6 weeks. When core paths such as payment are involved or partial refactoring is needed, the cycle usually reaches 8 weeks or more. It's safer to have an evaluation report first and then decide the workload.

Can bumping the version number and re-submitting fix the crashes?

No. App stores check the binary, the signature, and target API levels. Bumping the version number won't fool the review. Even if it goes live, system compatibility and permission behavior issues will still appear on new phones.

First, don't blow the problem up into “should we rewrite?” When an old app crashes on new phones, use the three-step self-check to collect device and crash information. Small-step upgrades are usually cheaper and less risky than a full rewrite. If the app itself has no active users or its direction hasn't proven out, don't pour the budget into technical maintenance — a minimum viable version for market validation is more appropriate.