KudoCC KudoCC - 1 year ago 81
Objective-C Question

If we build with 9.3 SDK and deploy to the device which system version is below 9.3, is the delegate `weak`?

I suddenly found that UIKit use

attribute instead of
in 9.3, it may already changed for a long time but I didn't notice that, feeling shamed.

@property(nullable,nonatomic,weak) id<UIScrollViewDelegate> delegate;

I noticed that because of a question. In the old days, we need set the delegate of
's delegate to nil in
method in case of crashing.

Now since SDK 9.3 has use
attribute for
, I think if we build our apps using the newest SDK and deployment to any devices which system version are above iOS5 (weak attribute is involved at iOS5), we don't need to set the delegate to nil in

However in the question I mentioned above, I have left a comment: "I'm curious to know if it would crash when you use the newest SDK to build and deploy to devices which are below iOS 9. Can you have a try? " and the answer is "Yes, the base SDK is "Latest iOS (iOS 9.3)". And it still crash if I doesn't set delegate to nil in dealloc method. ". I'm confused.

My question is if we build with 9.3 SDK and deploy to the device which system version is below 9.3 (I mean the SDK which use
rather than
attribute), is the delegate

Hmm there is another question, if we build with 9.3 SDK, can we deploy to devices which system version is below iOS 5.0 (says 4.3, it don't support weak attribute) ?

Answer Source

As you say, the weak attribute has been available since iOS 5. If you declare a variable as weak, it gets set to nil when the object it points to is deallocated.

If you make a delegate property assign rather than weak it's a good habit to set it to nil in your dealloc method, but it should not cause a crash if you fail to do so.

It doesn't usually cause a crash because at the completion of the dealloc method, the object in question is freed, so the value in that property is irrelevant.

Setting an assign property to nil is much more important in the case where the object it points to is deallocated, but the object doing the pointing is not being deallocated. In that case failing to set the property to weak can lead to a zombie.


OK, I just followed the link to the question you referred to. I get it now. That link was talking about a UITableView's delegate property. In some older iOS version (not sure when it changed) the tableView's delegate property was assign, not weak. Thus, when you have a view controller that serves as a table view's delegate, you should set the TABLE VIEW'S delegate property to nil in the view controller's dealloc method, to avoid cases where the table view tries to make a call to it's delegate (your view controller) after it's been deallocated.

I'm not sure if this is a real problem though, since the only thing that should have a strong reference to the table view is the view controller's view hierarchy, and when the view controller is deallocated, so is it's entire view hierarchy.

In answer to your question, what would matter is the OS version you are running on. UITableView is a system class, and the version of UITableView compiled into the OS determines the memory management rules for it's delegate. If UITableView declares it's delegate as assign on a given OS version, then it won't get set to nil when the object is deallocated.