It seems as though a lot of arguments about this boil down to a few inane implications:
1. Apple should test every (common?) app and any change to the OS that they make that makes an app worse shouldn't be done regardless of why they wanted to make that change.
2. Even though Apple tells people not to use private APIs, if a program uses a private API anyway Apple should build a workaround into their OS instead of letting apps suffer their own repercussions.
3. Apple should test everything ahead of time and then go around telling all the app developers that there's a problem, as if those app developers are going to do anything about it.
No matter what Apple did here, their actual choices boiled down to:
1. Add workarounds for misbehaving broken apps, giving those apps no incentive to fix their issues, and forcing Apple to support those workarounds indefinitely; this also undermines their "don't use private APIs, they could break later" position. This is the kind of thing that made Windows into an unmaintainable sack of cruft.
2. Do what they did, which is change the API and let broken apps be broken to the user's detriment. Everyone blames Apple even though it's objectively not their fault.
2. Add some kind of non-workaround that caused problems for the app and not the user; e.g. have this private API rate limited or something so that the app ends up blocking in the call. Could cause problems for actual consumers of this API, and people would still blame Apple but in this case it would be more of their fault than option 2.
In the end, Apple can't spend their time fretting over what bad developers do wrong; they spend their time on their OS and software and if a developer writes bad software and causes problems then so be it.
I think testing the top 10 projects in a few verticals is a pretty reasonable thing. For my open source projects I do this kind of basic QA against their top users.
Then the bugs could be reported to the various app developers, and they would have been able to get some notice. Many would have acted on it. Many of the top apps have dedicated Apple contacts already. Seems like a completely reasonable expectation?
4. push Gatekeeper-blacklist entries for the broken (bundle ID, version) pairs of these apps (even if those are the current versions!) — such that when the user goes to open them, they just get a dialog reporting the app as being "not compatible with this Mac, and should be moved to the Trash."
I seem to recall from past reading of the AppKit source code that one solution to (1) was to have version specific workarounds that worked for e.g. RecklessApp 39, but would no longer work for RecklessApp 40. I assume that the developers in question were informed of the fact, and now had every incentive to fix the problem.
Apple really should investigate why so many popular apps are implemented using Electron. Is it that hard to use the native APIs now? If so, Apple needs to improve the native application development experience. The UX on these apps is terrible and should be embarrassing for all involved.
Electron isn't popular because SwiftUI sucks (although both statements can be true at the same time) it's because big shops have decided that it's not worth the cost to develop native UIs on each platform anymore, so the only way they've decided we will get "native" apps is via Electron.
If electron didn't exist, it would be QT, or we'd only see native apps on Windows like the old days, and nothing at all on macOS and Linux (or just web apps).
It's not a tech issue but a cultural/management problem.
Personally I try to avoid Electron apps as much as possible, but it's pretty much unavoidable now. Docker Desktop, Bitwarden, 1password, slack, VSCode, dropbox, GitHub Desktop, Obsidian, Notion, Signal, Discord, etc. All the major apps are electron. Even in the Windows world Microsoft stopped making native and makes heavy use of their own version of Electron (EdgeWebView2) for their own apps. The freaking start menu is react native ffs.
The industry has lost its collective mind in favor of being able to hire cheap javascript talent
The other reason is that many of the companies that ship Electron apps are web-first companies. Slack, Discord, VSCode, Github, and Notion were all solely web apps at first — some for years — before any native app was released.
To these companies, a "native app" is just "a web app with its own start-menu icon, no browser chrome, and access to OS APIs."
(In other words: if PWAs had access to all the same OS APIs that Electron does, then these companies wouldn't ship native apps at all!)
I have written applications for macOS in Objective-C and remain a Swift skeptic. Maybe the language has more serious design behind it now. I don’t know. As much as I hate JavaScript, maybe it is time for Apple to provide a JavaScript API or their own official Electron layer. I really hate how Electron apps don’t use the same text input field as the rest of macOS.
That's sort of the route Microsoft went with EdgeWebView2.
Swift itself is great and stable enoug now. I really like the language. SwiftUI though still needs work and is still missing functionality that you have to fall back on AppKit for so there's tons of bridges to embed AppKit views in your SwiftUI hierarchy (like NSTextView still relies on AppKit, as does some drag and drop functionality) so at a certain point you might as well just continue using AppKit.
Apple introduced an entirely new language and UI framework to make it easier, Swift and SwiftUI respectively. They have tutorials, classes, thousands of example projects, playgrounds, videos, and documentation. No, it’s not hard at all.
But very few users seem to care about performance or polish, so why not save a few bucks and build your desktop software with some cheap JavaScript devs?
1. Apple should test every (common?) app and any change to the OS that they make that makes an app worse shouldn't be done regardless of why they wanted to make that change. 2. Even though Apple tells people not to use private APIs, if a program uses a private API anyway Apple should build a workaround into their OS instead of letting apps suffer their own repercussions. 3. Apple should test everything ahead of time and then go around telling all the app developers that there's a problem, as if those app developers are going to do anything about it.
No matter what Apple did here, their actual choices boiled down to:
1. Add workarounds for misbehaving broken apps, giving those apps no incentive to fix their issues, and forcing Apple to support those workarounds indefinitely; this also undermines their "don't use private APIs, they could break later" position. This is the kind of thing that made Windows into an unmaintainable sack of cruft.
2. Do what they did, which is change the API and let broken apps be broken to the user's detriment. Everyone blames Apple even though it's objectively not their fault.
2. Add some kind of non-workaround that caused problems for the app and not the user; e.g. have this private API rate limited or something so that the app ends up blocking in the call. Could cause problems for actual consumers of this API, and people would still blame Apple but in this case it would be more of their fault than option 2.
In the end, Apple can't spend their time fretting over what bad developers do wrong; they spend their time on their OS and software and if a developer writes bad software and causes problems then so be it.