Overrides accessibilityScrollToVisible

[chunhtai]

fixes flutter/flutter#61624

Observed behavior is that this method is called when an item is swipe-to-focusd in VoiceOver.

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide and the C++, Objective-C, Java style guides.
• I listed at least one issue that this PR fixes in the description above.
• I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test-exempt. See testing the engine for instructions on writing and running engine tests.
• I updated/added relevant documentation (doc comments with ///).
• I signed the CLA.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[chinmaygarde]

I don't think we can rely on private APIs for fixes. That may cause us to run into trouble with App Store policies. Is there no other way to do this?

cc @stuartmorgan (who I'm told I should forward to in @jmagman s absence).

[chunhtai]

I am attempting to test with apple store submission to see if we will run into any trouble or not.

[stuartmorgan]

I don't think we can rely on private APIs for fixes.

That's true, but the description in the PR and the method comments is incorrect; methods that we are defining on our own objects, without any special prefixing, by definition cannot be private API. I don't see any private API usage in this PR.

[stuartmorgan]

I am attempting to test with apple store submission to see if we will run into any trouble or not.

This is largely irrelevant for a framework, because "currently passes submission" is not at all the same thing is "follows app store policy" and "will continue to work, rather than suddenly preventing every single person who uses Flutter from submitting their app".

If this were calling private API and didn't happen to be picked up by the current app store checks, I would still veto landing it for that reason. But this isn't using any private API AFAICT, so the only issue I see here is the incorrect description in the code.

[stuartmorgan]

methods that we are defining on our own objects, without any special prefixing, by definition cannot be private API. I don't see any private API usage in this PR.

These two methods are likely defined in UIKit source code but are not exposed through UIKit's public header.

I understand what the code is doing. I'm saying that there is a very important distinction between how you are describing this code and what is actually happening. This PR is just defining API on our own objects, with perfectly reasonable names.

It happens that if we define such API, UIKit will apparently call it, which is convenient for us. But that's UIKit's doing, not ours.

There are more obscure way to overriding this API to possibly avoid detection

We would not want to attempt to hide use of private APIs; we just wouldn't use them.

but the fact still stand that we are using private APIs

That's definitely not a fact. We're benefiting from UIKit calling an API on our own object, which does not involve us using any APIs. We should change the description accordingly, to say something like "Observed behavior is that this method is called when an item is swipe-to-focusd in VoiceOver."

[chunhtai]

I see the distinction now, and I agree with your point. I will update this pr

[vashworth]

LGTM