NSCollectionViewLayout _visibleSections leaks like crazy?

Just revisited this issue in my project. I should correct my original post. The _visibleSections method that is leaking is in a private class NSCollectionViewLayoutAccessibility.

The only workaround I can think of, is swizzling the method and returning nil. Doing that works around the memory leak, which can become pretty significant over time, especially if the collection view has lots of items in it. I imagine I wouldn't be able to release on the MAS....and also would be worried that in Apple's private implementation the return value of that method could get passed to a method that requires a nonnull argument....and maybe they'll.raisie an exception (haven't ran into this yet, but vodoo is vodoo).

Hope this gets fixed 😮

It won't get fixed if there's no bug report written. 😉

Can you toss a simple sample project in a bug report and post the number here?

Sure. Thanks for responding. I just attached a sample project to the bug report.

Bug number is

25831410

I'm having the exact same issue but I can't figure out what you mean by swizzling the method? I thought we are not able to access private classes. Any response is appreciated.

We aren't allowed to access private APIs. You can override a private method (or swizzle it) if you know the method. You wouldn't be able to send the app to the App Store though. It is prohibited.

If you want to learn about method swizzling you can Google around for a tutorial. You shouldn't swizzle methods unless you really know what you are doing though.

Oh okay, thank you for your response. I would like to send my app to MAS but I am pretty sure It would get declined due to this leak... It skyrockets to 200-300 leaks in a single scroll. Did you get any response in your bug report? Ever found any workaround? The only option I haven't tried is setting up the collection view through code. I'm pretty much clueless.

Thanks in advance.

I'm unaware of an App Store approved workaround. I haven't looked into this in awhile. My app is on the store. I'd just go forward with it if I were you. I haven't had any customer emails complaining about memory issues. You can't control what you can't control.

I guess you could try to switch to IKimageBrowserView and go old school (I think IK has some leaks too, unrelated to this), or use an open source alternative.

Alright so a few days ago I managed to get to a workaround (almost forgot to post here). Basically you have to create the collection view programatically. Initially after setting it all up the collection view did not appear but after a bit of googling I found out that you have to wrap it in a scrollview. However this would also set the enclosingScrollView variable of the collection view which just reproduced the leaks from earlier. So the solution which I came up with was overriding the variable and setting it to nil. This prevented the leaks but also prevented the creation of all the items in my collection view (it only created those which would fit the collection view frame - my guess is that the collection view calculates how many it can produce based on the enclosingScrollView content size). The final solution was to wrap it in two scroll views, one as a simple wrapper for the collectionview, and another "main" scroll view which would hold our first scroll view with its collection view. You also have to subclass the first scrollview and redirect the scroll events. The only downside which I've noticed is a bit slower scrolling. Sounds a bit confusing but it works. 🙂

Cheers

Interesting. Thanks for sharing. I don't think i'll implement that workaround, seems too complicated and I'm not sure if that would create any unintended issues. Also it seems that scrolling performance in NSCollectionView doesn't seem to be that fast normally so I'm not sure if sacrificing scrolling performance is better. Not sure if it's just me but since I linked against 10.12 I think scrolling may have gotten slower.

I guess since my bug is still open the issue didn't get resolved in 10.12 (will have to check that soon). My iMac is on 10.12 by my Macbook Pro is not (installing it now) and I'm not near my iMac.

If this didn't get fixed it's kind of a bummer, especially since it looks like this issue is something that could get fixed in less than 15 minutes if you had access to the source code.

I'm no longer seeing the leak in when profiling in Instruments in Xcode 8 on Sierra. It looks likey did fix it actually. Thanks Apple