In Objective-C, an object’s life cycle and its ownership qualification are not the same thing. The former is about how long the object itself lives in memory. The latter is about the different behaviors of ownerships towards what the object refers to in the different stage of the objects’s life cycle.

If an object is declared with retainable object owner type, but without an explicit ownership qualifier, its type is implicitly adjusted to have __strong qualification.

As a special case, if the object’s base type is Class (possibly protocol-qualified), the type is adjusted to have __unsafe_unretained qualification instead.

Source: http://clang.llvm.org/docs/AutomaticReferenceCounting.html#objects

NSDictionary from NSData | Cocoanetics

#import "NSDictionary+Helpers.h"
@implementation NSDictionary (Helpers)
+ (NSDictionary *)dictionaryWithContentsOfData:(NSData *)data
	// uses toll-free bridging for data into CFDataRef and CFPropertyList into NSDictionary
	CFPropertyListRef plist =  CFPropertyListCreateFromXMLData(kCFAllocatorDefault, (CFDataRef)data,
	// we check if it is the correct type and only return it if it is
	if ([(id)plist isKindOfClass:[NSDictionary class]])
		return [(NSDictionary *)plist autorelease];
		// clean up ref
		return nil;

Template and Guideline on Git Commit Message

Here is a template originally written by Tim Pope at tpope.net and mentioned in the Pro Git book

Short (50 chars or less) summary of changes

More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together.

Further paragraphs come after blank lines.

- Bullet points are okay, too

- Typically a hyphen or asterisk is used for the bullet, preceded by a single space, with blank lines in between, but conventions vary here

From Documentation/SubmittingPatches in the Git repo:

Describe your changes in imperative mood, e.g. “make xyzzy do frotz” instead of “[This patch] makes xyzzy do frotz” or “[I] changed xyzzy to do frotz”, as if you are giving orders to the codebase to change its behavior.  Try to make sure your explanation can be understood without external resources. Instead of giving a URL to a mailing list archive, summarize the relevant points of the discussion.