3 ms·

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 t

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!

dopernicus 11y ago
Just wanted to add - since we don't expect there to be a public API for this, even if we do find a solution that doesn't get auto-rejected, we'll be much more up front about our use of private APIs so people are aware of the risks of something like this happening at some point.
dheera 11y ago
Why does this affect you but not affect Meteor and Phonegap, both of which also use a hybrid approach?
- morbidhawk 11y ago
  Nobody else wants to do what they are doing. They are removing a native control that's built into the keyboard (above it actually), probably to put in their own custom one I'm guessing. While apps are getting rejected because of accessing a private API to remove it, I think an even better reason to reject these apps is because users expect to have the native keyboard accessory be part of the keyboard control.
- dopernicus 11y ago
  Just to clarify, this is not an Ionic-specific issue: It's a Cordova plugin maintained by Ionic, so it will affect all apps using the plugin, including Meteor-Cordova and PhoneGap apps. The fix is the same for everyone: update the plugin! It's installed by default on all Ionic apps, so it's safe to say a majority of Ionic apps will be affected by it.
Benjammer 11y ago
Could you do something like this? 1. Add a text input as another view outside the UIWebView 2. Translate the frame of the input off screen so it's not visible 3. Wire up the input with the webview to mirror focus with the webview text input (maybe a combination of UIWebView executing JS, and the web content passing redirects back to the webview delegate that get interrupted by webView:shouldStartLoadWithRequest:navigationType:) 4. Pass the text input back into the webview from the text view delegate method textView:shouldChangeTextInRange:replacementText:
- dopernicus 11y ago
  This is something we haven't explored enough yet, but would be awesome to get working since it would allow us to support all UITextInputTraits and get rid of the accessory bar. We had a simple PoC, but I seem to recall there being some weird edge cases. Definitely worth looking into more though!

dopernicus 11y ago

Just wanted to add - since we don't expect there to be a public API for this, even if we do find a solution that doesn't get auto-rejected, we'll be much more up front about our use of private APIs so people are aware of the risks of something like this happening at some point.

dheera 11y ago

Why does this affect you but not affect Meteor and Phonegap, both of which also use a hybrid approach?

morbidhawk 11y ago
Nobody else wants to do what they are doing. They are removing a native control that's built into the keyboard (above it actually), probably to put in their own custom one I'm guessing. While apps are getting rejected because of accessing a private API to remove it, I think an even better reason to reject these apps is because users expect to have the native keyboard accessory be part of the keyboard control.
dopernicus 11y ago
Just to clarify, this is not an Ionic-specific issue: It's a Cordova plugin maintained by Ionic, so it will affect all apps using the plugin, including Meteor-Cordova and PhoneGap apps. The fix is the same for everyone: update the plugin! It's installed by default on all Ionic apps, so it's safe to say a majority of Ionic apps will be affected by it.

Benjammer 11y ago

Could you do something like this? 1. Add a text input as another view outside the UIWebView 2. Translate the frame of the input off screen so it's not visible 3. Wire up the input with the webview to mirror focus with the webview text input (maybe a combination of UIWebView executing JS, and the web content passing redirects back to the webview delegate that get interrupted by webView:shouldStartLoadWithRequest:navigationType:) 4. Pass the text input back into the webview from the text view delegate method textView:shouldChangeTextInRange:replacementText:

dopernicus 11y ago
This is something we haven't explored enough yet, but would be awesome to get working since it would allow us to support all UITextInputTraits and get rid of the accessory bar. We had a simple PoC, but I seem to recall there being some weird edge cases. Definitely worth looking into more though!