Best Practices with nil in Objective-C

NSString *myString = nil;

is the same thing without nil, so just keep it off:

NSString *myString;

The same goes with properties. Remember that nil is equivalent to 0 which is equivalent to NO for a BOOL type. So no need to do this:

@property (nonatomic, assign) BOOL didLoad;
...
didLoad = NO;

Setting an initial value of NO is unnecessary since all variables start with nil so didLoad is already NO.

if (self.delegate) {
   if ([self.delegate respondsToSelector:@selector(@"didFinish")]) {
      [self.delegate didFinish];
   }
}

This can be simplified, since if the delegate is nil, nil can receive messages which will evaluate to nil, so here it is simplified:

if ([self.delegate respondsToSelector:@selector(@"didFinish")]) {
   [self.delegate didFinish];
}

if (myObj == nil)

can be simplified to

if (!myObj)

Also avoid the !=:

if (myObj != nil)

this is hard to read and look how simple this is:

if (myObj)

if (a.b.c)

So this will evaluate to false if a, b, or c are nil. This is perfectly ok, so no need to do this:

if (a) 
   if (a.b) 
      if (a.b.c) 

I've noticed a lot of code in the past where I'd set an array to be empty: @[] rather than just letting the array remain nil, or uninitialized. It's ok to let things be nil. If you have an array object that is nil, checking its count has the same behavior as if it was an empty array. For example, the following conditional will evaluate as true for both myArray = nil and myArray = @[]

if (myArray.count == 0)