>I don't know iOS inernals, but to me it looks like they started using multiple threads for the UI? Smart when you want to update multiple areas of the screen at once, buggy when multiple areas have to sync animations?
iOS has always used separate threads for UI rendering standard since GCD was added in iOS 4. This is just lazy mistakes and poor QA.
I'm pretty sure that iOS renders UI on a single thread? You can't even create UIImageViews off the main thread without risking severe breakage. Fortunately, modern Xcode has an Analyze option that will flag attempts to access UI off the main thread.
GCD is a nice API for scheduling async tasks but that doesn't mean those async tasks can access UIKit or OpenGL contexts safely?
Correct, you need to do everything that touches the UI on the main thread. But I never ran into problems that it would lead to frame drops, scrolling frame drops are because too large calculations are done (especially on the main thread) while displaying a new cell. I don't say it's trivial always to do complex stuff in a non-blocking way but if I can do it probably somebody working at Apple can do it too.
I‘m intrigued where you got that info. As an iOS dev, I can tell you that an app should not access UIKit stuff off-main-thread. Facebook does off-main-thread layouts [1], but they still rely on backing views on main thread.
Or do you mean that the rendering/compositing itself is multithreaded?
>I‘m intrigued where you got that info. As an iOS dev, I can tell you that an app should not access UIKit stuff off-main-thread. Facebook does off-main-thread layouts [1], but they still rely on backing views on main thread.
Right, I wasn't implying UIKit stuff is done multi threaded. I just meant that the best practice is to do all your UI work in the main thread, and use GCD for any blocking operations which shouldn't be on the main (animation) thread.
iOS has always used separate threads for UI rendering standard since GCD was added in iOS 4. This is just lazy mistakes and poor QA.