Cleaning up your Xcode: Beauty in simplicity.

Have you found yourself wondering why your code is so verbose in Objective-C? Does [NSNumber numberWithInt:3] seem like too much code to write to represent the number 3? Do you have pointers to properties declared in your .h and then synthesized in your .m? I have been guilty as well of having my head stuck in writing code without looking up to see the new best practices. Researching online can lead to divergent and sometimes outdated trends. What you will find below are simple tips to clean up your code and make it more manageable and readable.

The Header File

One of the purposes of the header file (public interface) is for others to use the class you created. They want to know what class your class extends and what are the publicly accessible methods, properties and protocols. If they are not public put them in the .m file. Others using your class don't want to waste their time reading about the implementation. Encapsulation of your data protects your code from unintended consequences.

Private Properties

The @interface in the .m file, known as the class extension, is where the private properties are declared. You would then refer to them in your code with an _propertyName. There is no longer a need for @synthesize except in cases where you might override both the getter and setter yourself. You only need to use self.propertyName when you want to use the setter and getter methods.

Another way to simplify your code is to use ivars instead of properties. This can be an advantage with primitive data types. For example, the BOOL in the sample below is an ivar. Disadvantages of using ivars are no thread safety, no automatic getters/setters, and you cannot use Key Value Observing (KVO).

@interface ViewController ()
 @property(nonatomic,strong)NSString *name;
@implementation ViewController{
 BOOL isCool;
- (void)someMethod
	_name = @"Juliet";
	isCool = YES;
IBOutlets and IBActions

Under most cases there is no need to make either IBOutlets or IBActions public. In the @interface class extension put all your IBOutlets and in the @implementation your IBActions. You can still wire them up through Interface Builder.

@interface ViewController ()
	@property (weak, nonatomic) IBOutlet UIButton *button;
@implementation ViewController
- (IBAction)buttonTouched:(id)sender {
 NSLog(@"button was touched");
Objective C – Literals

As easy as making an NSString *name = @"Luke", Objective-C literals are making other data types easy to instantiate as well. For instance:

NSNumber *number = @12;

The term for this is boxing. The back end of this still uses [NSNumber numberWithInt:12]. Unfortunately, especially for those of us with a Java background, there is no unboxing, at least yet.

Here are examples of using literals with NSArray and NSDictionary:

NSArray *arr = @[ @"Cap", @"Tech", @2102, @YES ];
NSDictionary *dict = @{@"key1":@"value1",@"key2":@12};

To create a mutable array or dictionary you call mutableCopy.

NSMutableArray *mutate = [arr mutableCopy];
NSMutableDictionary *mutableDict = [dict mutableCopy];

Subscripting using ‘[ ]' syntax is yet another way to simplify your code.

NSLog(@" %@",arr[0]); //accessor
mutate[1]=@"newValue"; //modifier
NSLog(@"value for key %@",dict[@"key1"]);//accessor
mutableDict[@"key2"] = @13; //modifier

To find out more about Objective-C Literals you can access the official documentation at or view a handy quick reference at


The inspiration for this blog was from attending sessions at the 2012 Cocoa Conference in Raleigh, NC where I had the privilege of attending sessions by Mark Dalrymple and Daniel Steinberg.

This post presents ideas on simplifying your Xcode projects. Hopefully I didn't offend those that get paid by the number of lines of code they write. There is beauty in the art of writing efficient code that doesn't give you Carpel Tunnel from having to type excessively. It is also easier to read and modify. If you've got questions you may contact me at