>> One is a developer reaching out (costs: developer time, management involvement: granting permission). The other is a change in project plans, staffing, workflow and timelines (costs: large, management involvement: massive).
I think it's a pretty safe bet to expect, for this reason alone, that the documentation quality of things like SwiftUI will improve over time. It seems pretty obvious they directed all their efforts to releasing SwiftUI within their iOS 13 release window, which likely meant the API only 'stabilized' very late in the process and it would be impossible to spend time and resources documenting it, at least not without postponing the release (not an option).
Generally speaking, in my experience all of the 'established' Apple API's have pretty good documentation. SwiftUI seems rushed, and it would probably been better if they waited until iOS 14 and release it along with documentation. I'm not definding Apple here, but I think the article is overstating how bad their documentation is based on one brand-new API that probably wasn't fully cooked for release to begin with.
I think it's a pretty safe bet to expect, for this reason alone, that the documentation quality of things like SwiftUI will improve over time. It seems pretty obvious they directed all their efforts to releasing SwiftUI within their iOS 13 release window, which likely meant the API only 'stabilized' very late in the process and it would be impossible to spend time and resources documenting it, at least not without postponing the release (not an option).
Generally speaking, in my experience all of the 'established' Apple API's have pretty good documentation. SwiftUI seems rushed, and it would probably been better if they waited until iOS 14 and release it along with documentation. I'm not definding Apple here, but I think the article is overstating how bad their documentation is based on one brand-new API that probably wasn't fully cooked for release to begin with.