I appreciate the challenges of scheduling guests, but my goodness it would be nice to hear some fresh voices rather than the same cadre of friends all the time.
I’d enjoy hearing Tech Dad on the podcast. He is a project manager, a teacher, a content creator, and uses his iPad for 95% of his work. His YouTube channel is:
I’m in the middle of listening to this episode, and just listened to the part about developer documentation. In my opinion, the problem is that Apple doesn’t “dogfood” the documentation. Internally, the developers at Apple don’t refer to the same documentation that third party developers have access to. Instead, internal developers have three private ways to learn about an API (I learned about this from a good friend that has been an Apple engineer for decades):
- Apple has an internal Wiki with non-public API documentation
- All internal developers have access to the source code, so they can just look there
- If 1 or 2 doesn’t work, they simply contact the person that originally wrote the code, or if they are no longer at Apple, someone else on the original team.
The end result is that internal Apple developers don’t care that the public documentation sucks - it doesn’t affect them. And management clearly doesn’t care either. The end result is lower quality 3rd party software with more bugs, but Apple management clearly doesn’t care about that either, though they certainly want to make sure that their commission rolls in.
This certainly hasn’t always been the case. I released my first app for the Mac in 1984, and in those days the “Inside Macintosh” books set the standard for fantastic documentation. The AppKit documentation in the early 2000’s was also very good, especially the detailed overview documentation. Unfortunately, not only did they stop writing these kinds of overviews, they have removed most of these from their developer portal. Fortunately I snagged literally over a hundred of these PDF files 10-15 years ago. They mostly contain content that is still valid and valuable, though obviously they don’t contain anything helpful about Swift, SwiftUI, or anything else modern.
One exception - the Swift Language Guide is quite good. It feels like a throwback to the early 2000’s documentation. But in general, the Swift team really operates as if it was in a different universe compared to the UI frameworks teams. It would be nice if some of the Swift team management styles could “infect” the frameworks teams.
P.S. So far, I think this is an excellent episode of the podcast. Even though David and Stephen aren’t developers themselves, they did an excellent job of directing the conversation and asking great questions. As a long time developer myself, I am definitely enjoying this episode. 