Private API usage in SlackTextViewController
dzenbot opened this issue · 6 comments
Summary:
SlackTextViewController is no longer using private APIs. We highly recommend updating your app to use version 1.9, to be in compliance with the App Store Review Guidelines and, therefore, avoid App Store rejections.
Some Context:
In the SlackTextViewController library, we were internally checking for 3 private class names. We recently removed the private APIs listed below:
UIInputSetHostViewUIVariableDelayLoupeGesture_UITextSelectionForceGesture
In one instance, we were accessing the keyboard's view to be able to drag the keyboard. In the other two instances, we were detecting the text selection loupe so that the behaviour of the auto-completion feature was more consistent with user expectations.
Keyboard Panning
In iOS 9, the keyboard was moved to its own view hierarchy. We were looking up its view so we could move the text input whenever the keyboard frame changed. With the removal of the API access, users will no longer be able to move the keyboard with a panning gesture. This feature will still work in iOS 7 and iOS8, if keyboardPanningEnabled is enabled.
NOTE: We are working on an alternative, to allow dragging the keyboard on iOS 9. Any contribution is very welcomed! 💪
Magnifying Glass Detection
When a user activates the loupe by long pressing on the text content area and moves the cursor into a range of text that triggers auto-completion, the loupe would disappear and cause some UI issues. With the removal of the API access, users may experience some of these issues again.
We have filed a radar with Apple about these issues and requested some features to help third-party developers to better interact with the keyboard.
NOTE: Apple as flagged this radar as duplicate of 9261950.
We highly recommend updating your app to use version 1.9 in order to avoid an App Store rejection. We sincerely apologize for the inconvenience and are working on putting together better processes to make sure this doesn't happen again. We'd love to hear any feedback you might have.
Why not just use UIScrollViewKeyboardDismissMode and UIKeyboardWillChangeFrameNotification? I don't understand why the controller has such complex keyboard handling.
We initially used a combination of APIs like UIScrollViewKeyboardDismissMode, a custom inputAccessoryView and KVO for observing it's superview's frame/center, but the transition felt kind of jarring and it was always possible to see a gap between the text input bar and the keyboard when dragging up/down quickly. Until #215 was pull requested, introducing a new technique by effectively moving the keyboard's view along the way to guarantee a smoother transition.
UIKeyboardWillChangeFrameNotification is unfortunately not enough. This notification isn't fired every time the keyboard's origin changes by result of an interactive dismissal, making it useless since we need to layout the text input bar as soon as there is a change on the keyboard's origin.
I really did appreciate the polish which these methods gave the text view and keyboard handling. I don't think it was appropriate to open-source the project without any documentation which called out private API usage: it's something which should be clearly disclosed, so potential users of the project can make a fully-informed decision about using this code.
@cbowns agree, we should have done that at least. We will be more careful from now on. Thank you for your feedback 👊
@dzenbot Can we go back to UIScrollViewKeyboardDismissMode at this point? I think the jarring animation only appears in the simulator right? I've never seen the gaps on my phone. (And we clearly can't find any better solution for iOS10 at least)
That could be a solution, but will require somewhat medium/large refactor. Anyone up to the challenge?