Here are some of the documents from Apple that informed the style guide. If something isn't mentioned here, it's probably covered in great detail in one of these:
- The Objective-C Programming Language
- Cocoa Fundamentals Guide
- Coding Guidelines for Cocoa
- iOS App Programming Guide
- Dot-Notation Syntax
- Spacing
- Conditionals
- Error handling
- Methods
- Variables
- Naming
- Init & Dealloc
- Literals
- CGRect Functions
- Constants
- Enumerated Types
- Private Properties
- Booleans
- Singletons
Dot-notation should always be used for accessing properties. Bracket notation is preferred when using methods and in other instances.
For example:
view.backgroundColor = [UIColor orangeColor];
[UIApplication sharedApplication].delegate;
Not:
[view setBackgroundColor:[UIColor orangeColor]];
UIApplication.sharedApplication.delegate;
-
Indent using 4 spaces. Never indent with tabs. This should be configured on the project.
-
if
/else
/switch
/while
and friends should always open on the same line as the statement, conditions like else or do that follow if or while respectively start in the same line where the previous condition ends.
For example:
if (user.isHappy) {
// Do something
} else {
// Do something else
}
- There should be exactly one blank line between methods to aid in visual clarity and organization. Whitespace within methods should separate functionality, but often there should probably be new methods.
@synthesize
and@dynamic
should each be declared on new lines in the implementation.
Conditional bodies should have braces, except when initializing and lazy loading.
For example:
if (!error) {
Field *field = [self.collectionView fieldForIndexPath:field];
return field.isValid;
}
even if it's one line
if (!error) {
return success;
}
Not:
if (!error)
return success;
Initializer
- (instancetype)initWithFrame:(CGRect)frame {
self = [super initWithFrame:frame];
if (!self) return nil;
return self;
}
Lazy loading
- (UILabel *)label {
if (_label) return _label;
_label = [UILabel new];
return _label;
}
The Ternary operator, ? , should only be used when it increases clarity or code neatness. A single condition is usually all that should be evaluated. Evaluating multiple conditions is usually more understandable as an if statement, or refactored into instance variables.
For example:
result = (a > b) ? x : y;
Not:
result = a > b ? x = c > d ? c : d : y;
When methods return an error parameter by reference, switch on the returned value, not the error variable.
For example:
NSError *error = nil;
BOOL shouldAcceptCalls = [self trySomethingWithError:&error];
if (!shouldAcceptCalls) {
// Handle Error
}
Not:
NSError *error = nil;
[self trySomethingWithError:&error];
if (error) {
// Handle Error
}
Some of Apple’s APIs write garbage values to the error parameter (if non-NULL) in successful cases, so switching on the error can cause false negatives (and subsequently crash).
In method signatures, there should be a space after the scope (-/+ symbol). There should be a space between the method segments.
For Example:
- (void)updatePersonWithName:(NSString *)name
andImage:(UIImage *)image;
In the method implementation opening bracket should always be placed in the same line as the last parameter:
For Example:
- (void)updatePersonWithName:(NSString *)name
andImage:(UIImage *)image {
// Implementation
}
In method invocations the parameters should be colon aligned, if the method becomes a cascade consider splitting the logic in several methods.
For Example:
[someObject updatePersonWithName:@"Example Text"
image:[UIImage imageNamed:@"Image.png"]
andDescription:@"Example description"];
Variables should be named as descriptively as possible. Abbreviated variable names should be avoided.
Asterisks indicating pointers belong with the variable, e.g., NSString *text
not NSString* text
or NSString * text
, except in the case of constants.
Property definitions should be used in place of naked instance variables whenever possible. Direct instance variable access should be avoided except in initializer methods (init
, initWithCoder:
, etc…), dealloc
methods and within custom setters and getters. For more information on using Accessor Methods in Initializer Methods and dealloc, see here.
When declaring a strong
property, you can leave out the strong
keyword as this is the default.
When declaring properties in public headers that contain mutable counterparts (NSString
, NSDictionary
, NSArray
) make sure to include the copy
keyword.
For example:
@interface HYPSection: NSObject
@property (nonatomic) NSString *headline;
@end
Not:
@interface HYPSection : NSObject {
NSString *headline;
}
Apple naming conventions should be adhered to wherever possible, especially those related to memory management rules (NARC).
Long, descriptive method and variable names are good.
For example:
UIButton *settingsButton;
Not
UIButton *setBut;
A three letter prefix (e.g. HYP
) should always be used for class names and constants, however may be omitted for Core Data entity names. Constants should be camel-case with all words capitalized and prefixed by the related class name for clarity.
For example:
static const NSTimeInterval HYPArticleViewControllerNavigationFadeAnimationDuration = 0.3;
Not:
static const NSTimeInterval fadetime = 1.7;
Properties and local variables should be camel-case with the leading word being lowercase.
Instance variables should be camel-case with the leading word being lowercase, and should be prefixed with an underscore. This is consistent with instance variables synthesized automatically by LLVM. If LLVM can synthesize the variable automatically, then let it.
For example:
@synthesize descriptiveVariableName = _descriptiveVariableName;
Not:
id varnm;
Prefer remoteID
or localID
when naming local or remote foreign keys.
For example:
Note *note;
note.localID = 12; // local
note.remoteID = 10; // from backend
Not:
objc
Note *note;
note.noteID = 1;
**or**
```objc```
Note *note;
note.noteId = 1;
Use pragma marks to structure your code. Sort them in a linear fashion, starting with the initialization, lazy loaded properties and other getters followed by the setters.
Private and custom delegate methods are added at the bottom.
Methods that overwrite their parent methods should be grouped in #pragma mark - PARENT_CLASS
#pragma mark - Initializers
#pragma mark - Getters
#pragma mark - Setters
#pragma mark - View life cycle
#pragma mark - Actions
#pragma mark - Notifications
#pragma mark - HYPBaseTableViewController
#pragma mark - UITableViewDelegate
#pragma mark - CustomViewDelegate
#pragma mark - Private methods
dealloc
methods should be placed at the top of the implementation, directly after the @synthesize
and @dynamic
statements. init
should be placed directly below the dealloc
methods of any class.
init
methods should be structured like this:
- (instancetype)init {
self = [super init]; // or call the designated initalizer
if (!self) return nil;
// Custom initialization
return self;
}
NSString
, NSDictionary
, NSArray
, and NSNumber
literals should be used whenever creating immutable instances of those objects. Pay special care that nil
values not be passed into NSArray
and NSDictionary
literals, as this will cause a crash.
For example:
NSArray *names = @[@"Brian", @"Matt", @"Chris", @"Alex", @"Steve", @"Paul"];
NSDictionary *productManagers = @{@"iPhone" : @"Kate", @"iPad" : @"Kamal", @"Mobile Web" : @"Bill"};
NSNumber *shouldUseLiterals = @YES;
NSNumber *buildingZIPCode = @10018;
Not:
NSArray *names = [NSArray arrayWithObjects:@"Brian", @"Matt", @"Chris", @"Alex", @"Steve", @"Paul", nil];
NSDictionary *productManagers = [NSDictionary dictionaryWithObjectsAndKeys: @"Kate", @"iPhone", @"Kamal", @"iPad", @"Bill", @"Mobile Web", nil];
NSNumber *shouldUseLiterals = [NSNumber numberWithBool:YES];
NSNumber *buildingZIPCode = [NSNumber numberWithInteger:10018];
Literals should be used when accessing NSDictionary
or NSArray
instances.
NSString *name = names[0];
NSString *productManager = productManagers[@"iPhone"];
Not:
NSString *name = [names objectAtIndex:0];
NSString *productManager = [productManagers objectForKey:@"iPhone"];
When accessing the x
, y
, width
, or height
of a CGRect
, always use the CGGeometry
functions instead of direct struct member access. From Apple's CGGeometry
reference:
All functions described in this reference that take CGRect data structures as inputs implicitly standardize those rectangles before calculating their results. For this reason, your applications should avoid directly reading and writing the data stored in the CGRect data structure. Instead, use the functions described here to manipulate rectangles and to retrieve their characteristics.
For example:
CGRect frame = self.view.frame;
CGFloat x = CGRectGetMinX(frame);
CGFloat y = CGRectGetMinY(frame);
CGFloat width = CGRectGetWidth(frame);
CGFloat height = CGRectGetHeight(frame);
Not:
CGRect frame = self.view.frame;
CGFloat x = frame.origin.x;
CGFloat y = frame.origin.y;
CGFloat width = frame.size.width;
CGFloat height = frame.size.height;
Constants are preferred over in-line string literals or numbers, as they allow for easy reproduction of commonly used variables and can be quickly changed without the need for find and replace. Constants should be declared as static
constants and not #define
s unless explicitly being used as a macro.
They should be located in the class that uses them, if they are shared between classes you can have them in the public header.
For example:
static NSString * const HYPAboutViewControllerCompanyName = @"Hyper";
static const CGFloat HYPImageThumbnailHeight = 50.0f;
static const CGSize HYPImageDefaultSize = {40.0f, 40.0f};
Not:
#define CompanyName @"Hyper"
#define thumbnailHeight 2
When using enum
s, it is recommended to use the new fixed underlying type specification because it has stronger type checking and code completion. The SDK now includes a macro to facilitate and encourage use of fixed underlying types — NS_ENUM()
Example:
typedef NS_ENUM(NSInteger, HYPAdRequestState) {
HYPAdRequestStateInactive,
HYPAdRequestStateLoading
};
Private properties should be declared in class extensions (anonymous categories) in the implementation file of a class. Named categories (such as HYPPrivate
or private
) should never be used unless extending another class.
For example:
@interface HYPAdvertisement ()
@property (nonatomic) GADBannerView *googleAdView;
@property (nonatomic) ADBannerView *iAdView;
@property (nonatomic) UIWebView *adXWebView;
@end
Since nil
resolves to NO
it is unnecessary to compare it in conditions. Never compare something directly to YES
, because YES
is defined to 1 and a BOOL
can be up to 8 bits.
This allows for more consistency across files and greater visual clarity.
For example:
if (!someObject) {
}
Not:
if (someObject == nil) {
}
For a BOOL
, here are two examples:
if (isAwesome)
if (![someObject boolValue])
Not:
if ([someObject boolValue] == NO)
if (isAwesome == YES) // Never do this.
If the name of a BOOL
property is expressed as an adjective, the property can omit the “is” prefix but specifies the conventional name for the get accessor, for example:
@property (assign, getter=isEditable) BOOL editable;
Text and example taken from the Cocoa Naming Guidelines.
Singleton objects should use a thread-safe pattern for creating their shared instance.
+ (instancetype)sharedInstance {
static id sharedInstance = nil;
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
sharedInstance = [[self alloc] init];
});
return sharedInstance;
}
This will prevent possible and sometimes prolific crashes.
This document is based on the NYTimes Objective-C Style Guide.