> Android (and I believe iOS does too) enforce that.
This is absolutely not true. Android simply detects that there has been no progress on the UI thread "for a few seconds" before force-closing the app [1]. By this time, the interaction has been janky/frozen for WAY too long. If you have seen bad iOS scrolling and lock-ups, you know this as well.
I have worked on mobile software for these apps that have billions of users. When I pointed out how much stuff ran on the UI thread, there was a collective "this is just the way it is" response and life went on.
It's super-depressing.
-----
[1] "Performing long operations in the UI thread, such as network access or database queries, blocks the whole UI. When the thread is blocked, no events can be dispatched, including drawing events.
From the user's perspective, the application appears to hang. Even worse, if the UI thread is blocked for more than a few seconds, the user is presented with the "application not responding" (ANR) dialog."
Attempting a network operation on the Android UI thread will throw the android.os.NetworkOnMainThreadException exception, and has done since API 11 (Honeycomb) in 2011.
Correct. Looking at the Windows side of things, most of the UWP APIs are designed to be async, meaning they will never block the UI thread.
The author is giving the OS a unfair rep here. All three major OS has solutions to this problem. It's more up to application makers to use the tools correctly.
Android (and I believe iOS does too) enforce that.
It's up to the developer to show a meaningful message/animation if an IO operation takes noticeable time.