So you’ve been working on your OutSystems mobile app for months, and you’re ready to go live, awesome! I have a question for you: After going live, what update distribution strategy are you going to go with?
In this article I will highlight the importance of a robust mobile application update distribution strategy, break down the types of app updates and highlight one of the most overlooked distribution feature in OutSystems. This article will not touch on mobile app generation since the application distribution phase comes after the app generation step. Nevertheless, if you’re looking for documentation on app generation, I recommend checking out OutSystems official docs where you’ll find detailed guides you can follow.
What is mobile application update distribution?
Let’s start with a quick definition: Application update distribution is the process of releasing app updates to a set of users to continuously promote app engagement and usage. This process is typically the final step in a mobile app deployment workflow and consists of planning the ‘how’ and ‘when’ when it comes to getting your app into the hands of your users.
Today, there are various distribution channels to which you can submit your app, ranging from publicly accessible app stores to enterprise mobility management solutions. Your target audience should heavily influence the channel you select to guarantee that your app is reaching its intended users. For instance, a mobile app intended to be used by internal company employees might not be best suited in a public app store like the Google Play Store or Apple App Store, but rather distributed via an internal enterprise store. Similarly, a mobile app targeted at customers would have a higher adoption rate if distributed securely via the public app stores rather than being sideloaded.
Furthermore, there are 2 other key factors to consider in your update distribution strategy: The expected frequency and the type of updates.
The frequency of updates refers to the expected time between every update pushed to your end users. Consider an example where you’re releasing a mission-critical application and need to have the ability to roll out updates in the shortest time frame possible to minimise unexpected production issues. In this scenario, using the public app stores as your distribution channel might not be preferable since app store review times for each new update can be too significant for the business to accept.
The other factor is the type of update. Typically, there are two common ways of pushing updates to your customers:
- Store-only updates: This type requires the end-user to download the entire native build to their device, typically distributed via public or private app stores.
- Hybrid updates: These are lightweight updates where the app itself downloads only the new “app parts”, without the end-user having to download and update the native mobile shell. These updates are efficient when you slightly change the UI or logic, especially when the app already works with the installed native shell. In addition, you can still release a new native build to the app stores in parallel. However, you’ll need to ensure that you safely handle changes that the new native build will introduce in the soft update. This will guarantee an undisturbed experience for customers who received the soft update but haven’t updated the native build yet.
So, how are those concepts applied in OutSystems mobile apps I hear you ask. Let’s start with Hybrid updates.
The benefits of Hybrid updates
All OutSystems mobile applications are set up to receive hybrid updates by default. Understandably, this is the favoured configuration for the majority of applications, and there are multiple reasons for this:
- Soft updates, patches and light hotfixes are delivered to the customer as soon as the release is pushed to production.
- Thanks to this speed of delivery, any vulnerabilities that could be addressed with a soft update are immediately patched when the user launches the app. This significantly minimises the chances of end-users encountering these kinds of issues.
- Users who have app store auto-updates disabled will still receive those critical updates.
The problem with Hybrid updates
Considering the benefits above and the fact that OutSystems recommends using Hybrid updates, you might ask, “Why would I ever want to think about configuring my app’s updates in any other way?”. Well, there are multiple scenarios where soft updates might not be preferable.
Firstly, there isn’t a straightforward method to disable soft updates for a particular deployment where your app relies on a new feature that also requires a store update. This lack of control could introduce instability risks if users use the app with the soft update before installing the store update. This limitation is further magnified by the fact that public store submissions could take a couple of days to complete the review process, let alone the time needed for the users to download the update which increases the risk window significantly. Now, of course, there are strategies to minimise this (like properly handling new Cordova plugins or disabling parts of the app which need the store update); however, this usually comes at the cost of user experience.
Secondly, consider this scenario: You’re working on a mobile application that will be used in a completely offline environment. Your mobile application will not receive soft updates even if configured to do so due to its offline state. However, more importantly, due to the app remaining in an offline state for an extended period of time, it will most likely miss many soft updates. If the app then goes online and fetches the latest soft update, the introduced changes might attempt to modify app parts that don’t even exist in the app (that might have been added in a previous missed soft update). This puts the app and its local data at massive risk of corruption or data loss, and due to the environment’s offline state data backups would been a challenge.
With those 2 scenarios in mind, it’s clear that a Store-only update approach is much more suitable in those cases. This is where OutSystems’ overlooked Configure Mobile application updates distribution feature comes into play. Found under Technical Preview at the time of writing, this feature enables Store-only updates for your OutSystems mobile apps on a per-app basis (Keep an eye out for follow-up article reviewing this feature in detail). Now, lets talk about what you can gain from this switch.
The benefits of Store-only updates
Some of the immediate benefits gained from switching to this approach include:
- Increased stability of offline applications: As highlighted in the second scenario (under The problem with Hybrid updates section), applications primarily used in offline environments will not run the risk of data corruption due to multiple missed soft updates. Updates to the app can be rolled out in a much more controlled fashion, ensuring that the underlying data remains safe.
- Controlled rollout plans: Store-only updates favour distribution strategies with multiple distribution channels. This is thanks to the increased coordination control that Application & Enterprise Release Managers have across all their channels, ensuring that all channels are serving the same version at the same time.
- Increased flexibility during PVT (Production Validation Testing): Due to soft updates being disabled, app changes are not rolled out immediately anymore after production deployments. This creates the opportunity to establish a safe PVT practice, where tests can run, issues be detected and resolved before submitting the app to the stores and eventually reaching the end-user.
The problem with Store-only updates
Despite the advantages listed above, there are a few downsides to this approach you need to be aware of:
- Starting with the obvious one: no soft deployments. With the Configure Mobile application updates distribution feature enabled, even a small tweak would require a new app shell installation. This might be less of an issue if you have a rigorous testing strategy that would catch any issues before release; however, the ability to quickly push a fix when needed can be invaluable.
- Delayed time of distribution. Following up on the previous point, the extended time needed to distribute a new native build can be too significant for the business to accept. This is especially true for apps being distributed on the public app stores, where review processes can take days before the update is successfully published.
Final Thoughts
Implementing a robust mobile application distribution strategy is vital to achieving the successful delivery of your mobile apps. Furthermore, continuously reviewing and optimising the performance of your update distribution channels will enable you to adapt to technological evolution whilst continuing to satisfy the needs of your customers and achieve long term success.
Not all apps are built the same nor have the same requirements, so knowing that you can consider a Store-only update distribution feature for your OutSystems applications could be all that you need after a successful launch.
Ossama Ghanem
Technical Lead & Trainer
Connect with Ossama on LinkedIn
This article was originally published on LinkedIn.
