Hacker News Reader

App store updates are perfect: no unnecessary complications, no unnecessary work (assuming Screen Studio is published and properly updated in the app store), and the worst case scenario is notifications about a new Screen Studio version ending up in a Screen Studio recording in progress.

Thinking of it, the discussed do-it-yourself update checking is so stupid that malice and/or other serious bugs should be assumed.

Exactly. The AppStore already exists and does updates (either automatically or manually, configurable by the user). The developer didn't have to lift a finger to get this functionality. Imagine sitting down and spending time adding functionality to your application that is already provided for free by the operating system, and then after all that, doing it incorrectly!

Starting from the paid developer accounts, the Apple app store isn't "provided for free by the operating system" and it is a source of endless busywork, fear and suffering, but the argument stands: a professional Macintosh software vendor uses the app store because Macintosh users expect it, so it can be assumed that "properly" publishing new software version to the app store is a sunken cost that should be made as useful as possible.

By "provided for free" I mean the App Store comes with the OS, costs nothing (monetarily) to the developer over the existing annual Apple Developer Program fee, which pretty much all macOS developers pay anyway, and can be counted on to exist on all macOS installations.

Yeah no, publishing to the App Store is a nightmare in cost and time. I can 100% guarantee they still saved money on 30% fees even after this $8000 snafu.

Screen Studio has 32k followers, lets say 6% are end users, 2000 users at $229, that is $137k in App Store fees.

I am going to say writing your own app update script is a wash time wise, as getting your app published is not trivial, especially for an app that requires as many permissions as screen studio.

Some people don’t like using the AppStore. I like to keep backups of installers so I can control the version. And if it gets pulled from the AppStore, I’ll always have a copy.

> malice and/or other serious bugs should be assumed

Going back to the blog post and re-reading it with this possibility in mind is quite a trip.

> It turns out thousands of our users had the app running in the background, even though they were not using it or checking it for weeks (!). It meant thousands of users had auto-updater constantly running and downloading the new version file (250MB) over and over again every 5 minutes

This could easily have been data exfiltration from client computers instead, and few (besides the guy whose internet contract got cancelled for heavy traffic) would have noticed.

I find the misbehavior of indie/boutique MacOS apps always insisting on starting at login very irritating. Unless the app needs to run some heavy background preparation steps before becoming usable, there is literally no sense it starting at login. Also when dormant, check for update(once every 24h), and nag the user if they want to update, but please do not auto download! A lot of non-tech folks use 128/256GB versions of macbook with trillions of photos already clogging their device, an app downloading new updates to add to the pain unless the user asks to do so is outright malice.

While we're listing complaints... 250MB for a screen recorder update?

And even when nothing changed?!? Fucking lazy developers aka "I have an idle ≥1Gb/s pipe to the download server". What happened to rsync/zsync/zstd (with dictionary)? There are so many good tools freely available to reduce wasted bandwidth when you insist on reinventing the wheel. sigh

I'd like to point out https://www.daemonology.net/bsdiff/ as a good, free, option for delta updates.

That’s pretty much the floor for an Electron app.

If you’re a small shop or solo dev, it is real hard to justify going native on three platforms when electron gives it for (near) free. And outside of HN, no one seems to blink at a 250MB bundle.

There are alternatives like Tauri that use the system browser and allow substantially smaller bundles, but they’re not nearly as mature as Electron, and you will get cross platform UI bugs (some of which vary by user’s OS version!) from the lack of standardization.

This app is Mac-only, which makes the choice to use Electron a little confusing.

That is… surprising.

I’d actually seen this project before because the author did a nice write up on using React portal to portal into electron windows[1], which is something I decided to do in my app.

I’d just assumed his was a cross platform project.

1: https://pietrasiak.com/creating-multi-window-electron-apps-u...

> And outside of HN, no one seems to blink at a 250MB bundle.

I can remember when I would have to leave a 250MB download running overnight.

Before that, I can remember when it would have filled my primary hard drive more than six times over.

... Why can't the app-specific code just get plugged into a common, reusable Electron client?

You mean like WebKit which Tauri uses?

I go into more detail in a sibling comment, but Tauri does not provide a standardized web runtime. The webview you get depends on your OS and OS version. They’re all “WebKit”, but definitely do not all render the same. I have built a Tauri app and switched to Electron after encountering multiple x-plat rendering bugs.

Different versions of electron bundle different versions of chromium. There can/will be rendering differences between them.

Tauri is an alternative framework that uses whatever web view the OS provides, saving ~200mb bundle size. On Mac that’s a (likely outdated) version of Safari. On Windows it’ll be Edge. Not sure what Linux uses, I’d guess it varies by distro.

The promise of Electron (and it’s an amazing value prop) is that your HTML/JS UI will always look and work the same as in your dev environment, no matter what OS the host is running.

I don’t have the time or inclination to test my app on the most recent 3 releases of the most popular operating systems every time I change something in the view layer. With Electron, I trade bundle size for not having to do so.

I do think alternatives like Tauri are compelling for simple apps with limited UI, or where a few UI glitches are acceptable (e.g. an internal app). Or for teams that can support the QA burden.

> And outside of HN, no one seems to blink at a 250MB bundle.

Please, many people connect to the internet via a mobile phone hotspot, at least occasionally.

This bug would likely cause you to go through your entire monthly data in a few hours or less.

I’m not excusing this bug. There are several poor decisions that went into this issue, but my contention is that using electron (with the resulting 250mb bundle) is not one of them.

You should probably not roll your own auto-updater.

If you do, checking every 5 minutes for updates is waaaay too often (and likely hurts battery life by triggering the radio).

And triggering a download without a user-prompt also feels hostile to me.

The app size compounds the problem here, but the core issue is bad choices around auto-updating

> And outside of HN, no one seems to blink at a 250MB bundle.

Except like 1 or maybe 2 billion people with slow or expensive internet.

Screen recorder under 100 bytes: ffmpeg -video_size 1024x768 -framerate 25 -f x11grab -i :0.0+100,200 output.mp4

you're not their target audience

does that work on MacOS?

No, but cmd+shift+5 does.

TIL

Yes, but command is different: https://trac.ffmpeg.org/wiki/Capture/Desktop

Screen recorder in under 100 bytes:

Open QuickTime and hit Command-Shift-N. Press record.

Screen recorder in 0 bytes: open camera app on phone and hit record.

Last time I checked, statically built ffmpeg was 100 MB, at least on Linux.

18.4MB compressed[1].

FWIW the transitive dependencies of the nixOS ffmpeg add up to 764MB, but dynamically linking is always much larger than statically linking, and that calculation will include more than just the shared-libraries.

Also note that he app includes an ffmpeg that is 39MB uncompressed.

1: https://johnvansickle.com/ffmpeg/ (based on the arm64 build, since TFA is an arm64 app).

Per [1] That would be 39MB (uncompressed; probably about half that compressed) to include ffmpeg-darwin-arm64, since OS X doesn't ship with ffmpeg installed.

1: https://news.ycombinator.com/item?id=43839120

As a user I hate auto updates. It feels like someone pulling the rug from under me.

Does the app store handle staged rollouts?

That was a thing I thought was missing from this writeup. Ideally you only roll up the update to a small percent of users. You then check to see if anything broke (no idea how long to wait, 1 day?). Then you increase the percent a little more (say, 1% to 5%) and wait a day again and check. Finally you update everyone (who has updates on)

Yes it does support this

yes obviously something as mature as the App store supports phased rollout. I believe it is even the default setting once you reach certain audience sizes. Updates are always spread over 7 days slowly increasing the numbers

> Wouldn't app store be perfect way to handle updates

But then the HN crowd would complain "why use an app store? that's gate keeping, apple could remove your app any day, just give me a download link, and so on..."

You literally can't win.

You can? Don’t check for updates every 5 minutes. Daily or even weekly would be sufficient for an app like this (if auto-updater is even necessary at all.. just show a notification)