Objective-C Coding Convention and Best Practices

Tram Ho

Most of these tutorials are in accordance with Apple’s documentation and the best practices accepted by the community. Some are derived from personal preferences. This document aims to establish a standard way of doing things so people can do things the same way. If there’s something you don’t like about these tutorials, then you should do it to suit everyone else.

This document is primarily aimed at iOS development, but certainly also applies to Mac.

Operators: Operators

++, -, etc. are prioritized after variables instead of before to match other operators. Separated operators must always be surrounded by spaces unless there is only one operand.

Data type: Types

Use NSInteger and NSUInteger instead of int, long, etc. according to Apple’s best practices and 64-bit security. CGFloat is preferred over float for the same reasons. It proves this future for 64 bit platforms.

All Apple data types should be used on primitive types. For example, if you are working with intervals, use NSTimeInterval instead of double even though it is synonymous. These are considered best practices and make the code more transparent.

Methods: Methods

There must always be a space between – or + and the return type ((void) in this example). There should be no spaces between the return type and the method name.

There should never be a space before or after the colon. If the parameter type is a pointer, there must always be spaces between the class name and *.

There must always be a space between the end of the method and the opening parenthesis. Open frames should never be in the following line.

There must always be two lines between methods. This fits some Xcode patterns (although they vary a lot) and increase readability.

Pragma Mark and how to organize

An excerpt of a UIView:

Methods should be grouped according to inheritance. In the example above, if some UIResponder methods are used, they should go between the NSObject and UIView methods because that’s where they are in the inheritance chain.

Control structure: Control Structures

There must always be a space after the control structure (for example, if, else, etc.).

If / Else

The else should start on the same line as the previous if .

If comments are desired around the if and else , they must be formatted as in the above example.


Parentheses are expected around each case. If multiple cases are used, they should be on separate lines. default should always be the last case and must always be included.


When iterating using integers, start with 0 and use <instead of starting at 1 and using <=. Quick listing is often preferred.


  • Import

Always use @class in header files instead of #import because it has the effect of increasing compilation time.

From Objective-C Programming Guide :

The @class directive minimizes the amount of code seen by the compiler and linker, and is therefore the simplest way to give a forward declaration of a class name. Being simple, it avoids potential problems that may come with importing files that import still other files. For example, if one class declares a statically typed instance variable of another class, and their two interface files import each other, neither class may compile correctly.

Header Prefix

Adding frameworks used in most projects to the prefix header should take precedence. If these frameworks are in the prefix header, they will never be imported into the source code in the project.

For example:

#import <Foundation/Foundation.h> should not be imported in the project except in the prefix header.

Properties: Properties

If the attribute is nonatomic , it must be first. The next option must always be retain or assign because if it is omitted, there will be a warning. readonly should be the next option if it is specified. readwrite is never specified in the .h file. readwrite should only be used in class extensions. getter or setter should last. Setter is seldom used.

Private Methods and Properties



Private methods must always be created in a class extension for simplicity because a named category cannot be used if it adds or modifies any properties.

Note: The example above provides an example for using the readwrite property accepted.

Extern, Const, and Static

Name: Naming

In general, everything should be prefixed with a 2-3 letter prefix. Longer prefixes are accepted, but not recommended.

It is a good idea for prefix classes with an application specific application if it is application specific code. If there is code you plan to use in other applications or find open source, you should do something specific for your company or your prefix.

If your company name is Awesome Buckets and you have an app called Buck Hunter, here are a few examples:


Share the news now

Source : Viblo