Hmm, I do not understand the Travis failure. It seems to tell me that I should format a file that I didn't touch :/

Looks like the engine repo is red on travis for master, so that failure was probably not introduced by you: https://travis-ci.org/flutter/engine/builds/334200934

+1 to @chinmaygarde's comment. First thing to do is clarify who's responsible for object lifetime, then clean up what's there and stop relying on just the shared dict for ref-count. Everyone using an NSObject should manage their own inc/dec of the refcount.

PTAL. In this new version I made parent a weak pointer, and children a strong ref-counted array of pointers. On top of that, I null out children's parent pointers eagerly inside the parent's destructor because there's no guarantee about when the child's destructor is called (iOS may continue holding references to children after we cleared them out). A similar relationship is established between SemanticsObjectContainer and SemanticsObject. After this change, SemanticsObject only holds strong references to it's children. So strong references always point down the tree, and weak references point up the tree and cleared out eagerly.

Update: I can no longer vouch for existence of a leak. It seems I have been reading the Instruments UI wrong. Many of the objects listed in it have ref count == 0.