> A kill-switch for your mobile apps
Really? I understand the rationale but this is one of the main reasons I prefer desktop apps where kill switches are relatively rare.
Really? I understand the rationale but this is one of the main reasons I prefer desktop apps where kill switches are relatively rare.
A nice poison pill built in up front lets the ancient clients that for whatever reason aren't being upgraded at least get a nice informational prompt when those breaking changes happen, instead of a potentially uglier failure mode
Its one of those things that you think you'll never need because of course you wouldn't make breaking changes, but then at some point an unstoppable force hits an immovable object and this becomes the least-bad way out for user experience
Version your API, figure out how to make maintaining the old versions zero cost, and don't throw users under the bus just because they are (understandably) unwilling to update.
It’s tied to a backend version. I do get annoyed with apps that want to update every single time, but with auto updates it’s not that bad.
As many mobile apps are merely wrappers around a web app, It’s easy to see how this happens. But I think the end game will be even more web-like: apps that indicate they must be up to date and can’t even be manually set to stick to one version.
Right - that's enough of a reason for me to include a kill switch!
Both Slack and Discord at the very least have one, but that is a small sample size.
Both Windows and Mac apps are very eager to self update. A feature they don't have on mobile devices the likely hides these kill switches.
For example, a photo editing suite, word processor, or code editor all have the expectation that they be usable entirely offline, and any additional cloud-based features are coded to fail gracefully.
As you point out, apps like Slack and Discord don't fall into this camp. Not only is their core functionality expected to be online, they are also Electron apps (basically, embedded Chrome browser) that likely have a thin layer of client logic, and load most resources remotely, just like accessing a web page.
Sure, word processors and code editors exist on mobile, and many of them likely work just like their desktop counter parts when offline [1]. But that's not what most mobile apps are. Most mobile apps would be useless without a remote server, and if that remote server needs to make a breaking API change, then you need a way to communicate that.
[1] I assume. It's been a while since I've used mobile MS Word. Even then, I suspect these apps will prompt the user to update or else lose cloud service at some point, even if they otherwise continue to work fine locally.