Apple starts rejecting apps that use UIWebBrowserView
Just to be clear, UIWebBrowserView is a private class, not the public UIWebView people should use, so it's not like Apple started rejecting random apps for no good reasons...
Hey all, author of the plugin for Ionic here. What a way to start a Friday morning!
So this was apparently a ticking time bomb, since we were directly using the name "UIWebBrowserView" to override that method at runtime, which is trivially found by Apple.
For anyone asking, "Why not use public APIs?", the answer is: because there are none for removing the keyboard accessory bar in a web view. At least not when the plugin was written, and as far as I know, that is still the case.
For hybrid apps, removing the keyboard accessory bar to look like native is fairly common practice. At the time the code was "written" (I'll use that term loosely), I didn't know much about Objective C and went with what worked. And it has worked, for the past couple of years, until today.
For the time being, I've removed the private API use until we find a solution that doesn't get automatically rejected (by not using the name of a private API directly, for example).
Thanks to everyone who brought this to our attention, and sorry for the headache!
Using private APIs in a plugin that other people embed into their apps, and not warning them in advance, strikes me as a reckless thing to do.
In case anyone is wondering, this plugin hides the "accessibility bar," i.e. the keyboard bar that appears when you tap on a form element in iOS: https://nolanwlawson.files.wordpress.com/2016/03/accessibili...
The accessibility bar is really annoying for hybrid app developers, because it's often not needed, and just takes up valuable screen real estate. As one of my coworkers put it, it has no purpose other than to announce, "Hi! I'm a WebView!"
Note that it's not starting to, quickly googling it shows they were rejecting applications back in October 2015 on that ground: https://forums.developer.apple.com/thread/22110
The difference may be in the way it's accessed, and that apple added new detectors which trigger on ionic's access pattern.
Actually, it rejects apps that use some private methods of UIWebView. Unfortunately this is done in one of the 'main' Ionic plugins and was fine until now and was used in thousands of apps...
Third party developers should conform their code to Apple's public API's, plain and simple. Hacking around in Apple's private APIs is just begging for a crash or an incompatibility when Apple changes something under the hood.
One thing I've never understood about situations like this: why doesn't the platform manufacturer just make it technically impossible to call private classes/methods without some kind of signed key? White list the OS classes/methods that all apps are generally allowed to call, and require some kind of signed key to call anything else.
Why try to fix this with policy rather than some technical block? I am sure I am missing something here, so any insight is greatly appreciated.
Title should probably include information that "UIWebBrowserView" is a private API and not UIWebView.
Another day, another misleading title.
AFAIK there is another way to do this using categories that has not been banned yet.
There are ways to get around this technically where Apple couldn't detect what you're doing, but definitely not recommend. I wonder if these rejections are a nod to Apple doing something with the underlying Web Browser View? Apple may be trying to prevent what would potentially become crashes by changing that private API. Start the heads up no so by the time Sept comes around with iOS 10, they can remove / refactor that class.
Apple is trying to make it more difficult to link to private API in Xcode 7.3 but objc doesn't help https://github.com/kif-framework/KIF/issues/770
Why is this enforced by a policy rather than code? Why aren't "private APIs" even accessible for third party apps?
(I guess what I'm asking: why hasn't a security mechanism been built in the language/linker/OS for this purpose?)
Will this affect React Native?
Good riddance. If your "app" fits entirely in an UIWebBrowserView, it should be a website.