3 ms·

> 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 relat

> 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.

georgyo 4y ago
Are they actually that rare? 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.
- kiawe_fire 4y ago
  I think the reason they might appear rare is because the number of desktop apps that depend on a remote server for functionality are less common. 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.
sethhochberg 4y ago
As much as any sane development team tries to avoid breaking changes, they're virtually inevitable for a long-enough-lived client/server platform. 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
- ryandrake 4y ago
  From the user's point of view, I can't think of a good reason to force users to update software, besides maybe a security/privacy issue. As a user, I expect software that works today to work tomorrow--forever. Every time I update, I risk getting a new UI shoved down my throat, or my favorite use case removed or broken, or the app has tripled in size for no discernible reason, or it's now too slow for my computer. I've been trained by software companies' repeated bad behavior to not update voluntarily unless I have some kind of assurance that it's purely a security update and no functionality has changed. 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.
  - simonw 4y ago
    "besides maybe a security/privacy issue" Right - that's enough of a reason for me to include a kill switch!
  - alkonaut 4y ago
    A mobile app is the same as a web page. I view them as much more related to web apps, than to traditional desktop apps. 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.
thefreeman 4y ago
It's not to kill the app entirely, it's to force the user to upgrade to a maintained version rather than just having the app crash if backwards compatibility is required to be broken. I tend to do it with two flags, one to enable an upgrade nag notification and another to hard kill switch the version.
- 1-more 4y ago
  Mad annoying when I cracked open an ancient iPad figuring I could watch Netflix on it and oops nope. No indication of why, but I know the answer because I'm the type of person who comments on HN.

> 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.

georgyo 4y ago

Are they actually that rare? 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.

kiawe_fire 4y ago
I think the reason they might appear rare is because the number of desktop apps that depend on a remote server for functionality are less common. 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.

sethhochberg 4y ago

As much as any sane development team tries to avoid breaking changes, they're virtually inevitable for a long-enough-lived client/server platform. 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

ryandrake 4y ago
From the user's point of view, I can't think of a good reason to force users to update software, besides maybe a security/privacy issue. As a user, I expect software that works today to work tomorrow--forever. Every time I update, I risk getting a new UI shoved down my throat, or my favorite use case removed or broken, or the app has tripled in size for no discernible reason, or it's now too slow for my computer. I've been trained by software companies' repeated bad behavior to not update voluntarily unless I have some kind of assurance that it's purely a security update and no functionality has changed. 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.
- simonw 4y ago
  "besides maybe a security/privacy issue" Right - that's enough of a reason for me to include a kill switch!
- alkonaut 4y ago
  A mobile app is the same as a web page. I view them as much more related to web apps, than to traditional desktop apps. 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.

thefreeman 4y ago

It's not to kill the app entirely, it's to force the user to upgrade to a maintained version rather than just having the app crash if backwards compatibility is required to be broken. I tend to do it with two flags, one to enable an upgrade nag notification and another to hard kill switch the version.

1-more 4y ago
Mad annoying when I cracked open an ancient iPad figuring I could watch Netflix on it and oops nope. No indication of why, but I know the answer because I'm the type of person who comments on HN.