Releasing a mobile app is vastly different from releasing a web application. There are a number of unique challenges and considerations that need to be taken into account, like releasing new versions of your app, interfacing with hardware, and managing version migration.
Obviously, one of the main challenges when releasing a mobile application is not owning the servers that distribute your app. When you make a release on a web application, you can push code as often and as large as you like because the servers are owned by the company. However, in an app ecosystem, you have to go through an Apple or Android review process since they host the binary your users will download.
While this sounds like a subtle difference, it can completely change your software development life cycle (SDLC) and release process, and restrict the way you deliver software to your users. Fast reverts are almost nonexistent in app development.
Backward compatibility focuses on ensuring your old app versions still continue to work well on all devices. However, managing backward compatibility can be difficult. In this article, you’ll learn about backward compatibility, why it matters, and what issues it can pose as well as how to mitigate those issues.
Backward compatibility simply means that older versions of your app will still work despite new releases. For example, if you made an app and originally launched version 1.0.0 but are now releasing version 20.0.0, you need to consider and plan for what type of an effect your new development will have on older versions.
This is much easier said than done. Because so much can change between version 1.0.0 and 20.0.0, it’s easy to forget what older versions of the app rely on. A new developer on the team can easily delete something that will cause an older version of the app to constantly crash and be unusable. Unless you are closely testing and monitoring older versions of your application, you would be unaware of the degraded user experience.
For instance, if you make an iOS/Android book app, you may have a JSON response that looks like this:
.png)
Four years down the line, you may choose to remove the facts feature but forget that an older version is dependent on it. In this scenario, if the facts section was used in version 3.3.1 of your app and dropped in version 15.0.0, anyone using your app between those two versions will likely experience constant crashes because the app won’t be able to deserialize the JSON.
Backward compatibility poses all kinds of long-term issues, including crashes and forced updates, in addition to increasing the difficulty of new development and testing.
Some reports show that up to 69 percent of users leave apps due to persistent app crashes. Another study found that only 16 percent of users give more than two tries to an app that crashes.
Keeping your users happy, providing a stable platform, and ensuring all versions of your app are crash-free are all strongly tied to the backward compatibility process you follow.
Some users will never update their apps. Applications that offer critical services, like banking, money transfers, or cybersecurity/MFA, get around this by forcing users to update.
However, force updating is generally considered bad practice as it can cause a frustrating user experience. Forcing updates can cause users to lose important information if they were in the middle of doing something, and it can even lead to users being unable to run the app due to its new size.
For instance, size-based worries were shown to lead to a 0.45 percent increased risk of never installing/uninstalling applications per extra megabyte added (if your app is less than 100 MB). Instead, you should consider continuing support for older versions for as long as feasible and disabling the latest or updated features for them. Users can choose to update the app when convenient, or you can speed up this process by offering new features via banners and popups that encourage your users to update in a timely manner.
It’s also possible for the app to become completely unusable if the user doesn’t have access to the internet at the time you force through an update.
Software teams, release managers, scrum masters, and others all focus heavily on the momentum of their developers. The goal is always to be stripping away blockers, speeding up development cycles, and maximizing (and protecting) their developers’ uninterrupted development time in order to deliver new features.
This is extremely positive for developers and can lead to a massive increase in the valuable contributions and work they can deliver per sprint. However, old app versions often become a hindrance to this productivity.
You can start to feel like new development is jumping through hoops for users who haven’t updated their app for two years and likely never will update (often due to their phone not supporting anything more recent).
This is frustrating as a lot of your users may be on the new app version, but development can be slowed by a percentage of users who are slow/reluctant to ever update their apps. Möller et al found that almost half of app users will still continue to use a vulnerable app, a week after a fix has been published.
Crashes are a key quality metric for developers - generally measured in how many times your app crashes per 100,000 users, represented as a %.
In situations where reports show a high crash rate on particular versions of your app, developers may be assigned the task of identifying why the crash is happening and then debugging and resolving this issue. To run tests on a particular version of your app (to release it as part of your quality checks) means that your developers have to do multiple debug builds on test devices to ensure your backward compatibility with each new version is high quality.
There are even a whole host of checks you can run (ie upgrade testing) to ensure your migrations between new versions of your app are smooth. But this can be difficult to manage unless you employ full-time testers.
Handling backward compatibility in traditional applications is complicated. However, there are several different methods available that can help mitigate the complexity, including the following:
In most cases, backward compatibility issues are caused by APIs upgrading to newer versions and dropping support for features that older clients depended on. To curb this, you could version the API so that the older versions of your client can still communicate with the older versions of your API rather than crash.
If you’re aware that support for a particular feature has been dropped in the latest version of your app, you can display a message in the older version of your app asking users to upgrade only when they try to use that feature. If they are happy without it, they may continue to use the app as before.
If you’ve made breaking changes to your app in your latest versions and are certain that the older versions will not work anymore, your only option is to force updates. While this may be off-putting to a lot of users, it can help prevent a bad user experience. However, you should try and avoid it when possible.
Server-driven UI (SDUI), an alternative approach to developing mobile apps, has recently gained popularity. It presents a near-perfect solution to the backward compatibility problem. SDUI enables you to deliver UI components to your users dynamically instead of hard coding them on the client. This further enables you to update the UI of your application as the APIs upgrade without having to release updates via the app stores and waiting for users to update their clients.
Unflow, an SDK, provides rapid iterations of SDUIs. In addition, it allows nontechnical people to rapidly design and deliver in-app content while making the (sometimes slow) release process instant by circumventing the app store release cycle.
It also comes with other added features like a clean design where you can use templates based on the best-in-class interface design or even utilize your own design system to create templates that you can use over and over to give your app a consistent look and feel.
Unflow also offers effortless A/B testing where you can ship multiple different binaries to your users to verify what resonates with your customers the best.
All these features enable you and your team to ship faster and deliver more quality additions to your app in a shorter time frame to delight your customers, without having to worry about the added backward compatibility hindrance.
This article has introduced you to what backward compatibility is, why it matters, what the common problems associated with it are, and how to mitigate those problems.
You can request access to Unflow today and start exploring adding SDUI to your app.
