Find new way to hide default keyboard toolbar

[cjwirth]

The relatively common technique of hiding UIWebView's input accessory view that we are using in CJWWebView+HackishAccessoryHiding.m is most definitely a horrible piece of code. Not only that but recently it has been getting apps rejected from the app store which is an outcome nobody wants.

Look into seeing if there is a better way to hide and/or cover up the input accessory view. Maybe this means upgrading to WKWebView, I don't really know.

This is a bad, brittle, dangerous piece of code, and I would really like to get it out of the codebase.

[mfrawley]

@cjwirth I was wondering about this too, this could be a blocker for our imminent release as we may get rejected because of it. Have you considered whether an "align toolbar top to UIWebView bottom" NSAutolayout constraint and bringSubviewsToFront could work?

[mfrawley]

@cjwirth Working on a solution ;)

[mfrawley]

@cjwirth So I tried a bunch of solutions and failed with everything including bringSubviewsToFront etc..I don't have an easy answer

[cjwirth]

Yep, that's why I settled with this solution in the first place -- I couldn't find anything else, and it seemed to be a pretty common technique online.

I'm not too concerned with being able to overwrite the inputAccessoryView, I just want to be able to remove it.

It might work to just reference @"UIWeb" instead of @"UIWebBrowserView", but that's less than ideal. Or just looping through views. I've got a bad feeling that getting at that view one way or another will be the only way to do it though.

[undefined-zola]

we have used @"UIWeb" instead of @"UIWebBrowserView"， also been rejected...

[cjwirth]

Aaah... thanks for the update.

I was afraid something like that would happen 😣
They sure are looking closely...

[huang5556019]

any new update?

[cjwirth]

Not yet. I don't know of any solution other than maybe just switching it to @"UIWeb", @"Browser", @"View" but apparently that can get rejected too...

I'm following ionic-team/ionic-plugin-keyboard#179 to see what happens, and I'll probably do what they end up doing.

[huang5556019]

i find a solution on https://news.ycombinator.com/item?id=11310683
i used in my apps and submit to apple store ,now in review two days,maybe this is a solution :
use UAObfuscatedString to generates UIWebBrowserView and UIWebBrowserViewMinusAccessoryView string at runtime

static NSString browserViewClassName = Obfuscate.U.I.W.e.b.B.r.o.w.s.e.r.V.i.e.w;
static NSString browserViewMinusAccessoryViewClassName = Obfuscate.U.I.W.e.b.B.r.o.w.s.e.r.V.i.e.w.M.i.n.u.s.A.c.c.e.s.s.o.r.y.V.i.e.w;
//
may get around Apple's checks. i am not sure

update:also been rejected...

[cjwirth]

I'm at WWDC right now, and I went to the labs to ask the Apple engineers about this. It doesn't seem like a very widely-known problem, because I ended up talking to 3 different engineers, and nobody knew about it.

I got the impression that there is really no reason that you can't hide or customize the toolbar other than "we never thought of that use case." However, I did report the radar number I filed to two of them, and so maybe, just maybe, they'll give us public access to the input accessory view (at least in WKWebView -- UIWebView is pretty much deprecated at this point... so I'll have to make that update as well)

In the end, the Apple engineers couldn't come up with a viable workaround either. But they have nothing to do with App Review, so they couldn't comment about anything there.

[cjwirth]

I think I'm just going to change it to use the "Web" + "Browser" + "View" technique for the time being. Hopefully my talking with the engineers at WWDC has prompted them to add some flexibility to this.

As for right now, I'm going to close the issue, because there's not a whole lot I can do right now. But just because I'm closing it doesn't mean I'm forgetting about it!

[vaibhavsingla1996]

After dividing UIWebBrowserView in parts while iterating in subviews, resolved the issue and prevented it from getting rejected....?