Release builds without embedded swift libraries

[lwouis]

Switch 5 is natively supported starting with macOS 10.15. This means there is no need to embed the 10-12MB of Swift support files for uses on that OS or later.

See more details here

On the Mac AppStore there is app thinning: the app is thinned depending on the environment of the use downloading it. I'm not sure how we are supposed to handle this outside the MAS. Maybe having multiple downloads for each OS version? It may be possible to guide the user by making some web frontend with some JS detecting their OS and suggesting the best download for them. Hopefully Github Pages supports that. I need to double-check.

It would be nice in general having a more accessible download page anyway. Github releases is pretty unwelcoming for non-developpers

[lwouis]

Migrating to Swift 5 is just changing the language setting from 4.2 to 5. No other action is required 👍

I experimented, and indeed, the Swift libraries are no longer embedded in the build starting from 10.14.4:

I'm worried about providing the benefits of a build targeting a more modern OS version (i.e. smaller app, better performance) vs the issues with dealing with multiple builds. Here are some issues that worry me:

• CI has to build 2 times now. Longer CI builds, more potential for issues
• The UX for end-users is now confusing. How do we communicate the 2 options effectively. This requires Improve the landing page #211 to have browser user-agent detection to help suggest the best build, with a fallback to manual selection
• Auto-updates with Sparkle: how would we handle this? Update: seems like there is a reasonable way with minimumSystemVersion
• How to handle homebrew? I imagine they have solutions for this scenario

[gingerr]

Why just not drop support for older OS versions? I think with the usage of the private APIs it could become painful to support/test/dev and also build now for multiple OS versions.

[lwouis]

Why just not drop support for older OS versions?

Dropping support for older OS versions = dropping support for some people. The end-goal of this app is to be useful to as many people as possible. For this reason, I take compatibility very seriously. I would only remove backwards compatibility for a very large benefit. Here reducing the app size is not worth it for me. I would rather support 2 distribution channels and deliver an optimized builds for people on newer versions, rather than distribute only 1 build for them, and drop support for everyone else.

[lwouis]

I think this will not happen. We could have multiple builds for specific platforms, but for now 1 fat build wins. It's easier to maintain, distribute, document, and is more portable, less surprising for users.