Has anyone else noticed that Apple has been slowly moving away from the long-form guides that were helpful at explaining core concepts? I remember once seeing a comprehensive guide on code signing, but over the years it appears to have been scrubbed from their documentation resources. In its place is a much less helpful (but prettier-looking) guide. In comparison, I've noticed Android has FANTASTIC developer document…
Yes! Apple used to have Technical Notes that were a deep dive into how the OS is implemented. They were super helpful in troubleshooting and optimizing for Mac OS. They haven't published anything like this in over a decade. I suspect someone took "hiding implementation details" too seriously, and now Apple never talks about how anything works (it's all magic). You only get function's signature, and "documentation" th…
On Apple's Piss-Poor Documentation
71–80 of 348 posts
Re: On Apple's Piss-Poor Documentation
#72Re: On Apple's Piss-Poor Documentation
#73Why would they improve the documentation? It's not like you have a choice anyway, you will have to figure out, since you cannot ask your customers to switch to another mobile platform... They really don't give a shit about developers. I'm a backend developer, their In App Purchase system is the worse API I have been unfortunate to work with (and it's much better than what it used to be)
Re: On Apple's Piss-Poor Documentation
#74I don't think Steve would have allowed this to happen. Developers are way too important part of the whole "where the money comes from?" question. He would have noticed the complaints before anyone wrote a blog about it. iOS docs were great back in 2011.
From what I've read, Jobs certainly understood the importance of software, but only great software. He didn't want the Apple ecosystem to become loaded up with crapware like on the IBM, or on the Apple ][ for that matter. So, if a small time developer couldn't write and distribute a crude but useful app, so be it. Favored developers probably didn't fare any better with the documentation, but help was a phone call away.
This was the "closed box" philosophy that I don't think has changed much over the years.
The irony was that "crappy but open" attracted more developers than "wonderful but closed." This is why apps such as assemblers for microcontrollers were written for MS-DOS. Essentially, even after the introduction of MS Windows, the ability to write for DOS provided a way to create and share simple apps.
Re: On Apple's Piss-Poor Documentation
#75Has anyone else noticed that Apple has been slowly moving away from the long-form guides that were helpful at explaining core concepts? I remember once seeing a comprehensive guide on code signing, but over the years it appears to have been scrubbed from their documentation resources. In its place is a much less helpful (but prettier-looking) guide. In comparison, I've noticed Android has FANTASTIC developer document…
I once owned every copy, of every generation of "Inside Macintosh." I agree about the Android docs. However, in defense of companies that don't like to have too much documentation around, I can tell you, from personal experience, that writing developer docs is hard , as is doing developer support. Keeping them up to date is also a challenge. I call it "concrete galoshes": https://littlegreenviper.com/miscellany/concr…
Re: On Apple's Piss-Poor Documentation
#76===
I never liked Ballmer, and really never liked the win APIs, but I fell in (technical) love with him after the much derided "developers developers" dance he did. In that regard he clearly understood who buttered his bread.
OTOH Apple treats WWDC as the entirety of their developer outreach, when really it should merely be the cherry on top.
Re: On Apple's Piss-Poor Documentation
#77This isn't an apple thing. Its industry wide. Much of the good documentation that exists is stuff that was written 20+ years ago by actual technical writers and is still being maintained. AKA the windows API/etc documentation, linux man pages, etc. The vast majority of modern documentation is worthless autogenerated garbage when it exists. It lacks good examples, meaningful overviews and functional diagrams. In many…
Did you ever look at the Windows API documentation?
Lets look at https://docs.microsoft.com/en-us/windows/win32/api/synchapi/...
Function description, supported version information, header-file and library file information, meaningful return code documentation, links to an overview of the system wait behaviors, documentation about what happens in low power situations, links to example code using the function, differences in behavior between differing versions, it goes on and on.
Can you point to something you think is better?
PS: I should point out, I have paper copies of the win32 api from the early 1990's that are falling apart from the use they got.
Re: On Apple's Piss-Poor Documentation
#78I feel as if Apple has let down the software industry by “going with the times” in general. A “north star” to lots of designers and engineers from interaction design all the way down to the systems level. Excellent documentation was part of it. Long game. Best practices. The whole “crafting” DNA seems to have been lost somewhere along the journey. I think it’s also a function of market driven angst and hence not sayi…
I read an ancedote from an aspiring SWE that after he saw the Apple product he couldn't afford, he knew he needed it.
People aren't buying because quality reasons, they buy because of various psychology tricks their marketing department is responsible for.
It creates a system where developers are dragged along to support 100% of users.
Re: On Apple's Piss-Poor Documentation
#79What makes Apple money is building pretty, locked-down computerlike appliances that are completely under Apple's control. I don't think Apple even sees developers as necessary any more, except the ones in their employ.
Re: On Apple's Piss-Poor Documentation
#80Honestly, reading the headers is the only way to understand iOS, macOS, and iPadOS properly. I find that the older I get, the more _code is my documentation._ Particularly for things like Python's matplotlib, once you do more than put lines or scatter plots together, you _have_ to understand how the code actually works. Of course, that's difficult when all you get is header files, but still...
Not to say that heavy documentation like this is perfect of course. It just seems like the complexity of the read-the-code solution is sometimes glossed over.