What types of retain cycles can be generated with ARC?

The main memory-related problem is the cycles of retain. They occur when an object has a pointer strong to a second object, and that object has a pointer strong to the first. Even when all references to these objects are removed, they still reference each other and will not be deallocated. This can also occur indirectly, through a chain of objects whose last in the chain refers to the first.

To understand this type of problem, it is important to know how memory management works on iOS. There is no garbage collector ; instead, the reference counting mechanism is used. Each pointer strong adds 1 to the reference counter of the pointed object (in this case, it is said that the pointer retains the object). When the pointer stops pointing at the object, the object's reference counter is decremented by one unit (the pointer is said to drop the object). The object is deallocated when your reference counter reaches zero.

That's why there are the modifiers __unsafe_unretained and __weak. __unsafe_unretained does not retain the object it points to (i.e., it does not increment the object's reference counter), but if the object is deallocated, the pointer points to invalid memory. The __weak does not retain the object and changes the pointer to nil when the object is deallocated. These modifiers are used to point to delegates , since in general you don't want a object retain its delegate, which could lead to a loop.

Another important point is that ARC does not manage type memory in C, such as those in the Core foundation framework (e.g. CGImageRef), which are allocated using malloc() (or through a function that calls malloc()). You are responsible for managing the memory of these objects in a way that prevents memory leaks.

(based on https://stackoverflow.com/questions/6260256/what-kind-of-leaks-does-automatic-reference-counting-in-objective-c-not-prevent)

ARC is a great help in solving memory leak problems, however, this does not mean that the programmer is free of responsibilities in relation to this. While there is a strong reference pointing to an object it will be alive (spending memory).

This means that it may be interesting to remove all strong references from an object (object = nil), so that it dies at a certain instant rather than letting it die at the end of the application.

It is also important to use weak references whenever possible to avoid this type of problem.

If there is no such care the objects will stay alive forever, even when totally useless to the progama.

Ignoring for a moment the theoretical part, which has already been well discussed by the other answers, you can have a more practical view of these problems (at least at more basic levels) by running Clang Static Analyzer through Xcode itself.

This tool should not be used as a definitive answer to problems, but it can present an initial view of the most critical points of your application.

XCode > Product > Analyze (Preferably with target/scheme set to device).

Another common problem has to do with blocks, for example if we have a property in a class that references a block and right inside the block we use self we can create a circular reference.

@property (nonatomic, copy) MyBlock block;

self.block = ^{
                NSLog(@"object is %@", self); // retain cycle
            };

__weak me = self; 
self.block = ^{
                    NSLog(@"object is %@", me); // no retain cycle
                };