These property attributes fall into three categories for different ways in which they change the way that your property works. The first ones are atomic and non-atomic. Most difficult part in Objective-C. Many times developers end up in dilemma about which property we need to use when.

Eventually, Memory Management in iOS has been improved with the years after ARC (Automatic Reference Count) comes in the market. We need not to deal with alloc, dealloc, deinite.

Atomicity

Atomic(Default)

Defining a property as atomic will guarantee that a valid value will be returned. Notice that valid does not always mean correct.

Atomic is what you get if you don’t specify anything.

This also does not mean that atomic properties are thread safe. Different threads can attempt to write and read a the same time. One of two values will be returned — the value before the change or the value of the change

Atomic properties suffer from minor performance hit due to locking and unlocking before and after setting/getting a value.

Non Atomic

When it comes to non atomic properties, only thing you get is the speed to access these properties. It has no guarantee to return a value. Everything is possible with this thype.

You may get null, you may not. Surprisingly, return value could be the correct one, a partially written value or even some garbage value.

Access

After atomicity there are two modify access. Which known as readonly and readwrite

readonly

readonly makes it so this property is read-only. There is no setter for it at all. One caveat is that it cannot be readonly to everyone else, but readwrite to me: if you say readonly, it is read-only to everybody, including you.

readwrite (default)

On the flip side, there is readwrite, which, of course, allows both read and write. That is the default; again, if you do not write anything, you have a readwrite property.

What if you want one property that works as readwrite to you, but readonly to everybody else? In your interface file you would declare it as readonly, but in your implementation file, you would create a class extension and redefine it as readwrite. The keyword in the interface communicates to others that they cannot write to (a.k.a., change) the property. However, the class extension at the top of your implementation (.m) file will redefine the property with the same name, only as readwrite instead, allowing you to write to the property within the implementxation file.

Storage

The final attribute of properties. Development in iOS becomes a bit easier with the release of ARC version of memory management and situation like memory leaks get handled many times automatically.

Strong: Strong is the newer form of retain. Till iOS 4, we were using retain in place of strong. Strong simply defines ownership of the object. Lifecycle of the object will be remain until owner itself didn’t dealloc the object. We generally use strong with the parent of objects i.e., in case of UI Elements, we use strong with UIViewController.

Retain: Retain also owns the object property. In general scenario, retain is used when we want to remove the previous value once new setter come for the same object.

Weak: Weak is simply a pointer and will work only if the object is being owned by some strong property. We generally use weak to avoid Retain Cycle. Retain cycle simply says that if A points to B strongly, B points to C strongly and if in any scenario C also seems to point A strongly then it will create a deadlock in between all A,B,C property. To avoid retain cycle, we generally make our either transition weak in place of strong. Weak property are generally used with IBOutlets, Delegates and other Objective-C references.

Assign: Assign is the older version of weak attribute. Till iOS 4, we were using assign in place of weak attribute. Assign is majorly used with primitive datatypes like int, float etc.