I suddenly found that UIKit use
@property(nullable,nonatomic,weak) id<UIScrollViewDelegate> delegate;
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.