Assumed Audience:practitioners or interested lookers-on for software development — and Apple itself.
Edit:some folksrightly pointed outthat my use of “garbage” suggests that the problem is the quality of the existing documentation; I’ve retitled the post to capture that the problem is themassive absenceof documentation. You can see the original title by way of the slug.
Over the past few months, I have been trying to get up to speed on the Apple developer ecosystem, as part of working on myrewriteproject. This means I have beenlearningSwift (again), SwiftUI, and (barely) the iOS and macOSAPIs.
It has beenterrible. The number of parts of this ecosystem which are entirely undocumented is frankly shocking to me.
Some context: I have spent the last five years working very actively in the JavaScript front-end application development world, working in first AngularJS and then Ember.js. Ember’s docs once had a reputation of being pretty bad, but in the ~ 4 years I’ve been working with it, they’ve gone from decent to really good. On the other hand, when I was working in AngularJS 5 years ago, I often threw up my hands in quiet despair at the utter lack of explanation (or, occasionally, theinaneexplanations) of core concepts. I thought that would have to be the absolute worst a massive tech company (in that case, Google) providing publicAPIs could possibly do.
I was wrong. The current state of Apple’s software documentation is the worst I’ve ever seen for any framework anywhere.
Swift itself is relatively well covered (courtesy of the well-written and well-maintained book). But that’s where the good news ends.1Most of SwiftUI is entirely undocumented — not even a single line explanation of what a given type or modifier does. Swift Package Manager hasokaydocs, but finding out the limits of what it can or can’t do from the official docs is difficult to impossible; I got my ground truth from Stack Overflow questions. I’ve repeatedly been reduced to searching throughWWDCvideo transcripts to figure out where someone says something relevant to whatever I’m working on.(2)
This is, frankly, unacceptable. In the Ember ecosystem, we have a simple rule that code doesn’t get to ship unless it’s documented. The same goes in Rust (I should know: IwrotetheRFCthat made that official policy). Now, I understand that Apple’sAPIdevelopers (often) work in a different context than these open source projects — especially in that they face crunches around releases which are tied to hardware products shipping.
But. At the end of the day, when you’re vending anAPI, it isn’t done until it’s documented. Full stop.
Given what I know of Apple’s approach to this, the problem is not individual engineers — who are not responsible for writing docs; that is the responsibility of dedicated coumentation teams. But that does not make it any less a failure of Apple’s engineeringorganization. The job of anAPIengineering organization is to support those who will consume thatAPI. I don’t doubt that many of ApplesAPIengineers wouldlovefor all of these things to be documented. I likewise do not doubt that the documentation team is understaffed for the work they have to do. (If I’m wrong, if Ishoulddoubt that, because Apple’s engineering culturedoesn’tvalue this, then that’s even worse an indictment of the engineering culture.) This kind of thing has to change at the level of the entire engineering organization.
Apple claims to be interested in building a platform that is accessible to everyone — from a brand new developer to the most experienced gray-haired folks who’ve been around since the NeXT days. Right now, they’re not even close. I have a decade of software development under my belt, a fair bit of it in languages with rich type systems and functional programming idioms, and some of this stuff is hard formeto figure out. I can’t imagine how mind-bogglingly terrible the experience would be for someone just starting in software, or coming over with experience only in languages like Ruby or Python or JavaScript. It would be completely impossible to learn.
Apple, if you want developers to love your platform — and you should, because good developers are your lifeblood — and if you don’t want them to flee for other platforms — and you should be worried about that, because the web is everywhere and Microsoft is coming for you — then you need to take this seriously. Adopt the mentality that has served other frameworks and languages so well:If it isn’t documented, it isn’t done.
GIPHY App Key not set. Please check settings