Rebuild vs Refactor – How to Future-Proof Your Mobile App

This decision can have a huge impact on the success of any mobile app, from short-term performance to long-term maintainability but, more importantly, it sets up your stall for years to come. The decision you make now could save (or cost) you a lot of money depending on the existing languages, libraries and frameworks of your application, your ongoing development requirements and the specific use case.

Many businesses can jump into an expensive and timely rebuild when a refactor would be more impactful. So, when do you rebuild or refactor an app?

The difference between a rebuild and refactor in mobile application development can be summed up as follows:

A rebuild refers to the process of completely replacing the existing code base with a new one, while a refactor process entails changing the existing code to a new version without actually changing its functionality.

Rebuild:
A rebuild is more intensive, as the entire code base must be replaced for it to take effect. This process is more common in the case of major upgrades or changes to a completely new development language or framework. Generally speaking, this process requires more time and resources than a refactor, but can provide a blank slate in terms of design, functionality and, often, technical considerations.

Refactor:
On the other hand, a refactor is more lightweight, as it involves making changes to the existing code without changing its functionality. The aim is to improve the nonfunctional properties such as compatibility, speed, ease of use and readability therefore giving you a product which is easier to develop in the future. Refactoring is also used to fix and improve issues that have arisen over the apps lifetime due to neglect and the turn around of app tech stacks. Refactoring usually takes much less time and fewer resources than a rebuild, and when done right, can be used to prepare the code for future changes and updates without the high cost of a complete rebuild.

Refactoring or rebuilding might feel like the nuclear option but the costs and knock-on effects of working in these conditions soon add up; as well as leading to frustrated developers, product owners and execs!

Often it can be difficult to identify that a refactor or rebuild is required, so we have created these thought starters to point you in the right direction:

To improve the non-functional properties such as compatibility, speed, ease of use and readability – Refactoring is the process of altering and normally improving the source code of an app without changing its behaviour/features. Code refactoring improves readability, and makes the QA and debugging process go much more smoothly. And while it doesn’t remove bugs, it can certainly help prevent them in the future.

To stop your app degrading – Refactoring is actually an integral part of best practice app development and should be part of any app project. The fact is your app degrades, this is inevitable, and unless you want to rebuild every couple of years refactoring needs to be part of the process.
Maintaining the app for future ease of development – This is key in reducing technical cost since it’s much better to clean up the code now than pay for costly errors later.

The technology is now obsolete – the development of technology is constantly evolving. This can mean that the tech your app was built in is no longer supported and updated, this obviously creates a bunch of issues, such as security vulnerability and outdated features. Also with new technology there is often a speed advantage to new and future development and sometimes new features or platforms become available as new languages and technologies are released.

The app is low quality – If there are lots of errors within your original app then the risk of replacing it with a new, sometimes bug-fraught implementation isn’t as much of an issue. With the best intentions new apps and software will always have some issues. These need to be ironed out over time but if your current solution is already in a poor state this risk is not as much of a problem.

There are no built in automated tests – Automated tests should be created in tandem with the original code. It is a huge amount of work to retrospectively go back and add automated tests to code that already exists, especially if the person who is writing the code isn’t going to be the one writing the tests.

The project team has gone – This can become a much greater challenge to achieve anything with your app. Every developer has their own way of coding and organising work, but this doesn’t mean the previous developer’s work was poor. The new developer should evaluate the previous code and improve upon it.

Time to market – Rebuilds take longer and time to market needs to be considered. Sometimes you need change now and a rebuild will not achieve this for you. However if this isn’t an issue a rebuild can be a variable approach.

Cost – Normally a rebuild is a costly route to take, especially upfront costs. Most of the investment in taking your application to where you want it to be is made upfront in one go though sometimes developers are willing to amortise these costs over a longer period of time.

As there is no hard and fast rule to rebuild or refactor we recommend implementing a full audit of your application. We use the Springboard Framework to understand the code quality, back history, and integrations. This also includes looking at the processes and business goals along the way, and if your application has an issue with it or has fallen over, so it can be determine whether it needs a rebuild or a refactor by following the steps below:

1. Complete a full technical audit
2. Capture & document required functionality
3. Audit your existing application’s functionality
4. Deploy a lightning release
5. Implement modern development infrastructure
6. Monitor, measure & maintain

Application Defibrillation – If your application has an issue with it, or you’ve lost control over your application, then we can act as an emergency service to come in and fix the issues as quickly as possible. Often this will be about quick fixes to restore functionality or to restore an application to the app store.

Code Review – We’ll take your app perform a top to bottom code review to understand what the next best steps are. Whether that’s a full rebuild or a refactor, we’ll come up with full recommendations based on our audit.

Good developers write great code but great developers keep on top of their existing codebase throughout the lifecycle of the product. The pressures of a release deadline can lead to shortcuts taken, suboptimal development methods and poor documentation which lead to almost immediate tech debt.

This can lead to a snowball effect with every release which eventually results in a requirement for a major refactoring project or even a complete rebuild. Sometimes though, proactive refactoring just isn’t enough. This could be due to languages becoming less common and therefore harder to find proficient developers or due to losing specialists within your own business.

Whether you initially decided to develop your mobile app using a native or cross-platform approach can have a significant impact on the design, features, and performance of the app; but what can often be less appreciated is that this decision can rear its head (often years later) when deciding whether rebuilding or refactoring the application is the right decision.

A native app is developed specifically for a specific mobile platform, such as iOS or Android, whereas a cross-platform app is designed to run across both platforms. Native apps tend to offer the best performance and user experience but they require more development and maintenance as they’ll require managing two separate codebases in order to be available for iOS and Android.

Cross-platform apps are generally cheaper and faster to develop but are not always as reliable or feature-rich, though this has been improving rapidly in recent years and, unless you’re looking to use bleeding edge OS technologies, for most purposes cross-platform will be just as performant and feature rich as you’ll need.

Often when we’re tasked with identifying whether a native app requires a refactor or rebuild we start by working out the amount of ongoing future work and new features are needed. To help us decide if more cost might be saved by rebuilding in a cross-platform framework such as Flutter, React Native or MAUI. This can sometimes (counter-intuitively) turn the more expensive rebuild into the more cost-effective long term solution.

When you’ve decided that you need to make the wholesale changes and investment required for a rebuild or refactor it’s important to take the time to understand the quality of the code as it stands.

In order to determine good or poor code quality ahead of making a decision your developers should examine:

• the overall design and structure of the code
• ensure the code is well-documented
• review the code for any known vulnerabilities
• check that the code is tested adequately.

If the quality of the code falls below the expected standard this may mean it will be easier to rebuild the solution rather than refactoring from the shaky foundation of a poor quality codebase. Conversely though, good quality but outdated code could be relatively easy to bring up to modern standards.

Another area it is important to audit is the security and data protection presently built into the app. As modern apps take on greater responsibilities in handling sensitive data it is important that the way that data is stored and transferred is in a secure and professional manner. Particularly apps which are deployed internally within organisations which may contain more sensitive data than public facing solutions.

Apps are also increasingly being used to store data when offline or when connectivity is limited, which again may mean a greater proportion of sensitive data is stored locally on the device versus other software implementations.

As part of this audit you’ll also need to see if the coding standards and security provisions are in line with the wider protocols established within the company such as ISO 27001 and cyber security essentials and so forth. Often legacy & neglected code bases are forgotten about and fall foul of not being compliant with modern protocols and standards.

Often when we’re asked the question of whether we would recommend a rebuild or refactor it’s because an app has been removed from the App Store or Play Store due to running afoul of the store guidelines. More often than not these days this is due to permissions, data security or battery management policy changes as these have seen the most rapid changes over the last few years. Sometimes the required changes might be relatively small and inexpensive but equally they could require large changes to substantial portions of the applications code which may necessitate a rebuild.

It’s essential to stay up-to-date with the latest mobile development trends and technologies. As technologies evolve, older languages and frameworks are often deprecated, meaning that they are no longer supported and can lead to compatibility issues with newer devices and operating systems. If your app is using an outdated language or framework, it may be worth considering rebuilding the application or, in some cases, refactoring into a newer version (for example Xamarin to MAUI).

Using a deprecated or insecure library can also be an increasingly common reason for app store removal so there may be an immediate requirement for an update where possible to get your app back into the stores.

The key point across all of these factors is that your decision should be influenced by both the current situation of your application and the desired future state.

If you have a native application with a large backlog of required new features, poor general code quality and no need for bleeding edge functionality then a rebuild into a cross-platform codebase could well work out the quicker and cheaper route. Often this can be difficult to hear due to the sunk cost!

If, though, you have an application which has good code quality and a robust feature set but has some outdated libraries or has been removed from the app stores due to a store policy change then a refactor may be the best route to take.

We often recommend the use of a lightning release both as a way to investigate the existing codebase, integrations and deployment process but also to fix any glaring issues or restore an app to the App Stores as there are likely to be limited updates to existing applications during the process of rebuilding or refactoring.

We’d love to say there is some easy answer or guaranteed formula. But when it comes to time to refactor or rebuild chances are it’ll be a far more in depth decision than can simply be dictated.

We recommend following a process of going through each of the previous points and recording the results as well as defining your business goals with the application before even considering making a decision.

It can also often be difficult to make an objective decision due to sunk-cost or developer bias. Therefore it can be useful to bring in a third party to either inform your decision or help you to perform the checks above and any others that might be worthwhile.