3 ms·
Ask HN: Why is UIWebView in iPhone SDK a second class citizen?
I tried my hand at development for the iPhone the year before last, but all of ideas blurred the line between native and web applications. However, this proved to be impossible on the iPhone as the UIWebView isn't even close to being Safari. Now I hear the new OS upgrade doesn't offer access to the new optimized JavaScript engine. I know Apple wants to control various aspects for overall better user experience, but it seems that the only options are to fork WebKit or otherwise be someone with the money to be able to negotiate with Apple. Does anyone know of practical, exact reasons why this may be, or is Apple really trying to weed out the lone developer with ideas that are alternatives to the Apple way?
- nerd_in_rage 16y agowhat were you trying to do? I've found the UIWebView to be pretty decent and have worked on some hybrid native/web apps. I have native code calling into JS code that runs in UIWebView, and JS code calling back into Obj-C, etc.
- th0ma5 16y agoOh don't get me wrong, it does I guess what it promises, but lets take for example scrolling. The built in Safari has great physics reactions and overall nice and speedy. The UIWebView is very flakey on scrolling (this was I guess version 3 something when I was messing with it). In general, the rendering I found to be rather different at subtle CSS settings. The same page in Safari would act one way, whereas UIWebView would render it differently. Now lets talk same origin policy. Android and iPhone both honor this as they should, but at the time I was developing, iPhone even enacted this for XML calls. If you did an XML call on the Obj-C side, from a remote server, it would not let you mix that data with your local served web page resources. Now the biggest thing is this point some of dev friends are making that there's a new performant javascript interpreter, but it is hands off to the developer. Another avenue I tried was to access iframes, from a foreign server, with javascript, ala greasemonkey ... no go there. The origin policy is enforced because the page running your javascript is locally hosted. I love the origin policy for general web use, but if I'm designing a browser more or less, it shouldn't apply. I would also think this is safe because UIWebView seems to support having its own history, cookies, etc, so it isn't like I'm trying to sniff what else the user might be doing elsewhere. So far in my android dev experience this all just works, and I'm even given a WebKit class to work with.