While working on my not quite super-secret autolayout project, tracking multiple sets of constraints was the largest friction point. Destroying all of the constraints if I didn’t need to was both slightly wasteful, and it was creating unintended consequences in the layout regeneration.
My first storage method involved a NSMapTable using the affected views (weak memory, with pointer personality) as keys and storing NSArray objects of the relative constraints. It worked up to a certain level of complexity, but it required wrapper methods to add/remove data. With one table of constraints (padding / spacing) it wasn’t bad, but when I added a second table (equality) it needed separation into a more reusable class.
When working on the reusable class, it became obvious that tracking the UIView to NSLayoutConstraint relationship in the data storage mechanism was redundant as the NSLayoutConstraint class tracked the views that a constraint directly touches internally. This meant I could write a function to return all of the constraints that affect a view without having to store that relationship myself. The next thing that I realized is that most of the things I wanted to do were the exact use case that NSSet/NSMutableSet makes easy, particularly the common case of removing all constraints that affect a view for that constraint set if the relative properties were changed.
I’m considering trying out NSHashTable as a backing mechanism, I’m not sure if I want the storage class to weakly retain the constraints, and if that will let me remove some of explicitly required cleanup functions in the class, but the base prototype is not working with a NSSet backed class, and I have some fairly complex autolayout code that requires minimal code in subclasses to make it work, and only slightly more code to make it work with animation.