Other problems in the dev culture accentuate this problem even further. It seems there is a complete lack of dependency graph between the software stacks; apple engineers who opt to rewrite a piece of software or functionality have no documentation or idea how the software is used or was originally intended to be used, be it inside Apple or otherwise, often causing serious design-level bugs, often resulting in major rollbacks. The lack of any QA work is also very apparent, especially in recent years, where simple bugs and glitches are allowed to go through, let alone major rewrites. The only tool to counter this is radar/feedback assistant, which are tools well documented in their inefficiency from current and ex Apple developers themselves.

I don't think this should solely fall on Apple developers, of course. As is often the case, such inherent problems in culture are due to lackluster management. This has been hinted at by many ex Apple engineers.

The day they completely gimped Disk Utility is the day I started looking to move off macOS.

The politically correct wording is now "The day they completely photoshopped Disk Utility is the day I started looking to move off macOS."

[0] https://en.m.wiktionary.org/wiki/gimp

Is this not the same as 'cripple'

If I call you a cripple, that's an insult, if I call some software crippled, that's acceptable?

The first definition I got btw was "A limp".

I don't know if you're a native English speaker or not, but one letter in this instance can make a big difference. The context is subtle but very different.

I am (literally) a native English speaker, gimp isnt used much in the UK, as I said, I associate it more with gimp masks, so I'm trying to work out if it's a legitimate grievance, or if it's someone being overly PC for humours sake.

Also upon rereading my comment, I hope it didn't come across as condescending in any way, I didn't mean it to but it does line of read that way.

Edit: On a serious note, thanks for pointing out my careless and potentially insulting word choice. My fiancee has an 'invisible illness' (lupus), and I would be very upset if someone referred to them like that, so I should strive to be better.

Most likely because original authors were laid off or moved on; it's cheaper to rewrite software than to fix existing one; both need very different skillset and there are more people that can write their own algo quickly than fix somebody else's.

That's a very shortsighted thought, because the rewrite has also introduced its own set of new bugs.

Again, the cynic in me can't accept the "cheaper" argument. Apple has lack of funds to properly hire people who are not afraid to go into complex existing code? I get this argument in a start-up environment, but won't accept it in the case of the largest tech company in the world. This is just bad management.

Also, developers in their nature like to rewrite things. There should be a product owner overruling them. I’m saying this as a developer myself. Otherwise you end up in a situation where images are running the asylum.

I can't think of how macOS could have previously supported NUL bytes in file names without those files existing in a separate universe that can only be interacted with by software that uses some proprietary Apple API. And if that's really how it worked, i feel like that was the real mistake all along...?

I do not know details here. But there is, in fact, a separate “proprietary” API for interacting with files on macOS, provided for backwards compatibility. This API exists because the POSIX file functions do not provide similar enough functionality to the earlier API. This API is called the File Manager. Documentation is hard to find on the Apple website, but you can find some fairly extensive documentation for it in the old Inside Macintosh series (and sometimes you can dig HTML or PDF versions of this on the Apple website, but whether this is possible, and the exact location, seems to change every couple years).

The way you would specify a file on old versions of macOS used a length-delimited string for the filename, and referred to directories by 32-bit IDs. This was packed into an FSSpec structure which was passed to most functions which operated on files. Being length-delimited, it is possible to pass a NUL byte.

From what I understand, the macOS kernel exposed some additional entry points for these functions to operate correctly.

If you are using features of the frameworks that are outside of the "happy path" for that year's keynote announcements, you can expect terrible bugs on a yearly basis. These bugs happen for the exact same reasons as stated in the GP.

I have developed for iOS for the last 5 years, and I haven't ever experienced those in UIKit. This year brought one single bug in UISegmentedControl, in a situation that doesn't happen often: https://forums.developer.apple.com/thread/122736

UITabBarController—https://twitter.com/LeoNatan/status/1168286996915204097

UIActivityViewController

Various UIView layout issues

Safe areas—https://twitter.com/LeoNatan/status/1179475940784721920

UITableViewController—iOS 13's sheet presentation broke clearsSelectionOnViewWillAppear (https://twitter.com/LeoNatan/status/1137474148488364034), for example, but it's often broken: https://twitter.com/Javi/status/644631570083483648

SLComposeServiceViewController is completely broken on iOS 13

Perhaps you are exclusively referring to mobile 'apps' and the APIs you can use for those?