Here is a quick summary: A strong reference will keep the object it points to from being deallocated. A
weak reference will not. Thus instance variables and properties that are marked as weak are pointing at
objects that might go away. If this happens, that instance variable or property will be set to nil, instead
of continuing to point to where the object used to live.

Most strong reference cycles can be broken down into a parent-child relationship. A parent typically
keeps a strong reference to its child, so if a child needs a pointer to its parent, that pointer must be a
weak reference to avoid a strong reference cycle.
A child holding a strong reference to its parent’s parent also causes a strong reference cycle. So the
same rule applies in this situation: if a child needs a pointer to its parent’s parent (or its parent’s
parent’s parent, etc.), then that pointer must be a weak reference.
Apple’s development tools includes a Leaks tool to help you find strong reference cycles.

Memory management attribute
The memory management attribute’s values are strong, weak, copy, and unsafe_unretained. This
attribute describes the type of reference that the object with the instance variable has to the object that
the variable is pointing to.
For properties that do not point to objects (like the int valueInDollars), there is no need for memory
management, and the only option is unsafe_unretained. This is direct assignment. You may also see
the value assign in some places, which was the term used before ARC.
(The “unsafe” part of unsafe_unretained is misleading when dealing with non-object properties. It
comes from contrasting unsafe unretained references with weak references. Unlike a weak reference,
an unsafe unretained reference is not automatically set to nil when the object that it points to is
destroyed. This is unsafe because you could end up with dangling pointers. However, the issue of
dangling pointers is irrelevant when dealing with non-object properties.)
As the only option, unsafe_unretained is also the default value for non-object properties, so you can
leave the valueInDollars property as is.
For properties that manage a pointer to an Objective-C object, all four options are possible. The
default is strong. However, Objective-C programmers tend to explicitly declare this attribute. (One
reason is that the default value has changed in the last few years, and that could happen again.)

When a
property points to an instance of a class that has a mutable subclass (like NSString/NSMutableString
or NSArray/NSMutableArray), you should set its memory management attribute to copy.

Why is it safer to do this for NSString? It is safer to make a copy of the object rather than risk
pointing to a possibly mutable object that could have other owners who might change the object
without your knowledge.

In terms of ownership, copy gives you a strong reference to the object pointed to. The original string

is not modified in any way: it does not gain or lose an owner, and none of its data changes.

While it is wise to make a copy of an mutable object, it is wasteful to make a copy of an immutable
object. An immutable object cannot be changed, so the kind of problem described above cannot
occur. To prevent needless copying, immutable classes implement copy to quietly return a pointer to
the original and immutable object.

Note that if you implement both a custom setter and a custom getter (or just a custom getter on a readonly
property), then the compiler will not create an instance variable for your property. If you need
one, you must declare it yourself.

Declaring a property in a class interface only declares the accessor methods in a class interface. In
order for a property to automatically generate an instance variable and the implementations for its
methods, it must be synthesized, either implicitly or explicitly. Properties are implicitly synthesized
by default. A property is explicitly synthesized by using the @synthesize directive in an
implementation file