Sadly:

  $ nm /System/Library/dyld/dyld_shared_cache_x86_64h
  /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm: error: /System/Library/dyld/dyld_shared_cache_x86_64h: Invalid argument.

But yes, there are tools to pick apart a shared cache, some which work better than others.

I never said I wasn't relaxed about it. I don't even use a Mac much.

But the platform does seem to have been in a multi-year process of technical decline, and much of that does speak to a "we know better than you, and everybody else" attitude.

A number of the changes that Apple has been making seem to be security related. One reason to just dlopen() rather than stat() and dlopen() is the race-condition, which an attacker could use to get a program to use the wrong library. Similarly macOS' locked-down root partition. Checking hashes of binaries is also for security, to make sure the binary you're running is the one the developer thought they were giving you. So on the one hand the platform is in "slow technical decline" yet we (HN) claim to value security. It seems to me that the platform is doing well technically. We all remember the mess Microsoft had 10 years ago with security vulnerability du jour; Apple seems to be pre-emptively protecting its users. I submit that the "technical decline" is really "macOS is changing from a freewheeling Unix system to a secure system" and people here want to be cowboys and artists with their own private filesystem canvas. I understand the frustration, but Linux still exists. Apple isn't in the business of making a dev playground, but a computer that Just Works for people. It seems to me there isn't a technical decline, it's that HN is revealing itself to value the plasticity of traditional Unix over security (now that security has gotten good enough). I expect that SELinux has similar chafing restrictions, the only difference is that Linux is more of a set of parts so you get to (must) choose how you put those tools together.

> One reason to just dlopen() rather than stat() and dlopen() is the race-condition

But dlopen() implies code execution all the time, and stat() does not.

A good way to close this race condition, by the way, is to have a dlopen-by-fd API [FreeBSD has fdlopen], and a single call to open(2) resolves the race condition inherent in referencing the filename multiple times.

But to your larger point... It seems there is a crowd that will kneejerk dismiss any criticism as "it's for security". And any implementation bugs (such as introducing massive delays when executing programmatically-generated shell scripts because they need to be hashed and sent to a server, as was an HN headline a while ago) are also justified. I think there needs to be greater skepticism than this about how secure these efforts really makes the system, or if they are just throwing buggy stuff at a wall and applying post hoc justifications.