1. While this is somewhat nitpicking from an abstract point of view, in terms of implementation details you don’t call methods on objects in Objective-C, but instead pass messages to them. It may seem nothing but it is a significantly different way of doing things as you can pass a message to an object that doesn’t respond to it, but can’t call a method on an object that doesn’t respond to it which opens up all sorts of powerful features (similar to those found in Ruby or Python).

2. In terms of running code, connections are just instance variables. In terms the seemingly magical connection made between coding and runtime they are quite different to their opposite number: actions. Actions use the standard NSControl methods setTarget: and setAction: (remember Interface Builder is working with actual objects, not representations of them). Connections on the other hand and linking actual objects to a proxy object (your controller). When the NIB is loaded at runtime, this proxy object is replaced with the instance of your controller objects and then the instance variables are hooked up to the actual objects, either via accessor methods if they exist, or directly accessing the variable if they don’t.

3. id is not equivalent to Object. NSObject is equivalent to Object. Saying something is Object or a subclass means that Object has to be one of the superclasses. This is the same with NSObject, but id allows objects that aren’t subclasses of NSObject. In a nutshell, id is dynamic typing, NSObject is static typing. This often helps with compiler warnings. For example:

NSObject *myArray = [NSArray array];
[myArray count];

Would give a warning that NSObject may not respond to the method count, even though NSArray is a subclass of NSObject. However:

id myArray = [NSArray array];
[myArray count];

Would give no warning. The compiler just cares that some object somewhere responds to count and trusts the object to handle the message if it doesn’t (either by discarding it or forwarding it to another object). It also helps get rid of generics or the need for casting (you’ll notice that all collection classes in cocoa use id rather than NSObject).

4. Obviously this doesn’t help on the iPhone, but if you were to ever program for the Mac there is a class in Foundation called NSSound which would simplify your sound code to:

[[NSSound soundNamed:@"filename"] play];

Unfortunately this is one of the many classes that is missing from the iPhone.

Anyway hope this helps