Hacker News Reader

Comment by spearo77 | Hacker News Reader

While that's a decent summary of his current perspective, I'd wager that the biggest adjustment won't be memory management. Although that is a trap for new players, a bigger adjustment will be to think and code in the "Cocoa-way".

In my experience, Cocoa Touch has all the benefits of it's very mature Mac OS foundation, and to develop effectively, and minimise friction, you need adhere to the Cocoa way.

View on HN

I totally agree. All the quirks and idiosyncrasies of ObjC go away after a week of coding in it. What's more difficult to adopt is Apple's Cocoa framework. Coming from a background of most UI frameworks, Cocoa is just simply different from anything else out there. You're gonna find yourself going to developer.apple.com and stackoverflow.com for even the most basic tasks. It requires a different way of thinking about problems because the solutions are so different. Developers who have only dabbled in MVC will find themselves forced to adopt MVC and all its overhead for applications large and small.

A lot of my problems with learning Cocoa was when I fought the framework. Don't fight the framework, save yourself time.

I thought ObjC had garbage collection now?

Only on the Mac. I guess Apple feels the memory and/or performance cost is still too high for mobile.

I don't know the history here, but based on the autopool directives it looks like they toyed with the idea.

With gc enabled, [autoreleasePool drain] asks the gc to run (IIRC), with gc disabled, it releases everything currently owned by the pool. Even on the Mac, you may still want to build your app without gc for performance reasons, and Apple gives you that option.

I'm sure we'll see gc on iOS devices eventually, but it's probably too memory hungry to be practical on the phone right now.

Either that, or the objC gc isn't ready for a phone-constrained environment yet. Android seems to manage OK, but they put in a lot more up-front work into making it viable there.

The drain method releases the pool itself — it's precisely equivalent to release. This does release the objects in the pool as well, but a lot of people seem to think that drain leaves the pool valid. (The reason it was introduced is so the same method could be used in non-GC and GC code, where release is turned into a noop.)

NSAutoreleasePool is the same on both platforms AFAIK. Any vestiges of garbage collection you see are from there.

Reply on news.ycombinator.com