2 ms·

There used to be a behavior in UIKit where you could scroll a view and tap to stop the view and quickly tap a button to move on to another screen, and at some p

There used to be a behavior in UIKit where you could scroll a view and tap to stop the view and quickly tap a button to move on to another screen, and at some point in time when Apple moved away from skeuomorphism, the UIView scroll behavior changed in a way that from then on forced users to wait for scrolling to stop before tapping a button, but they also injected a full fraction of a second, probably somewhere between 200 to 600ms before you could interact with UI controls again. iOS has felt so stupidly slow since then, because you're waiting for all of these dumb screens to swipe and pan and you can sit there and tap a button in the middle of all of this like 3-5 or more times and the damn phone does nothing until everything is all settled and complete, and only then will it listen to your tap event. Who are these utter grandpas who make these stupid UI decisions?

jwells89 3y ago
> There used to be a behavior in UIKit where you could scroll a view and tap to stop the view and quickly tap a button to move on to another screen, and at some point in time when Apple moved away from skeuomorphism, the UIView scroll behavior changed in a way that from then on forced users to wait for scrolling to stop before tapping a button, but they also injected a full fraction of a second, probably somewhere between 200 to 600ms before you could interact with UI controls again. Is this specific to certain types of scroll views? I just played around in my Mail app inbox (most likely built with UICollectionView) initiating flick-scrolls and then double-tapping to stop the scroll and select the message under the tap and it works exactly like the original behavior you describe with zero delay.