I'm really hoping somebody at Oculus/HTC/Microsoft sees this and wants to develop it, because I agree the hardware industry needs to step up its game to make this a reality.
Android Lead from Capital One SF here. I did and it was one of the best hires I ever made. He's the most enthusiastic and motivated person on my entire team, and is also amazing at UI and performance optimization. I've been begging them to send me more candidates ever since.
If "most cases" means the average small team (2-3 developers), then you probably have a point. Once you have more than that, I think it's absolutely necessary to enforce code style in this way.
Yeah this is the general idea we went with. We did our best to synchronize around it, but unfortunately we can never have total control, which necessarily introduces race conditions.
I would imagine this is what leads to the 0.4% crash rate I mentioned at the top of the article :-(
We do this for various other reasons (clearing possibly corrupted state, etc), but we've never uploaded the statistics to the servers. We may begin doing this in the future.
We've been using Crittercism in the past and recently switched to Crashlytics, unfortunately memory crashes are one of the few exceptions (hah) to the rule, as they are SIGKILLs from the OS.
Another commenter recommended touching a file at launch and at sleep to track untraceable crashes, which we do for various other reasons, but don't upload the stats. We may begin doing this.
I won't argue too strongly on this, as you're far more knowledgable about it than I am.
However, imo the intention and semantics behind a call like CFMakeCollectable implies a transfer of ownership to an external system. A newbie Apple coder could be forgiven for thinking it would still transfer ownership in RC environments, just to the autorelease pool instead of a collector. In all likelihood this is what happened. An intern got at the code and didn't know the details about GC.
Obviously the point stands that this interpretation is well-documented to be false, but its naming is definitely misleading.
Double edit:
I see from your edit that some of my basic assumptions about CFMakeCollectable were wrong, having never actually worked with it. My bad.
I would disagree pretty strongly with that. The function CFMakeCollectable is explicitly a function for dealing with the garbage collector, and its unpredictability in non-garbage-collected code is the direct cause of the bug.
Doesn't it make sense to say that without the existence of Apple GC, the bug never would have existed? Doesn't that at least somewhat justify the title?
edit:
Furthermore the original intent of including garbage collection in the title was as an ironic twist based on the fact that ios has never had garbage collection. Maybe that didn't convey as well as I would have liked.
I should clarify. iOS does not have garbage collection and has never had garbage collection. The root of this bug is in old legacy cruft from the garbage collected days of OSX. The code is dormant in a lot of old CoreFoundation classes, and still causes unexpected behavior from time to time.
I should note that, while we saw something like 0.4% increased crash rate, we actually don't have a number to compare it against for memory crashes.
This is because if memory usage gets too high, the OS will send a kill signal to the process, which can be neither detected nor caught.
This means that in our original decision to use this fix, all we had was anecdotal evidence of untraceable crashes. Luckily we had dedicated QA that was keeping pretty solid track of them all, and they piled up.
I've been thinking about this since yesterday, and it seems like a really good solution for some use cases, but isn't there quite a bit of overhead to using a dispatche queue for fine-grained operations? I mean it seems like the overhead of cross-thread communication would severely outweigh a simple synchronous lock call.
Then again, if you can do things like background non-essential operations, then the higher-level benefits can probably outweigh that.
That would certainly be an interesting project, although the performance implications on a mobile platform may be an issue (although that's becoming more moot with each generation).
In this case, however, our goal was to take common, familiar interfaces and idioms in Objective C, and make them safer/more powerful.
Something more like channels-like would be quite useful, but it would likely be published under a different project.