It's because the input field will always appear at window level above the level of key window. So, if you need to show overlay in key window, the input field will appear above the overlay. Example for such overlay could be a loading indicator.
hi Aaron, I did briefly look at SlackTextViewController. But decided not to use it because the project contains many features that we do not need. Furthermore, it doesn't support usage on iPad.
There's no mention in the article that since iOS 7, there's been a "UIScrollViewKeyboardDismissMode", which allows "interactive" dismissal. It isn't perfect, but the last time I investigated, too many solutions out there involved touching private APIs.
In 2015, most apps shouldn't support anything below iOS 7.
Create a constraint that attaches the input field to the bottom of the scrollview.
One tradeoff is that dismissal doesn't start until your touch enters the real keyboard area. I'll take it, since it's safer than using KVO to observe private APIs.
You're observing the superview in a hierarchy you don't own. In your code, you have an iOS version check, presumably since the property you're looking for changed between iOS versions.
This is such a great writeup, thank you for digging into it. Have you tried this out with iOS 9? I know JSQMessagesVC, which does a really solid interactive dismissal, has some problems with that.