>> 'I can't help but feel like some of the hoops you have to jump through for it make it a tremendous pain in the ass.'

Any examples? I've only played with it a little but I'm thinking of doing my next app in Swift instead of Objective-c.

There's a lot of manual management of potential null-values. Which may be a good thing for app stability but is ugly in code. Currently you also get a lot of mysterious crashes and very often the debugger is useless when you do. So it's back to print statements to find errors. As the language and runtime matures this will be less the case.

Probably the biggest issue with Swift right now though is that it has to accommodate all the older Cocoa APIs so in practice it's often just a slightly nicer syntax for the same code. Cocoa functions tend to return untyped values or things like NSArray so you have to do a lot of manual casting, etc.

Yeah, all of the manual casting (which I feel like sometimes takes more trial and error than it should to get to compile) and the awkward null checking are the two most painful points. The debugger being basically useless is a problem, but it's something that will get fixed eventually. I have less faith in the first two points though because initially they were less painful but in later betas they became more painful.