I think their bigger problem is there's shit for documentation. You get a big list of function signatures and if you actually want to know how you're supposed to use anything you find the WWDC session from 4 years ago and hope it's still accurate.
What's even worse is they used to have great documentation, then for some nonsense reason archived it and replaced it with this wannabe JavaDocs crap with vague function explanations that leave more questions open than they resolve.
They now tell people to watch WWDC videos as if those relatively short videos contained the same amount of information a proper API documentation does.
honestly i don't see this as Apple-specific but more of a sign of the times. i've seen a few libraries and vendor platforms we use at work with the same style of documentation (really lack thereof).
Microsoft's documentation quality very noticeably fell of a cliff about a decade ago. Now most of their public APIs and SDKs have hundreds of thousands of "documentation" pages that are just the name of the function with spaces added between the words. There might also be a listing of the parameters, which helpfully tells you that "string param1" is called "param1" and takes a string as the data type.
Yeah, the extreme basics seems to be the trend. We've actually had a lot of trouble due to this exact problem with one particular vendor now. Even repeated requests to improve their documentation are completely ignored or laughed off. it's too bad I don't have the purchasing power otherwise I'd suggest we should find a different vendor.
We've come from the monstrous Inside Macintosh tomes, to that early OS X documentation (that's now in the documentation archive), to this seemingly programmatically generated from doc comments thing.
In general it is assumed that documentation is the boring part and paying attention to it is a sign of quality. But where do you put people who prefer writing and/or teaching to thinking long and deep about product issues ?
Perhaps the biggest issue with the 737 MAX was lack of documentation. Boeing consciously chose to completely omit several new features (most notoriously MCAS) from the pilot manuals in order to make it seems like nothing important was changed that would require retraining 737 NG pilots on a simulator.
In a sense, this is far worse than what most tech companies do since it is a life-and-death issue and Boeing has made a very conscious effort to hide details here, rather than just being lazy.
One could say that "the point" of MCAS was to be an implementation detail, something that you would often deliberately hide from software documentation so that users don't design around internal details.
There's something of a history of aerospace vendors omitting "implementation details" that end up contributing to serious accidents (e.g. if you get an Airbus far enough out of the normal envelope protections, you lose stall warning), and an equally sordid history of flight and maintenance crews improvising procedures to the observed (rather than designed/specified) behavior of aircraft systems.
Arguably, the single biggest systematic risk in the current pilot training system is that crews overlearn to the implementation details of their training, rather than the actual principles and flight manuals (e.g. training inadvertently training for quick engine shutdowns, when the consequences of shutting down the wrong engine in reality are much more serious).
> There's something of a history of aerospace vendors omitting "implementation details" that end up contributing to serious accidents (e.g. if you get an Airbus far enough out of the normal envelope protections, you lose stall warning),
And Airbus control laws and protections are well defined and studied by pilots training for them.
You encourage them to blog about it and you aggregate the posts into documentation - somehow. (I'm sure there's people for that, or an AI, or something). They had to explain it when they implemented it - explain it on a post. Confluence. Somewhere.
I've read one of the manuals for the 787 management software stack, and it was... beautiful. It read like a novel. I read it twice on the train for the simple pleasure of it.
No they don't. Just last week I was looking for something, found a Google result from Microsoft's docs, but opening it resulted in a page saying they're moving docs around, this one isn't being moved, fuck off. No content, no link to the content.
I can attest to that. I used to freelance doing porting about 10 years ago, and the main way of having a stable event loop for a game on macOS is not really anywhere clear in the documentation, at least not anywhere I could find.
Libraries and SDL, GLFW and Sokol handle this for you, and I had to poke inside them to actually figure out how to get the same performance of other games.
In a nutshell, the trick is simple, you call [NSApplication finishLaunching] and do a while-loop yourself instead of calling [NSApplication run].
