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

Apple Developer Documentation Is Missing

v4.chriskrycho.com

Post reply on HN
Print view View original

131–140 of 400 posts

Re: Apple Developer Documentation Is Missing

#131

Post by mmusson »

When I first learned iOS ten years ago I thought the documentation was outstanding. It had good API level documentation as well as a large number of guides that showed the right way to use the API to implement particular features.

I recently returned to the platform and my experience is very much like the parents. The documentation appears to be almost completely missing. The built-in documentation does not appear to include any guides at all. The API documentation is largely the kind where the description is a more verbose form of the method name, and sometimes when Objective-C is selected the documentation is showing the Swift version.

Re: Apple Developer Documentation Is Missing

#132

Post by ChrisMarshallNY »

eugeniub wrote: post #125
ChrisMarshallNY wrote: post #120

Earlier quoted context omitted.

"Giving the developer succinct ways to prevent program failure from unexpectedly undefined values is a feature." Most languages have had this since the 1960s. It's called the "if" clause. The ternary and nil-coalescing operators are shorthand (sugar) for an if test (or guard, in Swift). Like I said, I actually like them, but I have to be careful, when using them. I really like Swift, but it's quite possible to write…

> Most languages have had this since the 1960s. > It's called the "if" clause. If we got rid of everything we don't absolutely need in programming, we would have to get rid of 98% of Swift syntax, and probably every modern programming language including Swift.

Yes, but I LIKE Swift, because of all that sugar.

I started off with machine language, in embedded systems. You can't get much more "raw" than that.

I have been writing Swift exclusively for a long time. I speak it without an accent. It's my beauty.

But I also know that you can have so much sugar you fall into a diabetic coma.

Re: Apple Developer Documentation Is Missing

#133

Post by ensiferum »

mmahemoff wrote: post #122
ensiferum wrote: post #108

Earlier quoted context omitted.

Most interviewers don't give a crap about one's GitHub/Bitbucket/X portfolio. It might help one to get the interview in the first place but after that point it's useless. Why? Because any single interviewer has a set of well rehearsed questions they know like the back of their hands. They know the different possible solutions and understand their pros and cons. This makes the interviewing a routine that lessens the b…

Asking the same questions also makes it easier to compare between candidates and the questions can become optimised over time to ensure they are fair and valid performance predictors. Also, it's never obvious how much someone contributed to their portfolio. Just being able to explain it doesn't mean you were the sole contributor, or the contributor at all, and it doesn't give a great indication of how you work or how…

Yep, exactly.

Re: Apple Developer Documentation Is Missing

#134

Post by skybrian »

ChrisMarshallNY wrote: post #70

Some time ago, I was contacted by Apple to apply for a job. My code is insanely well-documented. I like to think that a lot of the inspiration for my code docs comes from Apple's open codebases. Their code is exceptionally well-documented. In any case, as is usual with all employers, these days, they completely ignored the focused, relevant links that I sent them to elements of my extensive portfolio of repos, and, i…

It sounds like you might not be quite getting the concept behind this sort of interview. Although some code is written, this is (usually) a test of how you talk about code. You want to show that, if a co-worker asks for your advice on how to solve a tricky problem, you will be able to help them figure it out.

Part of this is understanding what they're asking for and adapting. If someone wants to know how to document code properly then you can have a conversation about that and give an example. But if they're asking about algorithms then you write the code and explain how it works verbally. You don't need to write comments because the reader is right there and you can explain it to them. It's not production code.

Re: Apple Developer Documentation Is Missing

#135

Post by oflannabhra »

edw wrote: post #117

Nowhere in the comments thus far has anyone pointed out that SwiftUI — the framework in TFA's crosshairs — is in beta. I've written a relatively large amount of SwiftUI code and I get the impression that the design is still in flux. There are corner cases (as well as much more mainstream one) that haven't been fully thought through. Beta 5 of Xcode 11 brought non-trivial changes to the API and I expect those to conti…

As I noted in another comment, the documentation for SwiftUI is actually pretty good, especially if you take into account how quickly the framework has changed. It includes some rich, progressive tutorials. [0]

The author states that they are planning to write an app from scratch with SwiftUI. I think most iOS developers would hesitate to build an entire app on a beta framework.

[0] - https://developer.apple.com/tutorials/swiftui/tutorials

Re: Apple Developer Documentation Is Missing

#136

Post by scarface74 »

orangecat wrote: post #130
scarface74 wrote: post #100

Earlier quoted context omitted.

Of course it’s sarcasm. It’s just like people who sat that the iPhone is a “status symbol”. How can something be a status symbol when 50% of smart phone users have it in the US and that anyone on any of the four major carriers can buy one an interest free 24 month loan. Geeks can’t stand to face the fact that people who can afford to have a choice, overwhelmingly shy away from Android.

How can something be a status symbol when 50% of smart phone users have it in the US It's more that Apple has gotten people to view anything other than the iPhone as low status, e.g. green bubbles.

So Apple has brainwasheded people for 20 years? Geeks have been saying that Apple was a status symbol since the iPod. As far as iMessage, it couldn't possibly be that Google has had four or five failed attempts at a messaging platform?

Re: Apple Developer Documentation Is Missing

#137

Post by EpicEng »

skybrian wrote: post #134
ChrisMarshallNY wrote: post #70

Some time ago, I was contacted by Apple to apply for a job. My code is insanely well-documented. I like to think that a lot of the inspiration for my code docs comes from Apple's open codebases. Their code is exceptionally well-documented. In any case, as is usual with all employers, these days, they completely ignored the focused, relevant links that I sent them to elements of my extensive portfolio of repos, and, i…

It sounds like you might not be quite getting the concept behind this sort of interview. Although some code is written, this is (usually) a test of how you talk about code. You want to show that, if a co-worker asks for your advice on how to solve a tricky problem, you will be able to help them figure it out. Part of this is understanding what they're asking for and adapting. If someone wants to know how to document…

>It sounds like you might not be quite getting the concept behind this sort of interview. Although some code is written, this is (usually) a test of how you talk about code.

Assuming everything the GP said is true, what you're saying is completely contradicted by the fact that they were dinged for not using a null coalescing operator.

Re: Apple Developer Documentation Is Missing

#138

Post by w0utert »

School-Cotton wrote: post #106
w0utert wrote: post #89

Earlier quoted context omitted.

If these are the 'best worst examples' you can come up with after ~3 years of iOS work, they are not really convincing. I just scanned the CoreLocation docs, and while it is true they do not explicitly state what sources are used for getting a certain accuracy, the documentation makes it very clear and unambiguous what you should use. You use kCLLocationAccuracyBest if you need to be absolutely sure you have the high…

Your assertion in the first paragraph is not actually true. Go to Central Park or somewhere else with no nearby WiFi beacons and try it out. Your test app will not fall back to GPS accuracy. I have done this. So actually the documentation you’re quoting is wrong. As for what you might want to know the maximum address space size for: evaluating whether unattributable production crashes might be due to running out of a…

>> Your assertion in the first paragraph is not actually true. Go to Central Park or somewhere else with no nearby WiFi beacons and try it out. Your test app will not fall back to GPS accuracy. I have done this

That's not what I said, nor what the documentation said. From the documentation:

The system always tries to give you the best location data that is available, but these properties give the system the flexibility to turn off hardware elements when they are not needed. For example, if you set the desired accuracy to kCLLocationAccuracyKilometer, the system might disable GPS and use only the Wi-Fi hardware, which would save power and still give you a greater accuracy than you requested.

In other words: the system will not promote the returned accuracy if the data it has is already within the accuracy you asked for, but it will still fall back to whatever source of location data available, possibly higher accuracy, if no lower-accuracy source is available.

This makes a lot of sense, because it is much more common to only have a GPS signal, and no cell tower or WiFi geolocation (e.g. when doing outdoor activities) than the other way around. In that case your '1 km accuracy' app might in fact get you GPS accuracy. But if you are in Central Park, you will most definitely get location data from cell towers, so in that case your app will not promote the accuracy since you didn't ask for it. Ergo, if you need the highest accuracy, you have to ask for it. The documentation makes it very clear the accuracy parameter is not a tool to force a specific accuracy, but to allow the system to relax accuracy in favor of lower power consumption, if your app doesn't need it.

Not trying to be snarky here, but in this particular case it seems the problem is not in the documentation, but in your reading comprehension of it. Unless of course there is a bug in CoreLocation, or you got so unlucky when you tested in Central Park, that there was somehow not even a GPS signal available.

Re: Apple Developer Documentation Is Missing

#139

Post by moron4hire »

mikestew wrote: post #110
moron4hire wrote: post #73

Earlier quoted context omitted.

Seriously, Apple is one of the richest companies in the world (I don't remember if it's still The Richest or not). Similarly, Google's documentation is pretty bad, considering just how ludicrously rich they are. They could afford to hire entire teams whose only jobs were to write documentation and it would barely make a blip in their bottom lines. In contrast, I've always found Microsoft's documentation to be incredi…

hire entire teams whose only jobs were to write documentation In contrast, I've always found Microsoft's documentation to be incredible. I don't know how Apple and Google work, but as a long-time-ago MSFT employee, I can tell you it is because they have entire teams. Chain-of-command, senior-level, leads, managers (don't know if there's such a thing as User Ed VP/Director, though) the whole works, like Microsoft kind…

Definitely. Good documentation is hard work, a full-time project all on its own. It drives me nuts how many "hackers" think of it as an afterthought.

Re: Apple Developer Documentation Is Missing

#140

Post by gnachman »

The comments in header files are often the only (or only useful) documentation. So don’t give up before looking there. Sometimes they wait a few years to write docs. For example, NSWindowAccessoryViewController went undocumented for three or four years. Which was fine because it was too buggy for me to use anyway. The docs are enough to get you started but it’s only brutal experience that teaches you how to use things. In practice you spend a lot of time working around bugs and design flaws. Those will never be documented, of course.
Post reply on HN