People are allergic to articles and documentation generated/processed by LLM.

You're switching from an active role to a passive one, meaning your skill will suffer over the time. There is a huge difference between doing the things and thinking you know what it's doing. It's harder to review bad generated code because how polished it looks, compared to code made by humans where the difference is much more obvious.

Code assistants seem to work great when dealing with boilerplate, but wouldn't be better to get rid of the need for the boilerplate in the first place?

Seems a better choice to just parse the files than using private APIs as I couldn't see much of the documentation for them (or rather reversed APIs in various projects) + image handling is weirdly complicated in macOS generally so I want to avoid that.

Currently I've experimented by just recreating the graphics from scratch using vector rendering but it's quite cumbersome.

Other libraries, such as Qt, try to draw the native widgets into offscreen image but it's extremely hacky way prone to GUI breaking with any OS update. Java has their own Apple blessed way, but seems quite limited to me and don't want to depend on that either.

I've used Borland C++ and Watcom C/C++ back in the day and MinGW after that. Also COM was invented for interoperation between languages/compilers.

Being a good citizen means to not use the inherently unstable C++ ABI directly. You can use C API or even COM for that. Relying on it is cute but it's accidental and it will break in the future. Microsoft can't guarantee that it will stay stable because C++ is always evolving, forcing to break the compatibility.

Open source projects shouldn't depend on proprietary compilers (they can support them, but not as the only option). It just undermines the purpose of it.

The reasons I use MinGW is because it produces better compatible binaries on Windows, allowing me to support all Windows versions from Windows 2000 to latest with a single binary (and sometimes 64bit if there is a need/advantage) and it doesn't require me to bundle dozens of DLLs (or worse, installing them system-wide) and artifically limit the compatibility for no reason.

Breaking the compatibility is hostile to the users who can't or want to always use the latest Windows.

I never had issues with C ABI, calling into other DLLs, creating DLLs, COM objects, or whatever. I fail to see what is fundamentally incompatible here.

A major part of the incompatibility with older versions of Windows is just because newer VS runtimes cut the support artifically. That's it. Many programs would otherwise work as-is or with just a little help.

I don't understand how open source projects can insist on requiring a proprietary compiler.

Additionally the cross-compiler on Linux also produces binaries with no extra runtime requirements.

This is typically not done, only certain parts such as handling of the crypto keys. That's because it's pervasive and requires reworking everything with that in mind (TLS library, web framework, application).

On the other hand the centralization and global usage of GC in the process allows to modify it to always zero out the memory that it deallocated and to do GC at regular intervals so it can have advantage here (it's very easy to inadvertly leak the secrets to some string).

Another approach was Transmeta where the target ISA was microcoded, therefore done in "software".

Not only is such signing all about control (the Epic case is a great example of misuse and a reminder that anyone can be blocked by Apple) it is also anti-competitive to other programming languages.

I treat each platform as open only when it allows running unsigned binaries in a reasonable way (or self-signed, though that already has some baggage of needing to maintain the key). When it doesn't I simply don't support such platform.

Some closed platforms (iOS and Android[1]) can be still supported pretty well using PWAs because the apps are fullscreen and self-contained unlike the desktop.

[1] depending on if Google will provide a reasonable way to run self-signed apps, but the trust that it will remain open in the future is already severely damaged

In one application I also offered an alternative by using a web app in case they were not comfortable with any of the option.

Also it's presented in a .dmg file where you have two icons, the app and the "How to install". I would say that's quite inviting for investigation :)

Another alternative would be to bundle this app: https://github.com/alienator88/Sentinel

It allows to easily unlock it by drag'n'drop.

My favorite thing is them cooperating against a common enemy (a dog that was eating their food sometimes, which we've tried to mitigate but not being much successful).

Then once they had a discussion in the opposite corner about the problem and launched a stealth attack, covering themselves behind the trees while approaching the dog without the dog knowing it. Then once close enough they attacked from behind, the dog squeaked, more from the surprise than pain and since then the dog never touched their food again and avoided them.

You have to trust native apps, as it always was the case. You can't just install random apps. You can delegate the trust to a curated lists of apps that you trust.

Or you can just use the web apps, but then you have to trust them too (so they don't misuse information about you or your data for example). But then it can't integrate with anything and many features are simply not available.

As for your example, a photo editor could need a network connection when it contains collaborative features. Or an auto-update system. Or downloading of assets on demand. Or cloud AI feature. Or list of add-ons to install. Or for license checks. Or online help/docs. Or whatever.

Before it was unclear so it was better to allow installation of apps without any verification to appear as more open.

Remember any regulation/law has unintended consequences. At one point Apple decided that PWAs would no longer be supported in EU so they don't have to provide equal capabilities to implement them in alternative web browsers, fortunatelly they changed their mind by obtaining an exception. PWAs is the only alternative choice for making "proper" apps on iOS (no hacky sideloading methods).

I think overally DMA is more a loss than a win (good on paper, terrible in practice). It codified worse things. The EU app stores are still fully controlled by Apple (harder to install, they can just decline or drag notarization of any apps or revoke your license to dev tools, you need to still pay them, etc.).

For various apps the EU market is too small (esp. for things that need to be global) to invest into the development so while you can for example theoretically develop a real alternative web browser to Safari/WebKit (forbidden by App Store rules) nobody is willing to do it.

It matters with patents where you can have patented stuff in the source code without a problem as long as it's not compiled into the binary. Users who are unaffected by the patents or have a license can compile it in.

Fair use is used during a trial to determine if your use case is an OK exception despite being it a copyright infringment. It's not guaranteed to go into your favor (there are a lot of nuances case by case despite of precedents) and you need to be sued to exercise it.

What you can do is to mimic the behavior and look from scratch, then it would be a separate work. The internal structure would be quite different too. Even the same logic would most likely be coded differently. And the look wouldn't be pixel-perfect just very similar looking.

I do this all the time (even at night without lights) with no problem at all. The key is to have properly set brightness/contrast on your monitor and gamma correction.

It can achieved by setting the brightness to a minimum (and use the contrast setting to go even lower, or even combine it with GPU settings in addition to monitor settings). It is also important to set a proper gamma correction so that darker/lighter levels don't have too big contrast.

The gamma correction needed can be measured by comparing the apparent thickness of antialiased text in black-on-white vs white-on-black color combinations that you toggle between. Once it is the same you get the right value. For example it's 1.3 on my LCD.

On M1+ devices it might also need "ad-hoc signing" if the developer hasn't done it (not required for Intel binaries). This is not a true signing, it just inserts a cryptographic checksum into the binary, no actual signing is involved.