Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On Apple's Piss-Poor Documentation

caseyliss.com

Post reply on HN
Print view View original

281–290 of 348 posts

Re: On Apple's Piss-Poor Documentation

#281

Post by geerlingguy »

Phrodo_00 wrote: post #271
ljm wrote: post #209

Earlier quoted context omitted.

I concur and add that PHP has actually evolved quite nicely, and it's horribleness is merely an outdated meme. Java is still playing catchup to the stuff PHP has added in recent years. Just because it was shit 15 years ago doesn't mean it's still shit now.

is the PHP standard library still an inconsistent mess?

The inconsistencies are either fully removed (many in 7.x, more in 8.x), deprecated, or at least very well documented these days (e.g. with top level documentation warnings about any potential pitfalls).

Re: On Apple's Piss-Poor Documentation

#282

Post by lukeh »

terhechte wrote: post #117
wlesieutre wrote: post #24

Earlier quoted context omitted.

Excellent, thanks for this! Most recent post is "Attributed Strings with SwiftUI" which is something I was wondering about. There's plaintext TextEditor view, but for rich text editing the impression I've gotten is to either fall back to something in UIKit or do it in a WebView. Will check this post out tonight, it might not change anything but I'd at least like a better idea where things stand in SwiftUI. Props to A…

Yeah, for rich text you need to wrap a UITextView, there's currently no other way to do that. Also, if you have a large amount of text, TextEditor won't cut it either. Even displaying rich text (non editable) is a wee bit tricky and severely under documented.

Yeah, the sizing thing is a bit of a pain as the creates visible content fitting artefacts when contained in a list or stack.

Re: On Apple's Piss-Poor Documentation

#283

Post by alblue »

Ronsenshi wrote: post #107
ProAm wrote: post #82

Earlier quoted context omitted.

> So instead you end up on 3rd party tutorials...How do you know if the feature changed significantly in the more recent release? I don’t know, but I can tell you where you won’t find out: the official docs. Get ready for documentation subscriptions. I wish I were joking.

Already a thing: https://apps.apple.com/us/app/a-companion-for-swiftui/id1485... No affiliation. It's sad and a bit pathetic that trillion dollar company can't hire even one person to work on public documentation.

They actually have a department to write the documentation. The problem is that it’s a separate department from the people who design the libraries themselves, which means instead of having high quality documentation throughout, you only get the documentation that the doc team had time to write. It’s why most of the APIs are minimal at best in terms of documents.

While the level of documentation that exists is usually pretty good, the sad fact is that most documentation doesn’t exist, and it’s entirely due to the fact that they are handled by developers/documentors separately. If you had developers documenting in-situ in the code, instead of WWDC slides, then it would be a lot better.

Re: On Apple's Piss-Poor Documentation

#284

Post by saagarjha »

heavyset_go wrote: post #100
wlesieutre wrote: post #2

I’ve been picking at SwiftUI recently and run into this myself. You want to know how something works or how to use it, so you go to Apple’s documentation. “Here’s the type signature, have fun!” Thanks. But I was hoping something more than what Xcode’s autocomplete already filled in for me. So instead you end up on 3rd party tutorials (special thanks to John Sundell and Paul Hudson) and always looking at dates on Medi…

Apple figures developers will still pay them $99/year even if they provide them with poor documentation, and unfortunately, it looks like they're right.

Many developers are paying for the ability to develop, not the development experience.

Re: On Apple's Piss-Poor Documentation

#285

Post by saagarjha »

on_and_off wrote: post #96
wlesieutre wrote: post #2

I’ve been picking at SwiftUI recently and run into this myself. You want to know how something works or how to use it, so you go to Apple’s documentation. “Here’s the type signature, have fun!” Thanks. But I was hoping something more than what Xcode’s autocomplete already filled in for me. So instead you end up on 3rd party tutorials (special thanks to John Sundell and Paul Hudson) and always looking at dates on Medi…

stupid question : but is there any specific reason why swiftui is not open source ? I am working with jetpack compose these days and it is both open source and documented. I am not sure how I would work with it without that, it is quite a big departure from the legacy ui api.

Probably because it’s a competitive advantage for Apple to keep to themselves.

Re: On Apple's Piss-Poor Documentation

#286

Post by saagarjha »

thombles wrote: post #237
_qulr wrote: post #64

Earlier quoted context omitted.

The other day someone referenced this post by an Apple engineer: https://developer.apple.com/forums/thread/663858 Why in the world is this a random undiscoverable post in the (terribly designed) developer discussion forums rather than a Technical Note in the documentation? It would have been a TN in the past. In fact that same engineer wrote a number of old Apple TNs. It's clear even to some within Apple that there's…

I would struggle to get many things done if not for that one particular Apple engineer and their forum posts.

We all would. Eskimo is a treasure and I have no idea how he does what he does.

Re: On Apple's Piss-Poor Documentation

#287

Post by saagarjha »

psahgal wrote: post #141
grishka wrote: post #98

Earlier quoted context omitted.

And even when there's no documentation, or when it isn't enough, you can just always dive into AOSP sources and figure out whatever needs to be figured out. They've recently made this more convenient too: https://cs.android.com No such luck for iOS. Best you can do is poke at binaries with a disassembler.

I have been frustrated many times after stepping into a system function on iOS, only to be greeted with a mountain of assembly instructions. It was one of the first grievances I had with iOS development, coming from Android. On the other hand, it's been a great opportunity to learn how ARM works!

If you haven’t tried Hopper already, it’ll level up your reversing skills: https://www.hopperapp.com/

Re: On Apple's Piss-Poor Documentation

#288

Post by saagarjha »

layoutIfNeeded wrote: post #14
psahgal wrote: post #7

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…

This. Their documentation on CoreAnimation concepts was wonderful [1]. It even has these little appendix sections discussing advanced use-cases. Sadly, they seem to have stopped writing these at around 2015... [1] https://developer.apple.com/library/archive/documentation/Co...

Relevant username?

Re: On Apple's Piss-Poor Documentation

#289

Post by saagarjha »

Etheryte wrote: post #11

Having run into something similar just recently [0], having any documentation is still (slightly) better than no documentation at all. As a stark example, macOS has a built-in sandboxing CLI tool called sandbox-exec (originally called Seatbelt), but the man page simply says it's deprecated, as far back as I could find them. Mind you, the same tool is used heavily by macOS internally, and has been around ever since Le…

Ah, yes, sandboxing, the technically SPI interface that everyone at Apple uses and large third-party apps are tacitly told to use.

Re: On Apple's Piss-Poor Documentation

#290

Post by hajimemash »

creativityEng wrote: post #78
musha68k wrote: post #29

I 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…

There's a huge disconnect between informed consumers and the average Apple product owner. 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…

The n=1 sample sounds like a normal beginner that wants to buy high-end equipment for a new aspiration. Doesn't mean much. My n=1 is for unix architecture and reliability. Probably the same for many devs.
Post reply on HN