Mike Ash says:
When __bridge_transfer is used in a cast, it tells ARC that this object is already retained, and that ARC doesn’t need to retain it again. Since ARC takes ownership, it will still release it when it’s done.
Clang documentation says:
(__bridge_transfer T) op casts the operand, which must have non-retainable pointer type, to the destination type, which must be a retainable object pointer type. ARC will release the value at the end of the enclosing full-expression, subject to the usual optimizations on local values.
Nowhere in the Clang documentation does it say that __bridge_transfer avoids a double retain. It only says that the object is released sometime in the future.
Why does this matter? Consider the following code snippet:
NSString *value = (__bridge_transfer NSString *)CFPreferencesCopyAppValue(CFSTR("someKey"), CFSTR("com.company.someapp"));
The CFStringRef starts out with a retainCount of +1. When it is assigned to value, the CFStringRef is retained again because, by default, value is strongly referenced. This results in a double retain. At the end of the scope, a -release is sent to value, but nothing else exists to balance the lingering retain from CFPreferences*Copy*AppValue, resulting in a memory leak.
How does __bridge_transfer avoid a double retain?
Clang’s documentation agrees with Mike Ash. It says it performs a cast, and the object is released at the end of the scope. There is no retain performed during the cast.
Basically,
(__bridge_transfer T)causes the value to be treated as an already-owned value of typeT, just as how calling[T new]would return an already-owned value of typeT.