Nabeel Writes

A deep dive to explore!

atomic vs nonatomic properties in Objective-C — November 26, 2016

atomic vs nonatomic properties in Objective-C

The difference between atomic and non atomic properties remained a favourite question for interviewers. Today we will analyse these keywords in detail. These keyword define the characteristics of how these properties will behave once they will be accessed from multiple threads simultaneously.

atomic (Default)

As the word explains itself, a single thread will be able to access the property at a given time. To explain more, only one thread will be able to access getter/setter of a property. Other threads have to wait until first thread releases get/set method. Let’s say we have a property firstName which is atomic.

- Thread A => obj.firstName=@"A"
- Thread B => obj.firstName=@"B"
- Thread C => NSLog("First Name: %@",obj.firstName);

It will ensure that the value of property remains consistent throughout the lifecycle. By default all properties are atomic.

Example atomic property:

@property (strong,atomic) NSString *firstName;
@property (strong) NSString *firstName;

Sample getter setter: This is how the methods of a property will look for an atomic property after

@synthesize firstName = _firstName;
-(NSString *)firstName{
    @synchronized (self) {
        return }
-(void)setFirstName:(NSString *)firstName{
    @synchronized (self) {
        if(_firstName != firstName){
            [_firstName release];
            _firstName = [firstName retain];

Note: the Objective-C 2.0 specification, mentions that locks are used internally, but it doesn’t specify exactly how. What you see above, is roughly what an atomic getter/setter would look like, but it might not be accurate.

Pros: Ensures that user gets a valid value and not some garbage

Cons: Slow, as it has code to ensure read write safety


For non atomic properties multiple threads can access the properties simultaneously, so there is always a risk of inconsistency between values


@property (strong,nonatomic) NSString *firstName;

Sample getter setter: This is how the methods of a properties will look for an atomic property

@synthesize firstName = _firstName;
-(NSString *)firstName{
    return _firstName;
-(void)setFirstName:(NSString *)firstName{
    if(_firstName != firstName){
        [_firstName release];
        _firstName = [firstName retain];

Pros: Fast as compared to atomic properties, as there is no extra code to control access of multiple threads

Cons: You are not guaranteed whether or not you will receive a valid value


  • Thread safe vs Read/Write Safe
  • When is code created for properties i.e how & getter and setter code is created?
  • When to use atomic vs non-atomic some solid rules?
  • Detailed Pros & Cons
  • Multi-threading on Single CPU vs Multiple threads

Further Reading

Dispatch Objects in GCD —

Dispatch Objects in GCD

Grand Central Dispatch (GCD) is a technology by Apple to manage multiple cores of hardware at system level. As GCD is built at lower level and closer to unix system, it can manage muliple cores and developer do not have to worry about it. GCD provides a set of APIs which a developer can use to submit code blocks (dispatch objects) to it, after that GCD can do its magic.

Dispatch Object lifecycle

When compiled with Objective-C compiler dispatch objects behave like normal Objective-C objects. They are reatained and then released at the end of their lifecycle automatically in ARC.

Further Readings

OCLint integration in XCode with xctool —

OCLint integration in XCode with xctool

In a hurry to do things fast and meet monster deadlines, developers keep the book of best practices aside and start coding. The result can lead to unexpected behavior in your project along with highly unmanaged code. Start following best practices of coding, with time it will become a habit.Even the experienced programmers sometimes can’t foresee the issues embedded in their code.

OCLint comes with a huge list of options which are way too lengthy anc can’t be covered in a single reading. In this tutorial we will cover best configurations suggested by OCLint documentation for XCode project.

About OCLint

OCLint is a static analyzer for C, C++ and objective c. The documentation to kick off your relationship with OCLint is huge and you will be jumping from one page to another in pursuit of something, something digestible. In this tutorial our goal is to Install, Integrate & View Analysis report of OCLint in XCode objective-c project.



If homebrew is configured on your system, you can use homebrew tap for oclint.

$ brew tap oclint/formulae
$ brew install oclint

And can be simplified to

$ brew install oclint/formulae/oclint

Use following commands to update to latest version

$ brew update
$ brew upgrade oclint

2. Download

Ignore it if you have completed installation via Homebrew.

Go to OCLint Releases on github and download latest oclint-{versionno-architecture-OS}.zip/ Extract the files.

  |--bin (Contains OCLint commands, from here you can execute it)
  |--lib (Contains clang static analyzer, reporters and rules library)

Set Path

Once installation is complete you can set path in terminal


Verify Installation

Check whether installation is successful. If you see the output listed below, congratulations you did it.

$ oclint
oclint: Not enough positional command line arguments specified!

OCLint Commands

1. oclint

OCLint comes with rich set of options which you can use with ‘oclint’ command. In terminal type $ ocline --help to get detailed list of configurations.

2. oclint-json-compilation-database

It is great that OCLint provides us options to specify each file’s configurations. But in practical life our projects contains hundreds of files and it will give you a headache to do this manually. Here comes the solution oclint-json-compilation-database

Integration with XCode

1. Create a new aggregate Target

Name the target OCLint.

Add new runscript.

Add the following script to new run script.

echo "Building ${TARGET_NAME}"
#Add OCLint bin directory to PATH
export PATH=/usr/local/Cellar/oclint/0.10.2/bin:$PATH
#Set Build path
#Check whether OCLint exists or not
hash oclint &> /dev/null
if [ $? -eq 1 ]; then
echo "OCLint not found, analyzing stopped"
exit 1
echo "OCLint is installed"
#Navigate to build path directory

if [ ! -f compile_commands.json ]; then
echo "compile_commands.json not found, possibly clean was performed";
echo "Removing compile_commands.json"
rm compile_commands.json
# clean previous output
if [ -f xcodebuild.log ]; then
echo "Removing xcodebuild.log"
rm xcodebuild.log


#Clean, Build and generate compile_commands.json project
xctool -project DemoOCLintTargetInProject.xcodeproj \
-configuration Debug -scheme DemoOCLintTargetInProject \
-sdk iphonesimulator  \
-reporter json-compilation-database:${BUILD_PATH}/compile_commands.json clean build

echo "Starting analyzing"
oclint-json-compilation-database -v -e Pods oclint_args \
"-max-priority-1=$maxPriority -max-priority-2=$maxPriority \
-max-priority-3=$maxPriority -rc LONG_LINE=500 \
-rc LONG_VARIABLE_NAME=100  -disable-rule=UnusedMethodParameter" \
| sed 's/\(.*\.\m\{1,2\}:[0-9]*:[0-9]*:\)/\1 warning:/'

Sample project

DemoOCLintTargetInProject is the project we used for above demo and is published on git.