21 ms·
Apple starts rejecting apps that use UIWebBrowserView
- pearjuice 11y agoGood riddance. If your "app" fits entirely in an UIWebBrowserView, it should be a website.
- Etheryte 11y agoDid you even read the link?
- Etheryte 11y agoAnother day, another misleading title.
- LeoNatan25 11y agoTitle is accurate. People don't know what a UIWebBrowserView is, it's their problem. Hint: It's completely different than UIWebView.
- Etheryte 11y agoAccurate but misleading, I never said the title was inaccurate.
- LeoNatan25 11y agoI cannot see how it is misleading by being accurate. People just need to read the article, then do some research (like a simple Google search).
- marknutter 11y agoIt's misleading because most people will read it as Apple rejecting hybrid apps like those that use Cordova, which is completely false. In fact, in this very thread someone commented "Good riddance. If your "app" fits entirely in an UIWebBrowserView, it should be a website." Seeing as how a good portion of HN users don't bother clicking through to the actual articles, this title can definitely be categorized as misleading. I myself initially thought it meant Apple was starting to reject hybrid apps, but only upon reading the comments did I realize what the title actually meant.
- galistoca 11y agoit's not accurate. Apple did not "start" rejecting. They've been rejecting all apps that use private APIs, including UIWebBrowserView. The title should be "Apps built with Ionic are rejected for using UIWebBrowserView"
- st3v3r 11y agoNo, it's kinda misleading. Saying that everyone should be intimately familiar with your chosen platform is pretty arrogant.
- LeoNatan25 11y agoI am not arrogant. For example, I am not familiar with Android intricacies; I would not jump to sensationalist conclusions just from a title without read the article, first and foremost, then doing some basic research. How arrogant is it to expect this of fellow tech people?
- st3v3r 11y agoIn this thread you've been nothing but arrogant. Claiming that everyone should know the intimate details of your platform, and then to google it when they might not even be aware that they don't know, is quite arrogant. Fix the title.
- leoh 11y agoAFAIK there is another way to do this using categories that has not been banned yet.
- Sephiroth87 11y agoWell, you CAN doesn't mean you SHOULD :)
- johansch 11y agoWhy 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?)
- userbinator 11y agoDo we really need more "security mechanisms" just because people might find something they could do which you didn't expect, but is actually useful for them and allows them to do what they want? A bit of a philosophical point, but I don't think it's a good thing at all if everything anyone ever did required explicit approval from some entity. Then again, I don't get the culture of strict conformance around iOS (and Apple in general) either...
- masklinn 11y ago> Then again, I don't get the culture of strict conformance around iOS (and Apple in general) either… Really? You don't get why apple would want to avoid software unexpectedly breaking on every OS update (on user devices, to widespread cries of "Apple broke software X") because the dev used an undocumented and unsupported private API which was modified or removed entirely?
- jessaustin 11y agoThe current situation is one in which things are breaking, right? Why do they want things to break now rather than in some hypothetical future?
- masklinn 11y ago> The current situation is one in which things are breaking, right? No, the situation posted about is one where developers get their application rejected, nothing is broken. > Why do they want things to break now rather than in some hypothetical future? 1. breakage in private APIs is absolutely not hypothetical 2. rejecting submission is a very different (and much milder) issue than applications breaking on end-user systems
- Sujan 11y agoTitle should probably include information that "UIWebBrowserView" is a private API and not UIWebView.
- LeoNatan25 11y agoOr, people should read the article. It's as simple as that.
- Sujan 11y agoNot really. Most users won't read all the finer points in the linked forum thread and comments here and will so remember the wrong, incorrect or incomplete information from the title and maybe make decisions influenced by that in the future.
- runholm 11y agoIt's been a while since I did anything iOS related. I didn't remember exactly what the class was named, and clarifying this in the title would have been helpful. It's not a question of how well I read.
- Grishnakh 11y agoRead the article?? I'm still pretty new to HN, but on other forums like this, that suggestion is outright heresy.
- Sephiroth87 11y agoJust 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...
- Sujan 11y agoThanks for the info. Is your obj-c good enough to explain what Ionic is actually doing in the file that triggers the problem? https://github.com/driftyco/ionic-plugin-keyboard/blob/master/src/ios/UIWebViewExtension.m https://github.com/driftyco/ionic-plugin-keyboard/blob/maste... Are they really doing it in a 'bad' way?
- Sephiroth87 11y agoThey are accessing an internal subview of UIWebView to hide the inputAccessoryView from the keyboard. When you use a normal view that uses the keyboard (UITextView, etc.), you can set it to any custom view you want, but because UIWebView is supposed to be used to display websites and not full apps, that property is not accessible, so they access the internal hierarchy of the webView, find the actual view that triggers the keyboard and modify it's property.
- masklinn 11y ago> They are accessing an internal subview An internal undocumented subview which is part of a private framework, aka they're digging into UIWebView's private implementation details[0] in order to do whatever they want to. Which may or may not be possible without that, but sadly that's besides the point. It's interesting to see that below the now-offending bits are even hackier bits which are currently commented "until [they] know it's app store safe" [0] which can't be formally private due to the architecture of Cocoa and objective-c I guess
- Sujan 11y agoThanks for the explanatin to you both! So removing this code would mean that all Ionic apps would display this thing here on all keyboards: https://raw.githubusercontent.com/clrung/PrevNextInputAccessoryView/master/README%20images/nativePrevNext.png https://raw.githubusercontent.com/clrung/PrevNextInputAccess... Did I get this right?
- Sujan 11y agoActually, 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...
- masklinn 11y agoNote 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 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.
- duaneb 11y agoI suspect that just a simple search for the class name would be sufficient for 99% of existing cases.
- TazeTSchnitzel 11y agoUsing 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.
- LeoNatan25 11y agoWorst of all, not even attempt to hide it. It is very easy to hide such trivial uses of "private" API.
- masklinn 11y agoI'd say attempting to hide it would be way worse, it would have been better if they'd clearly noted they're making use of private APIs which could break at any moment in the readme/documentation, but at least you can see it's dodgy by just going through the code.
- LeoNatan25 11y agoThe way I see it, there are two types of private API use - malign and benign. Malign would be attempting to circumvent iOS security, such as attempting to access disallowed services, attempting to retrieve personal information, abuse, etc. Bening would be use for overcoming Apple bugs or shortcomings in public API. If for the latter, as here, it is not that bad in my book.
- masklinn 11y agoMotivation is irrelevant to my comment. If you're using private APIs in a library, any user of the library is at risk of submission rejection because of the library, the least you can do for them is let them make an at least somewhat informed choice about it, and ideally (if your library is multi-purpose) have them opt in the behaviour requiring private API access. It's not a question of purpose or of "badness", and really has nothing to do with your book.
- 11y ago
- afoxtron 11y agoThird 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.
- techdragon 11y agoFor developers not actually writing code that does this but rely on the developers of tools like Cordova/Ionic.., are they expected to learn the language the apple code is written in in order to do that? At some point the burden falls to the abstraction author for the mistake, and the abstraction user chalks one up in "well I couldn't have foreseen that happening"
- c1sc0 11y agoI'd say the take-away message here is: yes, learn a little about the environment you are working with & my guess the take-away is rather going to be "Next time I'll void abstraction layer X".
- sopooneo 11y agoOne 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.
- schrodinger 11y agoI'm sure that'd be preferable, there's just no easy way to do that with objective-c, because of how dynamic it is. You can pass any message (call any function by name) on any object. Changing that would be a really significant effort.
- Benjammer 11y agoYeah it's kind of impossible when you basically have full control of the method dispatch system at runtime.
- asveikau 11y agoThat seems like a paranoid waste of engineering resources. Keep in mind Apple likely needs to access these components in the same address space as an app, and this fool's errand will only make everybody's work more annoying. Also keep in mind that 99% of internal methods and objects will never lead to a harmful "misuse", and you can't predict ahead of time which one will be a real problem.
- kybernetyk 11y ago>That seems like a paranoid waste of engineering resources. And if someone _really_ wanted to get around it they could by simply bypassing the "key checking" trampoline and jumping directly to where the wanted to end up in the first place. (Obj-C is still C).
- Benjammer 11y ago
- masters3d 11y agoApple 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 https://github.com/kif-framework/KIF/issues/770
- Sephiroth87 11y agoIt wouldn't have done much in this case anyway, since that's just removing the ability to link private frameworks, while this is a private class of UIKit which is public...
- joeblau 11y agoThere 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.
- dopernicus 11y agoHey 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 agoJust 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 agoWhy does this affect you but not affect Meteor and Phonegap, both of which also use a hybrid approach?
- morbidhawk 11y agoNobody 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
- _Codemonkeyism 11y agoWill this affect React Native?
- jeanregisser 11y agoNo, React Native is not using any private API. Also it's not using web views for rendering.
- _Codemonkeyism 11y agoThanks!
- Sephiroth87 11y agoReact Native, as the name suggests, runs Native apps, it doesn't use a webview
- _Codemonkeyism 11y agoThanks!
- nolanl 11y agoIn 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/accessibility_bar.png 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!"
- blkhp19 11y agoWell, that's what happens when you don't write native apps.
- minikites 11y agoI'm having trouble thinking of cases when it isn't needed, do you have a simple example?
- nolanl 11y agoLet's say you have one big contenteditable, so there's only one field, and it's pointless to have "previous," "next", and "done" buttons. Or just any situation where you don't think the user needs to be able to switch left and right and can tap instead. Or situations where you want to make your own UI instead of using the default Safari UI.
- minikites 11y agoBut the "Done" button would hide the keyboard so you can see more of the text to review it, right? It just seems user-hostile to remove system features that otherwise always appear.