Definitely not a good way to introduce new programming languages to newbies.
http://www.h4labs.com/dev/ios/swift.html?age=90 - Last 90 days
Take a look at a weekly view: http://www.h4labs.com/dev/ios/swift.html?week=0
Most topics get sufficient coverage. If you don't mind paying a small monthly fee, Ray Wenderlich's site has lots of tutorials that are well maintained. Plenty of free examples too:
Another pay site that is be useful if you want to come up to speed quickly is http://nsscreencast.com
However, I was an iOS dev 3-4 years ago and wanted to learn swift - so, it was a pretty smooth upgrade for me. I think whoever wants to learn iOS dev might be better off learn the basics more thoroughly and then come back to this course.
Apple is horrible about bugs and providing feedback. Why the heck would I need to file a radar anyway? Doesn't someone at Apple check the examples to make sure they still work? These are the examples Apple uses to promote and teach the language and how to build apps.
Yes, they can be a bit tight-lipped. I have found that they're pretty quick on fixing documentation though. They won't tell you that it's resolved, but it's usually updated within a couple of days.
> Doesn't someone at Apple check the examples to make sure they still work?
I'd expect that they do, but some slip through the cracks. Maybe on of the Apple engineers in this thread could weigh in?
Developer documentations should start following API like structures. For example, in API land we have:
/api/v1/users
/api/v2/users
This means that making requests to v1 will only work with v1 and v2 only with v2. This makes sure that the API you are connecting to is using the correct parameters for its version.Going back to documentations, they should state in the examples or in the documentation that this document is written for V2 of swift or anything more specifc. Even better would be sticking to Semver like specifications for the versioning.