"ARC is awesome, but I highly suggest that you don’t use it until you can manage memory yourself. In other words, don’t rely on ARC until you understand what it’s doing."
This is not good advice.
ARC is meant to free the programmer from having to think about memory management and allow us to instead think about what we're trying to express in our object graphs and algorithms. Deciding where to call retain and release is an old, tired dance and is where the vast majority of memory leaks and app crashes come from. With ARC, we can just relax and let the compiler insert all those pesky retains and releases where it knows they should go.
There is no reason for newcomers to learn the old style. If a newcomer is reading old-style code, she can skip over the retain/release calls and pretend they're not even there, because they don't affect the algorithm.
I very strongly disagree. ARC still reveals the underlying nuts and bolts, necessitating a basic understanding of reference counting systems.
It doesn't solve retain cycles, thus requiring the judicious use of __weak in cases where a retain cycle may emerge. Determining where such a cycle may occur requires understanding reference counting. This significantly impacts your expression of algorithms where the simplest/best implementation may involve cyclic object graphs.
Additionally, ARC does not handle mixing CoreFoundation and Foundation code directly, requiring one to manually express bridging rules based on an understanding of reference counting.
It may be that ARC gradually smooths out its rough edges, and we find ourselves in a situation similar to GC, where developers need only understand the difference between weak and strong references, and the opportunities that exist there for leaks caused by maintaining strong live references.
However, we're still a bit far from that point, and newcomers should remain well-aware of retain/release and the vagaries of reference counting systems.
I agree (with you, nupark) For example, thr other day I was debugging a crash in my Cocoa (ARC) app. I've been programming Cocoa since 10.1, although I stepped away for a few years.
Anyway, random crash. My "manage memory manually" training knew it was an object getting released too early: I know I needed to retain it. Think think think... Of yes, my @property declaration was missing a retain declaration. Of course cocoa was releasing that object!
ARC sure helps, and between it and use of the autorelease pool (thanks Brent Simmons!) I hardly have to worry about memory management at all - except when I do, then I need to know what ARC is or is not doing behind the scenes.
Here in Europe we almost exclusively drive standard shift cars only. In fact, I've never driven an automatic shift car until very recently when I've visited my American girlfriend's parents the first time and found that's it's simply impossible to rent a standard shift car in the US. After a few hours I had to realise that modern automatic transmission systems these days are so good that unless you have special needs, there's simply no need to drive or even to learn to drive stick shift anymore. They're incredibly smooth and clever and completely abstract away the complexity of changing gears. It's like magic.
However, ARC is not quite there yet. It's a very useful tool but it's still a rather imperfect abstraction. You have to understand the problems with loops in object graphs, strong and weak references and why they're needed, bridging and all the other things ARC can't do for you yet. Maybe in a few years it will be possible to completely forget about memory management but today you simply cannot write a well behaving Objective-C application without understanding what's happening under the hood when it comes to memory management.
I agree with the general sentiment, but you're not free from all memory management. If I've never learned about it, how do I know when to make something strong vs weak? How about bridging from CF types?
ARC is a step in the right direction, but it doesn't free newcomers from ever learning about memory management.
Apple's ARC documentation explains how to deal with those kinds of things. It's as accessible to an iOS beginner as retain/release are, perhaps more so. Specifically, regarding strong vs weak, the point is that you are to think about your object graph instead of thinking about memory management.
Here's how I learned iOS dev (still not wildly experienced, but I'm familiar with the beast).
If you're a Rubyist, pick up PeepCode's Objetive-C for Rubyists. You're going to watch that multiple times.
Then, go and get yourself a subscription at teamtreehouse.com and subscribe to Stanford's CS193P (a fantastic course taught by Paul Heggarty) on iTunes U.
Treehouse's iOS 4 badges' topics are somewhat aligned with the topics on CS193P. You should watch the topic on treehouse first, and then watch the corresponding Stanford lecture, which will be much more detailed and a bit heavier. Having watched the treehouse videos, though, you'll have a basic understanding of what Paul is talking about, and the progression will seem very natural.
Set aside 1-3 hours a day for this. The basic things I learned in a day, the more complex ones like CoreData took me a bit longer. If you don't fancy the homework assignments on iTunes U (the first one is rather boring, the other ones are ok and practical), do something else that uses what you learned.
Two weeks of 2-3 hours a day and you'll be on your way.
I came to Objective-C from Java (server side web apps) and it really was quite a shock. However, once I got past the syntax , I found that it was just another OO language. Encapsulation, inheritance, interfaces, they were all there. I will say that while Apple (and the web) provide lots of examples of specific implementation details, they usually don't get past the simple stage of that one API. It's a bit more challenging to put all of them together in a way that is both good form and sensible for your problem.
Very helpful for getting your mind around basic concepts.
Re: Interface builder. I think the trick is knowing when to use it and when not to. Certainly it is incredibly useful for getting your layout exactly as you want it. (This was a refreshing change from html) But it can be cumbersome if you're trying to share common interface elements via subclassing or without wanting to load a nib file every time. Occasionally I would use it just to get the layout right and then implement the same interface in code.
I was in a similar situation a few years ago, but I opted for Monotouch [1]. I still had to learn UIKit, Foundation etc, but I didn't have to learn a "new" language. I did have to hack together a Visual Studio package to trick it into loading monotouch project files, but it was like 10 lines of code, and now you don't have to.
I did spend several months developing (and shipping) two Objective-C apps for the few months that Apple banned Adobe AIR (and everything else along with it), and despite having spent 30 years programming, and a good part of that in C and C++, the full awfulness of ObjC was a surprise. But if all you've ever done is C#/WPF, ObjectiveC is going to be quite a shock. In fact there'll be a lot of cognitive dissonance.
1. Build an app in Interface Builder.
2. Learn Cocoa Touch. The breadth of the library is more intimidating than the complexities of Objective-C.
3. Learn C and Objective-C.
Then think about paying apple to develop, releasing products, learning how memory management works, adding core data...
I'm a new Cocoa developer (on OS X) and can attest to the mental pain of accepting Interface Builder if you're used to programming other GUI frameworks. Usually I stick my neck out and comment on HN when I know what I'm talking about or I think I have an interesting question, but here I'll speak as a noob, for what that's worth. (I'm speaking so that people who know what they're talking about can get the perspective of somebody who doesn't, in other words. Please don't make fun of me, but corrections would really help.)
The first mental sticking point for people used to other frameworks is that you really must use Interface Builder as a beginner, even if it seems undesirable or unnecessary. Drag and drop an NSFooView in Interface Builder, and it will be nicely initialized and will act the way you expect. Instantiate an NSFooView in code, and you have a debugging task ahead of you, because the defaults you get when you init an object in code are different from the defaults you get when you create it in Interface Builder. It doesn't look or act the same at all. You end up creating the same object in Interface Builder just so you can inspect its attributes and try to set them to be the same in your code, maybe running your Interface Builder code in the debugger to see how the object behaves. (I assume the same is true of UIFooViews, though their default configuration might be closer to what Interface Builder creates since iOS interface objects are newer, code-wise, than the NextStep-derived objects used in Cocoa on OS X.) It's hard work to do things the wrong way. Someone used to another UI framework can put themselves through a lot of misery trying to figure out how to accomplish things in code without the help of Interface Builder, before they realize Interface Builder is an important part of the framework, not just a minor feature of Xcode that you can easily do without.
Another major cause of disorientation is that the learning curve is shaped very differently because of Interface Builder. In a framework that doesn't have a GUI builder, the beginner documentation holds your hand line by line through the code required to create a window, instantiate UI elements, configure them to behave properly, add them to a container, and specify how they're laid out. Why all that? Because you can't do anything without being able to do that! You can't pop up "Hello World!" with a button below it saying "Hi there" unless you can do all of the above!
With Interface Builder you don't have to do any of that in code. It's just drag, drop, done. No need for a twenty-page tutorial that explains containers and layout managers and the event-handling loop.
But here's the thing. There isn't much more to a typical UI framework than containers, layout managers, elements inside the containers, and events. So the "beginner" tutorial in a typical framework holds your hand across all the territory you need to master, and a decent book will explain the things that the tutorial glossed over. By the time you're able to make the button under "Hello World!" change the text to "Ha ha ha fart face" you've learned all the fundamentals, and you can reason things out for yourself. You're self-sufficient! From that point on, the rest of the learning curve consists of reading documentation for the various framework elements you need to use (individual widgets, menus and menu items, layout managers, framework APIs for background tasks, keyboard shortcuts, persistence of preferences, etc.)
Interface Builder, on the other hand, makes it so easy to get a simple application up and running that programmers are assumed to spend a certain amount of time at the static layout level. If you try to jump ahead and create a more complex app (what I think of as a realistically complex application) then you're already leaving beginner territory. If it's your first app, then you're trying to take the curve too fast. Personally, it's been weeks and I don't feel self-sufficient. I don't grok GUI development in OS X at all; I can't fend for myself at all in Cocoa-land; and it feels like I'm shamefully slow at accomplishing these things. Creating widgets at runtime and laying them out dynamically (because I don't know at compile time how many widgets I'll need and of what type -- I SWEAR IT -- I will kill any man who questions it) is just killing me. All of the documentation seems to assume I know what the hell I'm doing much more than I actually do. The response I get from other beginners when I ask about dynamically creating and laying out views is, "You're braver than me!" which isn't true. I'm not brave! I'm a shivering, sniveling noob! I want this to be beginner stuff! But the Interface Builder learning curve is shaped completely differently. What I'm trying to do follows naturally from noob tutorials in other GUI frameworks, because it's really hard to be a noob in other frameworks. In Interface Builder, it's easy to be a noob. How you get beyond that is still a mystery to me, though.
Pre-noob question: what do you mean by "NSFooView"? Googling for it revealed almost nothing, so I take it that you made up the term as a stand-in for some general case. Yes? If so, does NS mean something? Even something that is just a joke or related only to your example? And are you using "Foo" as a reference to the general stand-in phrases "foobar" and "foo = bar"? These questions are sincere, and if you get a chance to set me straight I would seriously appreciate it.
NS is the prefix for Cocoa classes on OS X. It dates back to NextStep. NSFooView is a stand-in for various subclasses of NSView that are the basic UI components in Cocoa. If you open an OS X nib (see below) in Xcode and select "Data Views" or "Layout Views" you'll have a choice of NSView subclasses to add to your UI: NSTableView, NSOutlineView, NSSplitView, and so on. Custom UI components usually subclass NSView.
A nib is a file created by Interface Builder that contains serialized objects that can be reconstituted at runtime. An xib is an XML file that compiles to a nib. An xib is somewhat human-readable and (if you keep the target platform exactly the same) can be somewhat usefully diffed as you modify the interface. I'd like to explain more, but my lack of understanding of the precise nature and use of nibs is part of what makes me a noob.
Thank you. Understanding what abbreviations stand for has always been an obsession of mine, and knowing the origin of "NS" may actually make learning this stuff much easier for me. I really appreciate your taking the time.
Also, because Objective-C doesn't support namespaces like C++, the prefixes sort of serve as a namespace and are there to prevent naming collisions. It's only a convention though, not a requirement.
Started reading and here we go: "Apple gives Xcode away FOR FREE, [...] you can GET IT."
About Apple's this and that: "WONDERFUL" (new compiler service), "which [...(does miracles)] FOR YOU", "arc is AWESOME"
Long story short - there are a lot of evangelist's marks badly hidden that convey into "acceptance and humility" - requested, and... oh yeah: "pay Apple".
This is not good advice.
ARC is meant to free the programmer from having to think about memory management and allow us to instead think about what we're trying to express in our object graphs and algorithms. Deciding where to call retain and release is an old, tired dance and is where the vast majority of memory leaks and app crashes come from. With ARC, we can just relax and let the compiler insert all those pesky retains and releases where it knows they should go.
There is no reason for newcomers to learn the old style. If a newcomer is reading old-style code, she can skip over the retain/release calls and pretend they're not even there, because they don't affect the algorithm.