We actually use GCD a lot. In components we use a background queue for allocating and measuring/laying-out component trees and then we punt them over to the main queue for "mounting" (attaching them to UIViews that we create or recycle and configure).
For the mem-models portion we also use GCD all over the place. However when we had mutable models (and used Core Data) we had data races, something GCD can't really help you. Moving to immutable models actually makes our system work really well with GCD because you can pass immutable objects around threads without much concern really.
For autolayout, we did some explorations and ultimately decided (especially for low-end devices) that having our layout calculations occur on the main-thread was too cpu-intensive for some of our more complex-layouts (which are quite common in feed).
Before mem-models we explored what the best cutting-edge practices were in using Core Data but ultimately we were using it as a cache and not as an ORM - wrong tool for the job.
Before components we looked at vanilla UIKit, re-approaching an MVC-style architecture given the lessons we had learned, and using Autolayout instead.
>we had data races, something GCD can't really help you.
Thank you so much for bestowing that insight. But I think you should read the docs on dispatch_barrier_sync() and dispatch_barrier_async() before claiming GCD couldn't have helped with the problems you were seeing in your code base.
For the mem-models portion we also use GCD all over the place. However when we had mutable models (and used Core Data) we had data races, something GCD can't really help you. Moving to immutable models actually makes our system work really well with GCD because you can pass immutable objects around threads without much concern really.
For autolayout, we did some explorations and ultimately decided (especially for low-end devices) that having our layout calculations occur on the main-thread was too cpu-intensive for some of our more complex-layouts (which are quite common in feed).
Before mem-models we explored what the best cutting-edge practices were in using Core Data but ultimately we were using it as a cache and not as an ORM - wrong tool for the job.
Before components we looked at vanilla UIKit, re-approaching an MVC-style architecture given the lessons we had learned, and using Autolayout instead.
I hope this provides a little more insight.