Hacker News Reader

This is true about all walks of Apple software, sadly, from file syncing to Bonjour (mDNSresponder) to UI frameworks to developer tools to consumer applications. Apple developers rewrite software in a butterfingered way on a consistent basis, creating software that lacks any design, missing large chunks of functionality and often lacks any kind of polish or coherency.

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.

Agreed, but at least Apple managers have great hair.

>Apple developers rewrite software in a butterfingered way on a consistent basis, creating software that lacks any design, missing large chunks of functionality and often lacks any kind of polish or coherency.

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

Yes, that's a good example. A software that was messed up, had crazy security bug and is still lacking. Why was a rewrite necessary? How cynical would be to say "the engineer of the day fancied Swift more than going into old code"? Sadly these days, I'm not sure this is so far-fetched.

> Why was a rewrite necessary?

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.

I get this point. But coupled with lack of expertise & experience, lack of QA and lack of dependency tree (what feature is used where), the result can be amateurish at best and catastrophic at worst. In the case of DU, it was more the latter.

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.

cheaper to rewrite software than to fix existing one

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

Didn't the re-write happen around the time that Apple released and shifted to APFS? Not defending the new app, it is a huge misstep in my book, but it makes sense that there was a major overhaul to the Disk Utility app when they were introducing substantial new features for something as important as the file system.

I think both apps are a wrapper for diskutil or its underlying implementation. And UI-wise, APFS didn't warrant introduce any substantial UI changes, especially not ones that couldn't be added to the existing software.

They are but I was focusing on the impetus of the re-write, not defending the decision to hamstring the UI. I agree that it’s a regression but I think the patient was on the table when APFS came out and the new UI appears to have come at that point.

Apple is a multi billion dollar company and you are saying they couldn’t find a C/Obj. C developer to take care of their own app?

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.

Google is doing it all the time; it's not a question of money, it's that most developers don't want to work on old stuff they had minimal input on; it's easier to motivate with "hey, let's do new stuff" instead of "hey, fix these convoluted bugs original author wasn't able/willing to".

Yes, this is creating lot of churn in terms of apps and user interfaces. Developers as I said before are motivated to build new things causing adverse problems like this situation here were perfectly good apps are being rewritten to an inferior state.

Please, many people consider that term offensive.

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

Pardon my ignorance, what does "photoshopped Disk Utility" mean? I get the reference between GIMP vs. Photoshop, but what does it mean by "gimped/photoshopped" an application?

To gimp something means to severely reduce it's functionality. The photoshopped part is a joke; it doesn't mean anything.

Using gimp as a verb can also be a sly reference to Pulp Fiction: https://www.urbandictionary.com/define.php?term=bring%20out%...

You've got it backwards. "Gimp" is also a BDSM term, which is what it's used for in Pulp Fiction.

It’s a joke: gimp as derogatory slang [0] should not be used, so you use... Photoshop.

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

Ok so before today I thought the issue was gimp masks and such.

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".

Saying some software is crippled (adjective) is fine as you're using the word as its meant to be used (perhaps someone intentionally removed some critical capability). If you, for some reason, referred to some software as a "cripple" (noun), some people might find that offensive as you're using a deragotory term for someone with a physical disability as a way to express something as being undesirable or bad.

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.

Gimped is an adjective just like crippled, thus my comparison.

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.

Fair enough. In this case it seems like it was intended as a joke, but I could see somebody actually getting offended.

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.

You could perhaps claim that perspective (gimp masks) as well, since they typically reduce motor range or flexibility.

Don't quit your day job.

Being called out by Don Hopkins makes my day.

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.

This explains something I ran into recently. I stick with older versions of macOS for a variety of reasons, and El Capitan cannot rename or delete a file that has a NUL character in its name. Earlier versions of macOS could do so. This implies they rewrote the unlink function and made a rookie C programmer mistake in the process. Why rewrite unlink? The mind boggles.

What do you mean 'rewrite unlink'? As far as i know, none of the standard POSIX/C file-manipulation functions, including unlink(2), have ever supported NUL bytes embedded in file names. Path arguments to those functions are all NUL-terminated strings, as are exec*() process arguments, so it would be impossible to manipulate or reference those files using any of the standard APIs or command-line tools.

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...?

Well…

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.

Pre-posix macOS (previously known as ‘system N’ where N was the version number) did indeed use pascal calling conventions, so the posters assertions aren’t unreasonable.

I'm not sure about the internal culture, but externally they seem to stress the importance of only using public published interfaces and frameworks as API & ABI layers and not touching anything else as they won't guarantee any stability in private internals. (per their docs iirc)

Even with the so-called "public" APIs, the way Apple operates, there is no guarantee of any stability, as most iOS developers know. AppKit is much more stable than UIKit, but still nowhere near the stability that companies like Microsoft provide (including changing the name of a product—Windows 9->10—so that existing software does not break!).

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.

But doesn't that go for anything? Take android where you need to account not only for all the cases of versions but also for every differentiated version from every brand and device, or if you build for things like silverlight which gets killed with no replacement. There are always things changing and unless you are on the same path as the vendor you're gonna get screwed. It's always been like that.

I think you misunderstand what I mean. There is an API, which is documented to function in some way. You'd expect it to continue functioning like that down the road, but since Apple engineering has such poor QA and is always rewriting things, their developers just let things slip through the cracks, often creating broken API for years. Android whataboutism is not really productive here.

Odd. I never had a public API go bad on macOS, ever. There were always multi-year planned deprecations etc but no sudden changes. The only issue I remember had to do with a toolbox issue before my time where timing wasn't always reliable to be sub-ms precise. Even 68k to PPC transition went fine API-wise, as well as toolbox to carbon.

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

Yeah, the context of the post you replied to is for iOS APIs. AppKit is a lot more stable, and it shows. It is still possible to run 10-12 year old software on Mojave (but not on Catalina). On the other hand, sometimes even one OS upgrade can break existing software visually or worse on iOS.

If a proprietary software is not much more better than an open source one, I will not choose it.

Can you give some examples of those "terrible bugs" you have experienced on a yearly basis?

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

UINavigationController—https://twitter.com/LeoNatan/status/1168286477882728448

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

You quoted a bug in 2015, then three in 2019. That's not on a yearly basis. Aren't your views colored by a bad iOS 13 launch? Because I do agree with you that iOS 13 seems bad (not my personal experience, from the general clamoring around us).

No. I maintain a pretty popular iOS open source project, as well as many low level projects for my job. It’s always unstable. Every year, new bugs pop up. Is it the end of the world? Probably not, but is it acceptable? It shouldn’t be. Before 10.15, I could run Mac software built 15 years ago. If AppKit developers can preserve backwards compatibility, so should UIKit developers.

FWIW, I created a mirror of all of Apple's OSS releases on GitHub here: https://github.com/apple-opensource-mirror