So you want to future proof your app? Is that even a thing? Is it possible to build an app that can confidently face the future, without ever requiring updates? I once received a request for the development of a new website and among the various other requirements I read this:
“CMS to be accessible and usable across all key browsers (and future proofed against browser updates)”. Italics mine.
Since then, I’ve heard questions of a similar nature regarding mobile app development too. Many times. Reliability and scalability are often central to the brief of the solutions we create, so the question itself is not strange, it’s actually very appropriate. But it does reflect a misunderstanding about the nature of technological progress. You can’t guarantee that something you build is 100% prepared for an unknown future. In the coming months and years, many things outside of your control will have an influence on what you create.
In a sense, the large majority of our projects are “future proofed” but it’s not quite as simple as you might imagine. Confused? Don’t worry, I can explain. Let me give you a quick preview of how we’d build a future-proof app:
Real life future proofing
The biggest problem with our initial definition of “future proof” was that the app would “never require updates”. The apps that maintain their relevance and are really future proof are those, that continue to get worked on (or at least maintained) all the time. It’s really not possible to build an app that is completed once, submitted to the app store, and then never returned to. At least, such an app can’t remain effective and relevant. At the same time, we can follow certain principles during development, to ensure that the app is as up to date as possible when released, so that it will last longer without requiring an update.
Acknowledge the context
As you know, the business environment we work in is constantly changing by its very nature. Nothing is stable. This is the new reality and the new normal. Google changes its search algorithms all the time. One day your website holds the top search rank, the next day Google updates something and your website loses that position. Facebook does the same, as well as many other companies on which we heavily rely today. New versions of Android and iOS are released each year, usually rendering some old functionality obsolete. The rules change all the time and each time, the successful product needs to adapt. What worked before may no longer work with the next update.
Having recognised that reality, it becomes clear that predicting the future and knowing the turning points ahead is impossible. Sometimes you can guess at or find info about the changes for the next update, but beyond that, future changes are totally unknowable. A website or app developer can’t guarantee that once a project is completed, it will last you just as it is for many years to come. We’d love to be able to do that, but it’s simply not an option and anyone who promises such a thing is deliberately misleading you. There are external factors that are beyond anybody’s control, that we cannot influence, but only adapt to.
This is the context. It leads us to the realisation that in order to survive, apps, websites or anything else reliant on the latest technology, must be maintained and updated regularly. The apps that are under continuous development are those that are most future-proof.
So, there’s no way to future proof an app?
Well, yes and no. No, you cannot build an app once that will retain its excellence, relevance and functionality for many years, or even for the next 12 months. As we saw above, this is because of the rapid advancement of technology which makes it difficult for projects to maintain a status quo for even a quarter. At the same time, you can create a product that will be ready for the future. As ready for the future as is possible at the time of development.
Honour the rules of the game
The rules are simple, very logical and easy to follow. Yet, not everyone respects them and applies them to each and every project. All you need to do is build using the latest tech available at the time. This is a very important principle to follow. Very often, at the time of release of the project, you have to check again, that the tech you are using in your project is really the most up to date. Lot’s of projects last for months or even years before completion and live release. This means that the technology used at the start of the project may have changed and evolved or released new versions by the time you finalise the project. We actually had this happen on one project. At the start of the project we used a Twillio API, which got deprecated by the time the project was completed. We then needed to re-do part of the functionality that was done at the beginning of the project.
Let me be very practical here, – using the latest tech on every project means utilising THE LATEST versions of libraries, plugins, modules, language updates, frameworks, etc. This is the first important way to honour the rules of the game. The second way I’ve described above: “acknowledge the context”. In practical terms this simply means to keep the app alive. Like a house built and abandoned, if left unattended and unmaintained for a year, well, you get the picture (spider webs, dust, damp, and maybe worse. The longer it’s left the worse it gets). Pretty much the same will happen with any app that gets built, submitted to the App Store and then left unmaintained.
Conclusion
If your friend has an app and you’re concerned about its future, you can do that friend a huge favour. Reach out to me and I’ll arrange a free health-check of the app and report back on the risk points of the application. It doesn’t obligate you to anything, nor would it mean that they’d need to work with us. It’s just a bonus I’m willing to do for those who read this article till the end! 🙂 Thanks.