Well I guess the feedback I filed should be enough then: FB18581605. During a workshop with folks from Apple last month, they acknowledged the issue and contacted the framework team. But it's been a month and I amass getting worried this would not be fixed before the final release.

You're right! Thank you. I wonder if it can still be regarded as a bug, or if it is intended, in which case nor the documentation mentioned by the DTS engineer, nor the WWDC videos mention it. I'll look for a way to still watch for the UIEvent phase in the eventuality this is intended and will not change.

In case of you miss the notification, it's still crashing with your recommendation. I attached some screenshot to demonstrate that.

Thanks for the confirmation!

To change shell, if someone as lazy as I am: chsh -s /bin/bash chsh -s /bin/zsh Close window to ensure it has changed to zsh or bash.

Thus, when the documentation refers to « dictated or user-typed input », it does not mean that the view which property accessibilityUserInputLabels is set should be a control that can receive user input. It rather means that the user will search for the view/control name and that we as developers can set this property to offer alternative names to accessibilityLabel when the latter will not be the best match to the user‘s input to make it easier for the user to find the view/control.

Thank you I read the documentation, which is why I shared the link to the property in the first place. I think you have a misconception about the property accessibilityUserInputLabels. Have you watched the WWDC I referenced? This is about adding names to a view/control so that when the user uses an accessibility search as offered by Full Keyboard Access or Voice Over search, they can find the view/control and activate it. It works with plain views, system buttons and so on.

What is a user input control? You mean a text field for instance? Then I don’t think this the topic as I mention in my second comment. I watched the WWDC session Support Full Keyboard Access in your iOS app where they use this API in a custom UI to make it easier to find a preferences button. This led me to think that it should be possible to use this API on UIBarButtonItem as it’s a common place to put a preferences button.

Also @MobileTen I think that the « user input » here refers to the fact that the user enters some input to find the control, using the search with Full Keyboard Access or Voice Over. It’s what I understand from the video I mention and from the documentation: « An array of localized labels the user provides to refer to the accessibility element. »

Wrong place, sorry

Yes, I thought about that too. I also tried to play with the content size of the collection view with no luck so far. It seems that the search controller changes the layout margins of the search results view (collection view) to make the content appear on the side of the keyboard and under the search text bar. I tried to inspect that and change the layout margins but again with no results. Indeed Spotify handles that well, thanks! I did not check that one. So there is definitely a solution.