automatic-ref-counting

Do we have to send removeObserver: explicitly for objects that have been added as observers to an NSNotificationCenter before? I am bit confused and unable to find the exact answer for this. Please provide me in detail, about this including why we need to removeObserver explicitly, and why don't compiler put it implicitly in class/application? rckoenes Yes, you need to call removeObserver: , if you don't the observed class could call all deallocated instance of the observer. From 10.11 observers are not required to un-register in their deallocation method. NSNotificationCenter and

If I declare a property strong, like so: @property (strong, nonatomic) UIView *iVar; When I'm setting it, does it matter if I do iVar = ... or self.iVar = ... ? It seems that with ARC, they do the same thing. If I only declare the instance variable (not the @property), e.g., BOOL selected , does that mean it's inferred to be __unsafe_unretained (since there's no property specifying it to be strong), or must I explicitly specify that? It seems like I may have answered my own questions above in answering ARC: How to release static variable? , but I'm still slightly confused on the above

I have this code that uses "__bridge" to cast the ids of colors: CGColorRef tabColor = (5 == 5 ? [UIColor blueColor].CGColor : [UIColor greenColor].CGColor); CGColorRef startColor = [UIColor whiteColor].CGColor; CGColorRef endColor = tabColor; NSArray *colors = [NSArray arrayWithObjects:(__bridge id)startColor, (__bridge id)endColor, nil]; CGGradientRef gradient = CGGradientCreateWithColors(colorSpace, (__bridge CFArrayRef)colors, locations); but would: NSArray *colors = [NSArray arrayWithObjects:(id)CFBridgingRelease(startColor), (id)CFBridgingRelease(endColor), nil]; CGGradientRef gradient =

I am trying to do some runtime programmation on Objective-C. In order to do this I override the resolveClassMethod method. Unfortunately I come up with some compilation error with clang when ARC is active : error: no known class method for selector 'dynamic' Everything works fine if I use gcc or clang without ARC ( -fno-objc-arc option passed), except a warning instead of the error. I am aware that ARC need to know the name of the method called to figure out how to manage the memory with returned value (following method name convention). But how to this issue without an ugly performSelector

So I just found out that ARC is only supported for devices running iOS 4.0+. How does my app (in the store) work on devices running iOS 3.0 then (definitely using ARC)? I'm so confused. Solution from below: As long as I don't use zeroing weak references it seems that using ARC still works with iOS 3.x, but Apple just has not guaranteed the result. ARC is mostly a compile time feature, the compiler inserts the appropiate release calls. AFAIK only zeroing weak references need runtime support. So as longs as you don't use those you're on thin ice, but it can work. Because ARC works at compile

If I have a closure passed to a function like this: someFunctionWithTrailingClosure { [weak self] in anotherFunctionWithTrailingClosure { [weak self] in self?.doSomething() } } If I declare self as [weak self] in someFunctionWithTrailingClosure 's capture list without redeclaring it as weak again in the capture list of anotherFunctionWithTrailingClosure self is already becoming an Optional type but is it also becoming a weak reference as well? Thanks! The [weak self] in anotherFunctionWithTrailingClosure is not needed. You can empirically test this: class Experiment { func