Reddit mentions of Cocoa Design Patterns

While this doesn't specifically cover designing complex applications, I still found it a great resource for designing the inner workings of my apps: http://www.amazon.com/Cocoa-Design-Patterns-Erik-Buck/dp/0321535022/ref=sr_1_1?ie=UTF8&qid=1382636637&sr=8-1&keywords=Cocoa+Design+Patterns

You should check out appcode, it's basically objective-c intellij. I've been using it instead of xcode for a while now, it's excellent.

As for the cocoa-touch framework, I think your issues with it come from a lack of understanding of the design patterns behind objective c. You admit in your post that you've only done a single project in objective c. I develop in ObjC professionally, and I find cocoa touch to be one of the best frameworks I've ever worked in. I can quickly and easily implement any type of ui I want, without hitting language or api constraints.

>I've only done one real Objective-C project, but before I do another, I'm seriously going to spend the time to wrap these retarded classes in my own so I can write the last 20% that's missing and save myself hours of development time anytime I need to implement one in the future. And that's just disappointing to me to see how much time apple spends on making sure their user experience is top notch, but then completely ignores and drops the ball on their developer experience.

This is a terrible idea. Just trying to save you some time. If you want a better use of your time, check out this book - http://www.amazon.com/Cocoa-Design-Patterns-Erik-Buck/dp/0321535022

The other issue that you run into with Objective C is that there was kind of a gold rush on the app store that has lots of terrible developers who have no idea what they're doing writing objective c and talking about it on forums, which gets picked up on your searches. There's a huge amount of faulty information on objective c online, which is a bit disheartening.

The other point that I have to make is that iphone apps are fast. Compare an iphone app to an android app, see which is faster and smoother. This is often down to the table view apis and their optimizations. Stuff like having a separate function for serving up the size of your cells falls into this category.

>Implimenting a pickerView or tableView is absolutely retarded.

I don't see the issue in the apis here. You have a view that has a pointer to a data source and a pointer to a delegate. The data source implements functions from a protocol that return the cells for the rows that the view asks for, and the delegate implements functions that get called by the view when certain things happen. This approach gives you far more flexibility in the architecture of your application than requiring you to pass stuff directly into your view object.

This book, updated for Swift.

I've also been trying to 'level up' my iOS dev skills, and cannot recommend Effective Objective-C 2.0 enough, as well as Cocoa Design Patterns.

Something else I've been doing is making my way through the Apple Programming Guides and sample code, and I've learned a lot just from that.

There is one book you need to have i you're going to be using Cocoa. Once you get a footing with Objective C as a language, you should buy yourself a copy of Cocoa Design Patterns. This covers Cocoa by teaching you first the rationale behind it, then shows you how to do things.

Also, this would probably be a worthwhile read, if only for the terminology it introduces.

Good luck!

EDIT: I personally learned Objective C using this book, and I'd recommend it to you as well.

https://www.amazon.com/Cocoa-Design-Patterns-Erik-Buck/dp/0321535022

this book:

http://www.amazon.com/Programming-Objective-C-Edition-Developers-Library/dp/0321711394/ref=pd_sim_b_1


and this book:

http://www.amazon.com/Cocoa-Design-Patterns-Erik-Buck/dp/0321535022/ref=pd_sim_b_7


and this guy:

http://www.raywenderlich.com/

http://www.amazon.com/Cocoa-Design-Patterns-Erik-Buck/dp/0321535022
for ios oo design