Project Type

Native app rewrites

Native app rewrite to modernise and take advantage of the latest platform technologies - Need help to bring your app up to date and even future proofing it?

Scroll Down
Image of code on a laptop preforming an app rewrite

appface.jpg

The one thing you can be sure of is that technology never stands still.

If your app has become old, tired and creaky (as do we all) or you want a technology refresh - or you’ve realised that your business has changed direction and you want your app to reflect that, at some point, you’ll probably consider having your app modernised and perhaps even rewritten.

This is a big investment, and also a potential headache.  Let’s look at the alternatives.

Why rewrite an app?

Having an app rewritten - effectively done again from scratch - is not something you leap headfirst into. It could be time-consuming, and there may be a few alternatives other than to continue with incremental updates to your existing old design. This can be an expensive way to buy you time, though. A rewrite or a new app is basically an unavoidable part of an evolutionary process.

So what are the telltale signs that you might need to consider an app rewrite?

Deprecation may mean that you’re simply not allowed to publish any updates to your app. If your technology stack is so dated, there may only be one possible way to go. Apple and Google say “no”.

Apps build on PhoneGap / Cordova technologies can easily get into this situation. Does the following look familiar to you?

ITMS-90809: Deprecated API Usage - App updates that use UIWebView will no longer be accepted as of December 2020. Instead, use WKWebView for improved security and reliability.

Updating PhoneGap / Cordova apps can be a time-consuming process, and at the end you still end up with the same app and same look and feel.

Using this time to refresh the app with a new design, built on a foundation of modern technologies might cost less than you think, as modern development frameworks are easier and faster for developers to use.

Complexity of the existing app. New features and ideas emerge all the time with software. You’ve doubtlessly had a few ideas about adding features.

After a year or two or putting new features in, you may find it gets steadily more difficult to add anything else. The underlying interconnected structure of the app makes it more an increasingly more convoluted process to add new content, and if you’ve changed developers mid way through, it can turn what should be a simple functional add on into an expensive, unreliable and time consuming process.

Talking of unreliable, this leads us to…..

The bug hunt takes longer. Nearly all software inevitably contains bugs. Either these bugs are programming mistakes or a result of complex code having to speak to several different external applications via an API.

Modern apps usually contain about 9 or so API’s, linking out to functionality like payment layers or location services. As your app grows, there’s more complexity, more room for bugs. And it’s more difficult to find them.

If your app has been developed using a number of different development companies, you may find that bugs start appearing as a result of your new developer not quite understanding what the previous developer has done.

Bugs are something you’ll always have to deal with, the question over time becomes not one of “Have we got any bugs?” but “How hard, and therefore expensive, is it going to be to get rid of them?”

Competitor app functionality. On other occasions, a rewrite becomes more an elective process.

Competitor apps are all fast and shiny and dripping with features, and what seemed a killer app a few years back now looks lumpen and trailing a lap behind the others.

What are the alternatives?

REFACTORING

Refactoring. “I’ll get sections of my app rewritten piecemeal until the whole thing is complete, section by section”.

This can work. Theoretically, it’s great, but you can suddenly find that - because of “technical debt” in the app as a whole. you’re making the new bits talk to the old bits, which means a compromise design.

Refactoring can work, however. It’s somewhat dependent on the state of the core app itself: generally speaking, it’s an alternative for when one bit of the apple has gone rotten, but you don’t want to throw the entire apple away. It can, basically, buy you some time before an inevitable rewrite is a necessity.

RESKINNING

Perhaps your app works fine, it’s just … ugly. Or perhaps your app just doesn’t flow. It’s unintuitive, click intensive and (after years of chopping, changing and bolting things on) difficult to navigate.

In both of the above cases, a UX or UI reskin (or both) is possible.

Basically, you can think “does my app really just need a cosmetic makeover? “ This isn’t an initially expensive approach but do be aware that a developer is going to have to tie up the new fancy graphics and navigation with the underlying code.

If the underlying code to the app is sound, refactoring or reskinning are viable alternatives. If your problems go deeper than that, a rewrite may be (eventually) inevitable.

Looks like I need a rewrite

Don’t worry, it may not be as traumatic as you think.

You’re actually at an advantage over someone wanting an app written from scratch: if you’re happy with the functionality of your app and the look and feel, then a lot of the work is effectively already done.

It’s more efficient for a developer to write apps from the ground up, by the way. Starting from first principles means you can avoid bug hunts and compatability issues.

One benefit of having an old app rewritten from the ground up is that you can now take advantage of cross platform development. If your old app was natively developed and had two separate versions for both Android and iOS, it’s probably cost you a lot of money in trying to get both versions with a similar look and feel and to debug both of them.

With modern cross platform development, we can produce one codebase which produces both an Android and iOS app - in 60% of the time it’d take to do separate versions. It’ll run as fast as a modern native app, have an identical look and feel across versions, contain less bugs and allow you to access new technology.

If the bad news is that you’ve come to a point that requires you to have a rewrite, the good news is that your new app will be faster, more reliable and more feature rich than the old app, and at a price which is probably less than you think.

As ever, if you want a chat about modernisation of an app, get in touch with us here. We’re happy to talk through the entire process with you at any time.