[saurik]

Yet on iOS, if you do silly work in the main/UI thread (which is very easy to do, as that really is your main thread on which you handle all events, and is thereby something many/most applications you find actually do quite often), it will block all UI updates for that process; claiming that iOS is solving UI lag by having a dedicated UI thread that is marked "real-time priority" is, AFAIK, wrong.

In fact, it is this very property (that on iOS, all UI work must be done from the main thread) that often /causes/ UI lag, and yet somehow Android (where even this author admits using background threads for non-UI work "is the standard Android design pattern" in one of the comments on his post) is the one with the serious UI lag issues <- this mental contradiction is the key problem, and it would be awesome if someone (from Google or wherever) provides a strong explanation.

[conr]

iOS has the advantage that all apps go through an approval process. If someone is doing lots of work on the main thread and blocking the UI, the reviewer can catch it and suggest to the developer to make their code suck less.

[hack_edu]

Do people actually get any feedback like this?

[msh]

Yes, i had an app that in one place didn't asynch a webrequest and locked up the main thread. They emailed me about this.

[campnic]

If we are going to give an advantage I think it would go to Android if thats the only way you get feedback on iOS. Android pops up an Application Not Responsive message if your main thread violates responsiveness thresholds. This is a meta issue to mechanisms for debugging main thread vs. side thread coding.