Modern Objective-C uses automated reference counting. C++ advice isn't really applicable unless you're writing Objective-C++ (which is a thing that exists) but even there you're often dealing with ARC'd objects from Cocoa and so you can't really use the normal C++ patterns in many cases. (I'd disagree with the general start-with-smart-pointers approach in pure C++, too, but I come from a game development background with regard to C++ and so there were more concerns related to it than most people necessarily have.)
rembrat: Objective-C pointers do point to memory addresses, but there's magic involved within clang to use them. Generally speaking (and this is really high level, there are places where it's not true) when you store an Objective-C object (anything inheriting from NSObject[1]) in a new variable, the thing it points to has its reference count incremented. When that variable no longer points to that, it's decremented, and when this count hits zero, it's deallocated and its memory is freed. In most cases, this means you don't need to dealloc yourself, but there are still instances where you might end up in non-ARC code (lots of libraries) so you do need to know when ARC is live or not.
You cannot allocate Objective-C objects on the stack (denoted by being a not-pointer, i.e. TypeName rather than TypeName*). You can allocate C structs on the stack, such as NSRect or NSPoint; these are just dumb chunks of data ordered in a predictable way (i.e., CGFloat[2]-CGFloat-CGFloat-CGFloat for an NSRect or CGFloat-CGFloat for NSPoint). If you have a pointer to a C struct, like an NSPoint*, it's a dumb pointer, so you have to handle memory management yourself--generally you'll allocate these on the stack, though, and they'll be automatically dealt with as they go out of scope. There are also cases where a library or something may return to you a pointer to a C type, and then you have to read the documentation to know whether you own the pointer (in which case you'll need to free it yourself) or whether it's still owned by the library and you just dereference it for data.
Long and the short of it, it's all pretty fucked and unless there's a reason you need Objective-C (instead of Java, MonoMac, etc.) I'd strongly consider looking elsewhere. It's possible to write very good Objective-C, but I wouldn't really recommend it as first-time exposure to a lower-level language. Too many weird things and too many inconsistencies.
Also, never ever use dot syntax in Objective-C because it obscures whether you're dealing with a struct or an object and makes it way harder to reason about.
[1] - You can have objects that don't inherit from NSObject but there's no good reason to do so when working with either iOS or OS X.
[2] - The definition of CGFloat changes from platform to platform. There are a few other data types for which this is true. Make sure you know what they are on your platform.