“Have you deleted the app and installed the latest build?” Is something that’s thrown around countless times here at Tappable, especially when clients are testing apps because things can change in the app structure that needs a clean install. Unbeknownst to them, they’re using an outdated build and by nature will experience a few issues. While we give instructions on how to appropriately check builds, we’ve figured that it’s in everyones best interest to try and find a way to automate the process of refreshing the clients build.
First, we must highlight the reasons why we currently have to uninstall an app before installing a new build:
- To delete written data in the device, such as downloaded or created files
- To assign a new device or unique user ID
- To reset remote data e.g. accounts in services and servers
- To verify that the client has the latest build installed
So now we’ll talk about a potential solution to this ongoing problem.
Detecting the App Version
When a new app build is installed for Android or iOS, it is installed as an update which means that it will keep the data. A file containing the current version can be created to inform the next install which version was installed before. If the file does not exist, that means it’s a fresh install – otherwise the new version will know it needs to clear its data and execute another reset.
Identifying the Device
Usually a device ID is used for client-server communication. As it comes from the operating system, a “salt” can be added to the original id in order to be able to manipulate it. With this implemented, the ID can then be changed in every build and the servers will take it as a new user. If third party plugins/services use a different ID, it should be handled automatically by the reset feature.
Running Version Control
When the app starts it should check that is running the latest version and show a pop up if not. That validation is made using a server which contains the information of the latest build and provides links to the user to update to the correct version. The version count must be increased each build, however this process can be made automatically. Note that the build must have an internal tag to mark it as a production or development build. This way, it can use the same ID and remove the pop ups if it is a production build.
- It will avoid the errors and bugs created when clients use an outdated build
- Easy adoption flow for the client
- Avoids distributing updates by sending links to clients
- An internet connection is required even if the project doesn’t need it
- Additional development is required to create and setup a plugin that provides the functionality
- A server to manage latest build links needs to be developed
Thanks for reading.