Open Radar

 
===== Kenny Yin (05-Mar-2016 12:31 PM)

This issue really generates an unpleasant experience that makes a device feel unresponsive. Even if the intention to block input during animation is understandable, the real world implication is far beyond “during animation”. Often times, an animation is already visually finished (from what a user can see), taps often still fail to register, since either the animation is “easing out”, not logically finished or nearly approaching the end of animations. Users have to tap several times for their actions to register.


If input blocking during animation is really intentional, why do some areas of iOS SpringBoard and UI Kit block it and some don’t, where there’s no clear pattern/logic of which ones are blocked and which ones are not?

Here are some examples of animation blocking in iOS 9:

1) Zooming/fade-in-out to home screen animation (blocks tapping on apps, 3d touch and sliding screens) (this input blocking was added in iOS9, it wasn't present in iOS 8.4.1, example uploaded as SpringBoard_No_Block_8_4_1.mp4 and SpringBoard_No_Block_9_3.mp4). Notice how from a user’s perspective, even though the animation is visually over, taps still fail to register in iOS 9, causing the user having to tap the icon for multiple times. This issue also affects iPad more than iPhone, as it is super pronounced when using multitouch gestures to navigate back to home screen.

2) Editing animation for example when you tap on edit in Mail app or Clock app and immediately try to edit an item (this input blocking was added in iOS9, it wasn't present in iOS 8.4.1) Similar applies to Messages app. Example uploaded as Clock_app_input_blocking.mp4.:

3) Scrolling animation inside Chinese or Japanese input candidate field (added in iOS 7, wasn’t present before that, uploaded example: Keyboard_Candidate_Input_Blocking.mp4);

4) Rubber-banding scrolling animation (blocks tapping, 3d touch) when you scroll to the end of a list, and quickly tap the last item in the list, your input won't register until the rubber-band animation stops animating.

5) Notification/Widget panel sliding animation - for example with widgets (such as philips hue buttons in notifications panel), one has to double or triple tap in order to register, because usually the first tap won't register due to input-blocking.

6) When tapping outside the rounded rectangle to dismiss a folder, blocks tapping or 3D Touch shortcuts on any icon on home screen

7) Back/Forward animation (blocks tapping, 3D touch) - for example, in Mail, tap inbox and tap first message fast, it won't register.

8) From lock screen to home screen animation: no 3d touch allowed (Important use case, whenever you take your phone out and unlock it, the transition to home screen does allow tap input during animation, which is good, but it doesn't allow 3d touch)

However, many areas of SpringBoard and UIKit does not block animation in iOS 9:

1) Control Center (stuff like flashlight, camera are immediately available, no input blocking, good!)

2) iOS9 folders animation (only when closing a folder and immediately trying to open another)

Tapping home button when you are on a home screen other than page 1 - for example if you are in page 5 of your home screens, it brings you back to home screen page 1, but you can interrupt it and it will allow input during animation.

3) From lock screen to home screen animation: tap allowed, but not 3d touch(very important use case, whenever you take your phone out and unlock it, the transition to home screen does allow input during animation, which is good, but it doesn't allow 3d touch = bad)

4) Zooming/fade-in-out to home screen animation: when invoked via pinch gesture only confirmed in 9.3 b2, if you use pinch gesture to go to the home screen rather than home button and immediately try to tap an icon your input isn't blocked.

If all the above behavior, notable and arbitrary regression in terms of performance for users, is intended, then may I kindly ask you to modify the state of this radar to "Feature Request/Enhancement", so that there is a chance for this to be addressed in future versions of iOS.

I am not alone in this one. Just alone in one thread on a non-official Apple discussion forum, over 600 users have expressed their worries. Sample: http://forums.macrumors.com/threads/ios-9-vs-ios-8-4-1-unresponsiveness-due-to-input-blocking.1942001/

'Clock_app_input_blocking.mp4', 'Keyboard_Candidate_Input_Blocking.mp4', 'SpringBoard_No_Block_8_4_1.mp4' and 'SpringBoard_No_Block_9_3.mp4' were successfully uploaded.


===== Apple Developer Relations (02-Mar-2016 01:19 AM)

This issue behaves as intended.

We are now closing this bug report.

If you have questions about the resolution, or if this is still a critical issue for you, then please update your bug report with that information.

Please be sure to regularly check new Apple releases for any updates that might affect this issue.



===== Kenny Yin (27-Feb-2016 11:58 PM)

Summary:
iOS SpringBoard blocks input during transitions/animations, starting with iOS 9.

This same underlying issue can be shown in many different ways, as detailed in "Steps to Reproduce". The overall issues make iOS feel less responsive and natural.

Steps to Reproduce:
On iPad:
1. Pinch to home screen with five fingers.
2. Before animation ends, try to swipe to the next page.

On iPhone:
1. Turn on "Reduce Motion"
2. Open and close an app. Before the fade effect is completely over, tap to launch another app.

Expected Results:
On iPad:
The input is not blocked, and the user can swipe to the next page, as in iOS 7 and iOS 8.

On iPhone:
The app fades open once the fade to home screen is over.

Actual Results:
On iPad:
The input is ignored. The user is locked onto the current page, and has to swipe again after the animation ends.

On iPhone:
The input is ignored. The user have to tap again after the animation is over.

Version:
iOS 9.3 Beta 4 (13E5214d)

Notes:
The overall blocking of input during animations make iOS feel less responsive and natural.

The issue used to be present in iOS 7.0, but resolved in iOS 7.1. The issue returns in iOS 9.

Configuration:
Any iOS 9 devices

Attachments:
None