gistfile1.m

- (void)myMethod {
	NSError* error = [NSError errorWithDomain:@"myDomain" code:42 userInfo:@{ @"Foo": @"Bar" }];
	
	NSString* file = [NSBundle.mainBundle pathForResource:@"Info" ofType:@"plist"];
		
	NSData* data = [NSData dataWithContentsOfFile:file options:0 error:&error];
	
	// safe
	if(data == nil) {
		// only access error if data was nil
		NSLog(@"%@", error);
	}
	
	// unsafe
	NSLog(@"%@", error); // error is stilll my error. no nil assignment	
}

I think this was not the question, rather it was if the following is 'wrong' (as some unnamed source supposedly claimed:

NSError *error = nil;
id result = [fooMethodWithError:&error];
if (error == nil) {
    // All good
}
else {
    // Something went south
}

I think the question was it is good to do the folliwing:

- (BOOL)myMethod:(NSError**)outError {
    if(outError != NULL) {
        *outError = nil;
    }
    return YES;
}

and the answer is no you shouldn't because it is a different behaviour then all the Apple methods.

Well, question was: "I've heard people say it's wrong to assign nil to NSError and then check after the call if it's still nil."
In my opinion, your code is not wrong or bad, just not as performant as it might be, because you are checking if outError == nil in every case (whereas Apple is only checking that if there actually is an error to report).