Would love to know how they resolved the problem on a technical level.
After all, the apps running in the background would still try to download updates every five minutes and disabling/blocking those update requests on the server might cut those installations off from ever auto-updating again.
Additional feedback on HN about checking even less often, getting user consent, and writing regression tests but commentators are being dramatic and insulting about it.
One of our users, who lived in a house, had their internet provider cancel their contract due to enormous traffic generated during a month. It was extremely problematic as there was no other internet provider available around. We decided to take responsibility and offer to cover all the costs related to this situation.
This is how you deal with a situation like this that you’ve caused. Accidents happen, what matters is how you clean up after.
There is, although if you have one wired broadband provider for an address, and that provider isn't willing to overlook a one-time issue, there may not be a lot of options that money can resolve. (The--sometimes--availability of Starlink helps these days but a sole supplier cutting you off doesn't have a universal fix.)
Is there a reason an app needs to check for updates every 5 minutes vs, say, once a day? That would have made this situation 288 times better, and reduced the processing tax on people’s devices.
Why download updates at all without the user knowing? Is prompting before downloading such an awful user experience in comparison? Or, you know, prompt once per day and add a 'remind me in x days/minutes' option?
The whole take-away of this article feels backwards. Instead of going 'hey maybe we should not just download stuff in the background without prompt', the author doubles down and actually proposes to add a way for the server to signal to the client that an update should be forced.
The article did not mention that as far as I can tell.
>The app checks for the update every 5 minutes or when the user activates the app.
>Normally, when the app detected the update - it downloaded it and stopped the 5 minutes interval until the user installed it and restarted it.
To me this reads as them downloading the update unprompted (as they mention their issue with the previous updater was that it would prompt the users every 5 minutes, which would be solved by just not checking every 5 minutes).
Either way, whatever the bug and its effects are, my gripe is that their conclusion is to add a way for them to remotely force-updates. As opposed to just notifying once or any of the other hundred ways to handle auto-updates that don't involve you remotely forcing an update.
Edit: the founder has confirmed in the comments the app does download without user confirmation, so my original point still stands.
Well, if the user wants the update, downloading in advance is a much better experience, because you only get interrupted once, for a restart that only takes a second or two.
That's in contrast to being interrupted twice (once to download, then again to restart) or a single long interruption (shutting down, then downloading, then restarting).
Of course, it's a different matter if the user doesn't want the update. But we developers don't like to think about that :)
An easier fix could be to just add a toggle so users can decide for themselves if they are fine with the app downloading unprompted or not. (This is just based on the post, the app could very well be behaving that way already but since the post doesn't mention it, I'm assuming it does not).
But also: a check every 5 minutes? I understand what you're saying but the only reason those interruptions are frustrating is because of the high volume of daily updates. This could be solved by just keeping this update-frequency reserved for beta users and maintaining a more sane update-frequency for regular users (now what a sane update-frequency is, is a whole other discussion judging by the comments so far :P)
Now I’m not saying coding is rocket science (because it isn't), but there are certain types of people who are a little (too?) obsessed with thinking of ways their logic can break and covering it with checks and tests… I'm guessing that designers are less likely to be one of those.
I love designers, btw. I think UI/UX is a hugely underrated discipline (see: "dark patterns", designing for safety). But unless you stare at logic all day, the implications of a code change like this might not immediately strike you as a risk.
I agree with you. Bugs happen, that's just the way it is.
But my issues with this aren't really related to code:
* downloading without user 'consent' (in the loosest sense of the word)
* and mainly: a proposed fix being a way the server can force an update on the user.
This whole issue just stems from the unreasonably high update-frequency imposed by the developer. They aren't addressing that and instead conclude that perhaps they can avoid a high bill by building remote code-execution into their app. As opposed to just adding a toggle and letting users decide whether they want updates to be auto downloaded. I would argue that's more of a UI/UX issue than a coding issue.
> Why download updates at all without the user knowing? Is prompting before downloading such an awful user experience in comparison? Or, you know, prompt once per day and add a 'remind me in x days/minutes' option?
Yeah, it's a pain in the neck. If I've got 20 bits of software on my PC and they all update once a month, then most days I'm going to get a random popup asking to update. Just get on and do it please.
That's fair. From the post my impression was that auto-update is forced, so users don't get a say in whether it can download in the background, if that's not the case then disregard that part of my comment.
> Screen Studio is a desktop app. It means we need some auto-updater
No, it doesn't. People used desktop apps perfectly fine before the always-on phone-home era of nearly universal broadband.
What's more troubling though is that this is somehow a story about monitoring cloud costs, and not a story about why your update interval was every five minutes instead of daily; or why it would auto-download instead of politely (no popups!) letting the user know there was an update; or why you failed to reconsider the fundamentals of your design in the face of the first round of negative feedback.
Your users told you they felt harassed and interrupted by your prompts. That's why you were making this change in the first place. That should have told you something.
User expectations have changed in this regard. If you don't auto update users will never update. Updating your computer or apps isn't a thing anyone thinks about anymore.
Don't do it like the OP clearly, and it's really sad that desktops can't provide an experience like mobile where updates are platform managed but you still gotta do it.
or in other words you normally want to integrate into existing update services, e.g. then package manager on linux. And if it then doesn't get updated e.g. because people don't update their system at all then that's their choice and problem IMHO. Just flag a warning/error once the API to your service changed too much or similar.
You mean no options except the Microsoft/Apple app store. And I think you also can hook into the Microsoft updated without being on the app store but not completely sure. And you can just use a existing auto updater library or similar instead of implementing it yourself ....
user expectation was never to update regularly. User expectation is a working application to continue function the same way until a change is required by the user.
Users should not have to update, applications should not auto-update unless asked specifically.
An update should be voluntary, not mandatory.
I hate finding a different application each time I open the same application. Particularly if it's a feature change or worse, a whole UI change.
This applies to desktop apps, saas apps, appliances, cars..
> user expectation was never to update regularly. User expectation is a working application to continue function the same way until a change is required by the user.
It does worry me that this may not be true anymore. How many years of the “slowly boiling frog” are necessary, with people growing increasing dependent on software they can’t control running only on others’ computers, before they forget what having locally-controlled software was like? How about young people or those who came to computers late in life who have known nothing different?
I’m increasingly resigned to the fact that the industry will wipe away this past. Old man “yells at cloud”, indeed.
> it's really sad that desktops can't provide an experience like mobile where updates are platform managed
What do you mean? There's an App Store for Mac users and there's the Windows Store for Windows users. I bet Linux has some similar offerings as well that I'm not aware of.
The services are there but developers have to jump through a bunch of (compliance) hoops (for good reasons) before they're accepted and it's easier to just let users download a ZIP from your landing page.
I would love if there was an "open" service that any app on the system could use to replace bespoke auto-updaters without having to be distributed via the store. Just like, "hi I'm $app, "run myapp.exe -check" to see if I have an update, and when either the user or the system decides to do the update run myapp.exe -update"
And then it's up to the OS that has more complete information to make decisions on when (i.e. don't check for updates on power saving mode).
That still requires every app to have a bespoke updater. You just pushed the invocation to the OS.
A better solution would be for the system package manager to allow programs to add their own update servers. Assuming the developers package their programs the same way the system does, this allows you to use the exact same update logic.
Most linuxes allow this. Add a third party repository to you sources, and you can update their software with the rest of your system.
Ideally, you would have a more locked down version, where you can restrict the permissions of a given repository; although I'm not aware of anyone that has done that yet
I feel like developer / publisher expectations are what changed, not the users’.
The allure of telemetry (even if it’s actually used for telemetry, not for nefarious spying and data collection) is just too much for most developers or publishers to resist. As somebody else said, these 5 minute update “pings” seem less, to me, about updates and more about near-realtime usage monitoring.
Exactly. I am actively developing a desktop app (https://didgets.com/). I have regular releases (every couple of weeks) that contain bug fixes and new features. While it would be nice if every user updated every time the new revision is posted; I don't expect that and other developers shouldn't either.
If it has been about 3 months since the user last updated; it will prompt the user to update to the latest version when the application starts (not some popup when they are in the middle of doing something important).
> People used desktop apps perfectly fine before the always-on phone-home era of nearly universal broadband.
Yes, and people used cars perfectly well before seatbelts. Except the people that died.
If your application is internet connected then you need a good update story so that (if nothing else) you can push out security updates. This is true of everything from embedded firmware to desktop apps.
Let me continue your mangled analogy of the connected car and ask: should a braking profile be auto updated while the car is hurtling down the road in traffic at 60 miles per hour in a torrential downpour? Should the cloud make that determination or the operator?
>> The app checks for the update every 5 minutes or when the user activates the app.
This is why I use Little Snitch, an application firewall that blocks requests like this and gives me some control over which applications are phoning home all the time. There’s no reason a desktop application should check for updates every 5 minutes. Once a month ought to do it without a compelling reason for more. But none of the lessons learned in the article show any attempt to reevaluate the update check frequency.
Why? Updates may or may not be to the benefit of the user, who should have a clear say in the time and place when their stuff is updated, nothing is more frustrating to have a job to do and then to sit there waiting for some silly update process to complete only to find out that (1) it doesn't matter to you anyway or (2) that they've borked the update or (3) that critical functionality you relied on has been removed or (4) that the marketing department thought this was a great time to try to upsell you on something.
Mandatory updates should only happen for critical security issues and even those don't need to be fixed on a five minute interval, once a day at most for a check and less frequently is probably fine as well unless the app is absolutely mission critical and people will die. And even then you should probably wonder if your QA is so bad that you need to be able to intervene on a moments notice, better to design your process in such a way that you can alert the user rather than to forcibly upgrade their system, especially if there is a chance that you'll get it wrong (again).
An upgrade is always a burden on the users, so you really don't want to do this too often and even if you are capable of releasing multiple updates per week it would be ridiculous to expect your users to follow that frequency.
In the past if there was an update for software I use I was excited and was curious about all the improvements it would bring. Now when I see some app has an update I have a feeling of dread as I am sure it will be slower, the UI more clumsy and the power features I like will surely be removed.
Especially if you are like Nextcloud client - just killing Explorer if you like so (without asking the user first) and then even rebooting the machine without asking user first.
It's a glorified sync client, why the hell it should behave like that?
This is trying to bring SaaS update frequency to the desktop. As both a SaaS user and SaaS developer, I think this is a big win. Why leave a bug open for a month, fix it the next day if it's serious.
Screen studio has gone through a period of incredibly rapid development with many new features and improvements, Adam has launched updates every day at times. So I can understand the motivation for at least a daily check.
However those rapid updates also increase the risk of a bug in a release, and so maybe a more regular update check is needed during that time?
Adam is also following the "build in public" marketing strategy, warts and all. It's worked very well, he has had massive growth in sales. The combination of building in public, a product that is "visual" and one that effectively advertises itself, is very clever.
If your background is web apps with CI, thinking you need a 5min update check interval is an easy trap to fall into.
I don’t use Little Snitch but the update frequency definitely struck me as insane. I cannot think of any consumer apps that need to check for updates once a day.
Sounds like a decision that could only be made by a company that believes their API will change often (or is for whatever reason worried about 0Ds) and without enough engineering headroom to handle versioning and translation layers correctly. It could greatly simplify a style of development that allows companies to move quickly without paying certain costs.
No. There is enough apps what I start, use and close. Why it should check the update every time it starts?
And this is even more irritating when the update check isn't working for some reason, eg update URI is not available but overall Internet works, now you sit there and wait while the update checker timeouts. Why, why?
It doesn't seem to be automatically installing the update, presumably as that would disrupt the user by restarting the app. I guess it's staging the update to run on exit or similar. So until the user actually quits the app (or clicks update etc.), it's going to be on the old version, and in this endless redownload loop.
Not a single mention of rate limiting? This isn't 2008, if you're offering an online service and do not have some form of rate limiting that will trigger when your throughput increases by 3 orders of magnitude, that's on you.
If you're using plain AWS S3 you can't reasonably add a rate limit - probably if you put some Lambda Edge function or Cloudfront in front of it, but that's unnecessary cost and complexity.
I think the approach for S3 is to have the app call a rate limted API to get the download URL, possibly as a pre-signed URL, possibly with an HTTP redirect. That doesn't help if the client caches that URL and downloads it from S3 directly many times. Alternatively, you could run your own update server, but S3 is so convenient.
There's also a concern that the update is designed to check every five minutes. So a rate limit may not actually get exceeded.
> you could run your own update server, but S3 is so convenient.
IMO if you're providing updates to your users you're distributing code automatically and potentially infecting their computers if anything goes wrong. You should take all proper precautions.
>> Normally, when the app detected the update - it downloaded it and stopped the 5 minutes interval until the user installed it and restarted it.
If I'm reading this correctly, the update mechanism stops if there is updated downloaded and waiting. So if user just doesn't install it, it will not get the versions after that?
Seems like whole logic might have more issues, beyond the basic uselessness.
Why the hell does the app check every 5min for updates?
Even once a day seems excessive.
Thy cynic in me sees a pattern of disregard for other people's resources like with electron. Being a good software citizen is also realising that the product is not the main task running on a computer and it's not acceptable to make decisions about other peoples priorities. It feels like every tray daemon and widget assumes they are the main reason the computer is running and load a web view, 3 windows services and scheduled tasks.
Admittedly the App in question is interactive, but the same principle holds.
Categorical imperative hah:
Construct in a way that you accept all tray icons to be constructed like.
It's more insidious than disregard, I expect. I assume it's a beacon masquerading as an update check - monitoring app usage, user locations, and such.
Aside: If your users are in the same time zone you may not want to do checks/updates on startup per se in order to avoid putting all your update load into the same time slice.
> Aside: If your users are in the same time zone you may not want to do checks/updates on startup per se in order to avoid putting all your update load into the same time slice.
This one bite my in the ass with a login used by IRL offices which all wanted to log in at 9:00 at the same time lol
> The problem with the auto-updater we had was that it would prompt the user to update the app as soon as it became available. This resulted in a popup appearing while users were recording the screen, which obviously provided a bad experience as it interrupted the recording the user was making.
The 5 minute bug was introduced while fixing this issue. But it was a bad one: I have so many apps "randomly" popping update notifications up all the time: Skype and Fantastical are the two worst, seemingly every day. The popups interrupt me when working, and _take keyboard focus_ meaning I lose the last half of a sentence, or sometimes even dismiss the dialog before I realise it's appeared.
> the product is not the main task running on a computer and it's not acceptable to make decisions about other peoples priorities
Yes! One thing I loved about early macOS (about OS X Tiger - Snow Leopard days) was that I never saw apps steal focus. On Windows at the time it happened all the time in various ways, but never on Mac. That included when apps started: if you were working in an app and started another but kept working in the first, the second started with the window in the background. It was lovely.
The fact that macOS allows apps to steal focus, with no obvious way to stop it, annoys the hell out of me. That it is apparently new-ish behavior is baffling.
Further: the two biggest productivity boosters macOS could add for me are:
1. Prevent focus stealing (again)
2. Probably more in Sparkle than macOS itself: apps today update constantly. I think it comes from web apps where you can deploy an update and people get it without realising, but updating a desktop app causes an interruption, so it shouldn't happen nearly as often. You end up with multiple apps during the day asking for updates. Apple tried to solve this through the App Store but many apps don't use it and use their own update mechanism, usually Sparkle.
So the Sparkle framework should collect all apps wanting to update and show a single notification (not a popup, a notification) once a day. Clicking it would show all apps that want to update. If you want to read release notes etc, you can there. But a single, centralised, shown via notifications not popups update mechanism for all Sparkle-enabled apps would be a _huge_ boost.
> Yes! One thing I loved about early macOS (about OS X Tiger - Snow Leopard days) was that I never saw apps steal focus. On Windows at the time it happened all the time in various ways, but never on Mac. That included when apps started: if you were working in an app and started another but kept working in the first, the second started with the window in the background. It was lovely.
Good point, when did Mac OS lose that? It's insulting if you know how it used to be.
Another concern, and this could be an Electron issue, why doesn't it download the file to a cache and then skip the download on subsequent checks? I wonder how this behaves on flaky internet access; does it restart the download instead of resuming?
> Why the hell does the app check every 5min for updates?
Part of it is just incompetence. Bootcamp dev is used to coding web apps where the code just gets to the client's machine every time (10 mb single page apps). When they transition to Electron, because it works with the same web tech they memorized, they see nothing wrong with doing these frequent updates.
Part of that is why I don't hate the idea of App Stores on desktop to distribute programs; The store can handle checking for update once per day instead of every app implementing it's own logic.
There are all sorts of circumstances, see also international travel, when unintentional downloads can get really expensive and it's not reasonable to expect people to police how and when they use data at a micro level. I'd much rather pester people to give permission for things than just download in the background because that's "probably what they want."
I think this post backfired at the writer. While trying to provide transparency over a problem (we all screw up) it uncovered what I think it's a horrible idea.
The issue is not the bug anymore but the update process.
These comments in HN might provide much more insights than the bug itself.
I hate this aspect of modern computing…Time was, you could look over at your firewall, or notice that the local network was running like crap…but Google (and for this post, Comcast/Xfinity) have GOBS of capacity. It’s easy to manage costs when your bandwidth is constrained to a relatively low rate…
That super high speed 1Gb fiber connection? The one that STILL has the 1Tb/Mo cap? You can blow through it in an afternoon with one poorly constrained app (e.g. Torrenting)
Same here. Google has _company ending_ amounts of bandwidth in their datacenters and you can lose everything without knowing it.
I think there is a problem here, but I don't think think that's the right problem. Not having these arbitrary technical limits is a good thing - for instance their service didn't degrade due to an unrelated problem. Regulating cost indirectly via some other metric is a very oblique way of solving the problem
The right solution would be throttling of spending - easy way to set proper limits, good notifications etc. It's possible to set up all these limits but nowhere near as easy as it should be. Also, how easy would it be for Google to send you an email saying "your spend looks a bit different than normal due to this traffic here"!
From personal experience, paying Xfinity an extra $30 or so per month to get the cap taken off was one of the first "upgrades" I made to my internet. Between me pulling node_modules for multiple projects and watching Netflix, I usually blow through the 1TB cap in the first 10 or so days.
I have an unlimited plan (Cox) and they've threatened to terminate me before during a period of high usage. (I was initializing an off-site backup.) Vague language about QoS for other customers in their terms of service, so at their discretion.
- Why check every 5 minutes? It's not like anyone will die if you wait a day to upgrade.
- Why download it without user confirmation. This is the worst one.
- The timer should not be stopped, or the user is forced to install the last downloaded update before they can install the latest.
It seems unwarranted to go to so much trouble for a screen recorder app, when just checking for an update at startup and prompting the user to go to the website would have been enough.
141 comments
[ 4.0 ms ] story [ 222 ms ] threadAdditional feedback on HN about checking even less often, getting user consent, and writing regression tests but commentators are being dramatic and insulting about it.
This is how you deal with a situation like this that you’ve caused. Accidents happen, what matters is how you clean up after.
The whole take-away of this article feels backwards. Instead of going 'hey maybe we should not just download stuff in the background without prompt', the author doubles down and actually proposes to add a way for the server to signal to the client that an update should be forced.
I'm actually baffled by this entire thing.
>The app checks for the update every 5 minutes or when the user activates the app.
>Normally, when the app detected the update - it downloaded it and stopped the 5 minutes interval until the user installed it and restarted it.
To me this reads as them downloading the update unprompted (as they mention their issue with the previous updater was that it would prompt the users every 5 minutes, which would be solved by just not checking every 5 minutes).
Either way, whatever the bug and its effects are, my gripe is that their conclusion is to add a way for them to remotely force-updates. As opposed to just notifying once or any of the other hundred ways to handle auto-updates that don't involve you remotely forcing an update.
Edit: the founder has confirmed in the comments the app does download without user confirmation, so my original point still stands.
That's in contrast to being interrupted twice (once to download, then again to restart) or a single long interruption (shutting down, then downloading, then restarting).
Of course, it's a different matter if the user doesn't want the update. But we developers don't like to think about that :)
Oof, imagine you're using the app to demo something and bam update Lol
But also: a check every 5 minutes? I understand what you're saying but the only reason those interruptions are frustrating is because of the high volume of daily updates. This could be solved by just keeping this update-frequency reserved for beta users and maintaining a more sane update-frequency for regular users (now what a sane update-frequency is, is a whole other discussion judging by the comments so far :P)
Now I’m not saying coding is rocket science (because it isn't), but there are certain types of people who are a little (too?) obsessed with thinking of ways their logic can break and covering it with checks and tests… I'm guessing that designers are less likely to be one of those.
I love designers, btw. I think UI/UX is a hugely underrated discipline (see: "dark patterns", designing for safety). But unless you stare at logic all day, the implications of a code change like this might not immediately strike you as a risk.
But my issues with this aren't really related to code: * downloading without user 'consent' (in the loosest sense of the word) * and mainly: a proposed fix being a way the server can force an update on the user.
This whole issue just stems from the unreasonably high update-frequency imposed by the developer. They aren't addressing that and instead conclude that perhaps they can avoid a high bill by building remote code-execution into their app. As opposed to just adding a toggle and letting users decide whether they want updates to be auto downloaded. I would argue that's more of a UI/UX issue than a coding issue.
Yeah, it's a pain in the neck. If I've got 20 bits of software on my PC and they all update once a month, then most days I'm going to get a random popup asking to update. Just get on and do it please.
No, it doesn't. People used desktop apps perfectly fine before the always-on phone-home era of nearly universal broadband.
What's more troubling though is that this is somehow a story about monitoring cloud costs, and not a story about why your update interval was every five minutes instead of daily; or why it would auto-download instead of politely (no popups!) letting the user know there was an update; or why you failed to reconsider the fundamentals of your design in the face of the first round of negative feedback.
Your users told you they felt harassed and interrupted by your prompts. That's why you were making this change in the first place. That should have told you something.
Don't do it like the OP clearly, and it's really sad that desktops can't provide an experience like mobile where updates are platform managed but you still gotta do it.
there needs to be some auto updater
but you don't necessary need to have some
or in other words you normally want to integrate into existing update services, e.g. then package manager on linux. And if it then doesn't get updated e.g. because people don't update their system at all then that's their choice and problem IMHO. Just flag a warning/error once the API to your service changed too much or similar.
If you're not on a Linux distro then you have neither hence the auto-updaters.
Users should not have to update, applications should not auto-update unless asked specifically.
An update should be voluntary, not mandatory.
I hate finding a different application each time I open the same application. Particularly if it's a feature change or worse, a whole UI change.
This applies to desktop apps, saas apps, appliances, cars..
It does worry me that this may not be true anymore. How many years of the “slowly boiling frog” are necessary, with people growing increasing dependent on software they can’t control running only on others’ computers, before they forget what having locally-controlled software was like? How about young people or those who came to computers late in life who have known nothing different?
I’m increasingly resigned to the fact that the industry will wipe away this past. Old man “yells at cloud”, indeed.
I hate security updates that has zero impact on my use case to be applied automatically.
Like a fix for amd64 arch applied for an app currently only running on arm64.
What do you mean? There's an App Store for Mac users and there's the Windows Store for Windows users. I bet Linux has some similar offerings as well that I'm not aware of.
The services are there but developers have to jump through a bunch of (compliance) hoops (for good reasons) before they're accepted and it's easier to just let users download a ZIP from your landing page.
And then it's up to the OS that has more complete information to make decisions on when (i.e. don't check for updates on power saving mode).
A better solution would be for the system package manager to allow programs to add their own update servers. Assuming the developers package their programs the same way the system does, this allows you to use the exact same update logic.
Most linuxes allow this. Add a third party repository to you sources, and you can update their software with the rest of your system.
Ideally, you would have a more locked down version, where you can restrict the permissions of a given repository; although I'm not aware of anyone that has done that yet
For decades before there was an app store and a windows store, yes.
I feel like developer / publisher expectations are what changed, not the users’.
The allure of telemetry (even if it’s actually used for telemetry, not for nefarious spying and data collection) is just too much for most developers or publishers to resist. As somebody else said, these 5 minute update “pings” seem less, to me, about updates and more about near-realtime usage monitoring.
If it has been about 3 months since the user last updated; it will prompt the user to update to the latest version when the application starts (not some popup when they are in the middle of doing something important).
Yes, and people used cars perfectly well before seatbelts. Except the people that died.
If your application is internet connected then you need a good update story so that (if nothing else) you can push out security updates. This is true of everything from embedded firmware to desktop apps.
This is why I use Little Snitch, an application firewall that blocks requests like this and gives me some control over which applications are phoning home all the time. There’s no reason a desktop application should check for updates every 5 minutes. Once a month ought to do it without a compelling reason for more. But none of the lessons learned in the article show any attempt to reevaluate the update check frequency.
Especially in a case like screen studio where it's under active development.
Mandatory updates should only happen for critical security issues and even those don't need to be fixed on a five minute interval, once a day at most for a check and less frequently is probably fine as well unless the app is absolutely mission critical and people will die. And even then you should probably wonder if your QA is so bad that you need to be able to intervene on a moments notice, better to design your process in such a way that you can alert the user rather than to forcibly upgrade their system, especially if there is a chance that you'll get it wrong (again).
An upgrade is always a burden on the users, so you really don't want to do this too often and even if you are capable of releasing multiple updates per week it would be ridiculous to expect your users to follow that frequency.
Especially if you are like Nextcloud client - just killing Explorer if you like so (without asking the user first) and then even rebooting the machine without asking user first.
It's a glorified sync client, why the hell it should behave like that?
However those rapid updates also increase the risk of a bug in a release, and so maybe a more regular update check is needed during that time?
Adam is also following the "build in public" marketing strategy, warts and all. It's worked very well, he has had massive growth in sales. The combination of building in public, a product that is "visual" and one that effectively advertises itself, is very clever.
If your background is web apps with CI, thinking you need a 5min update check interval is an easy trap to fall into.
At startup is perfectly fine. Then once every 24 hours later if the app hasn't exited is also perfectly fine.
More often than that is too often. Every 5 minutes? That's ridiculous.
No. There is enough apps what I start, use and close. Why it should check the update every time it starts?
And this is even more irritating when the update check isn't working for some reason, eg update URI is not available but overall Internet works, now you sit there and wait while the update checker timeouts. Why, why?
There's also a concern that the update is designed to check every five minutes. So a rate limit may not actually get exceeded.
> you could run your own update server, but S3 is so convenient.
IMO if you're providing updates to your users you're distributing code automatically and potentially infecting their computers if anything goes wrong. You should take all proper precautions.
If I'm reading this correctly, the update mechanism stops if there is updated downloaded and waiting. So if user just doesn't install it, it will not get the versions after that?
Seems like whole logic might have more issues, beyond the basic uselessness.
BTW, in our team we compiled a spreadsheet showing Git commits before and after security audit reports [1].
[1] https://docs.google.com/spreadsheets/d/1bqtQI05z-O6uclvYYXxH...
Even once a day seems excessive.
Thy cynic in me sees a pattern of disregard for other people's resources like with electron. Being a good software citizen is also realising that the product is not the main task running on a computer and it's not acceptable to make decisions about other peoples priorities. It feels like every tray daemon and widget assumes they are the main reason the computer is running and load a web view, 3 windows services and scheduled tasks.
Admittedly the App in question is interactive, but the same principle holds.
Categorical imperative hah:
Construct in a way that you accept all tray icons to be constructed like.
Aside: If your users are in the same time zone you may not want to do checks/updates on startup per se in order to avoid putting all your update load into the same time slice.
This one bite my in the ass with a login used by IRL offices which all wanted to log in at 9:00 at the same time lol
The 5 minute bug was introduced while fixing this issue. But it was a bad one: I have so many apps "randomly" popping update notifications up all the time: Skype and Fantastical are the two worst, seemingly every day. The popups interrupt me when working, and _take keyboard focus_ meaning I lose the last half of a sentence, or sometimes even dismiss the dialog before I realise it's appeared.
> the product is not the main task running on a computer and it's not acceptable to make decisions about other peoples priorities
Yes! One thing I loved about early macOS (about OS X Tiger - Snow Leopard days) was that I never saw apps steal focus. On Windows at the time it happened all the time in various ways, but never on Mac. That included when apps started: if you were working in an app and started another but kept working in the first, the second started with the window in the background. It was lovely.
1. Prevent focus stealing (again)
2. Probably more in Sparkle than macOS itself: apps today update constantly. I think it comes from web apps where you can deploy an update and people get it without realising, but updating a desktop app causes an interruption, so it shouldn't happen nearly as often. You end up with multiple apps during the day asking for updates. Apple tried to solve this through the App Store but many apps don't use it and use their own update mechanism, usually Sparkle.
So the Sparkle framework should collect all apps wanting to update and show a single notification (not a popup, a notification) once a day. Clicking it would show all apps that want to update. If you want to read release notes etc, you can there. But a single, centralised, shown via notifications not popups update mechanism for all Sparkle-enabled apps would be a _huge_ boost.
Good point, when did Mac OS lose that? It's insulting if you know how it used to be.
The absolute worst are the ones that steal it while running in the background, unpredictably and with no visible UI.
[1]: https://superuser.com/questions/734007/how-do-i-tell-which-a... [2]: https://apple.stackexchange.com/questions/123730/is-there-a-...
Part of it is just incompetence. Bootcamp dev is used to coding web apps where the code just gets to the client's machine every time (10 mb single page apps). When they transition to Electron, because it works with the same web tech they memorized, they see nothing wrong with doing these frequent updates.
Part of that is why I don't hate the idea of App Stores on desktop to distribute programs; The store can handle checking for update once per day instead of every app implementing it's own logic.
The issue is not the bug anymore but the update process.
These comments in HN might provide much more insights than the bug itself.
That super high speed 1Gb fiber connection? The one that STILL has the 1Tb/Mo cap? You can blow through it in an afternoon with one poorly constrained app (e.g. Torrenting)
Same here. Google has _company ending_ amounts of bandwidth in their datacenters and you can lose everything without knowing it.
(See also medical billing)
The right solution would be throttling of spending - easy way to set proper limits, good notifications etc. It's possible to set up all these limits but nowhere near as easy as it should be. Also, how easy would it be for Google to send you an email saying "your spend looks a bit different than normal due to this traffic here"!
But yes, Google and others should implement a cap.
My dislike of ISPs is evergreen.
- Why check every 5 minutes? It's not like anyone will die if you wait a day to upgrade.
- Why download it without user confirmation. This is the worst one.
- The timer should not be stopped, or the user is forced to install the last downloaded update before they can install the latest.
It seems unwarranted to go to so much trouble for a screen recorder app, when just checking for an update at startup and prompting the user to go to the website would have been enough.
Why isn't checking once a day / week enough?
And... code review?
Relying on code review is a dangerous game because fine looking code can be riddled with bugs.
Seeing as it's macOS only is there even any reason to roll your own update mechanism when you can use the Sparkle framework [1]?
[1]: https://sparkle-project.org/
That is the actual bug.