The pace of change in mobile technologies continues at pace, with new operating system changes and handsets, do apps have a best before date or shelf life? Lets see…
So will my app go out of date?
Well, broadly yes. An app written and released to the store and never touched thereafter, may require a complete rewrite within one to three years. This could be due to changes in the underlying OS, new mobile devices with a unique screen size, or format (like when iPhone X came out with the “notch”), or new security requirements (like GDPR). App changes could also be forced by changes in web services and APIs that your app is depending on, by branding changes required by your company or really any number of external factors.
So what can I do about my app going out of date?
A total code rewrite should not be needed if you look after your app, typically with a support and maintenance programme. Proper maintenance means that as new features are added, the underlying code is updated to support those new features, and other parts of the code may also need to be rewritten over time in order to support new platform releases.
Support and maintenance is the process of updating an app to keep it cleaner, maintain efficiency, monitor performance or support structure and connectivity. Support and maintenance also allows you to keep your codebase up to date by taking advantage of the latest development techniques and best practices.
Having a backlog of technical items, allows you to make sure that every incremental release contains both improvements to the codebase as well as new features. A backlog is just what it sounds like – a log of things in your code that you know need to be updated and improved to maintain the code, make it more efficient and less buggy. Sometimes a backlog is the result of consciously taking shortcuts during the development process to avoid obstacles or get to market faster with a minimal viable product (MVP).
The trick is to continually review the code so it does not stagnate. As you look at new features your app development team should be looking at the code and decide if a restructuring of that section is needed to implement the new feature. Alongside this the support and maintenance programme should be looking at external factors, like platform releases, third-party SDKs and API updates to plan changes to accommodate these.
Occasionally iOS or Android will release major changes that impacts the entire codebase, your team will get early sight of these and at that stage can evaluate and plan changes ahead of it going public. It is important to do this carefully and iteratively, to avoid creating new issues.
When Should An App Be Rewritten?
If an app has been unmaintained for a considerable amount of time, something we see when we help clients by taking on an old project, then a rewrite may be needed. In this case, it can take longer to update the old code than starting again from scratch.
Good support and maintenance is less risky and more economical than rewriting. Without doubt, rewriting a whole app from scratch is risky. It is likely that new issues will be uncovered during the process. It is less risky and cost effective to maintain the existing code and improve it over time, testing as you go with each release, than to completely start from scratch. Only in rare circumstances would a complete code rewrite be more economical.
How Can I Learn More About Support and Maintenance?
Simple, if you are a current client speak to your account manager, we have a comprehensive options pack they can share with you. If you are not yet a customer get in touch.
So remember:
- Your app doesn’t have to have a best before date.
- Support and maintenance of the code will prevent problems.
- New features can also be added as part of a support programme.
- Include code improvements in each release, in addition to planned features and bug fixes.
- Actively maintaining your apps is more economical and less risky than rewriting your app from scratch.
