What is the point of UIWebView, if it's meant to help developers write Javascript "native" apps, and yet it's 3x slower than a web app would be inside Mobile Safari? Doesn't that kind of defeat the purpose of UIWebView existing?
I'm pretty sure Apple is leaving this as it is on purpose so Javascript apps don't start to compete on performance with ObjectiveC apps, and the security excuse they give is just the lazy one to get them off the hook, just like Microsoft is saying "WebGL poses security issues, so we won't even try to add it".
Well guess what. A lot of stuff poses security issues. But you have to balance that out with the features and usability you want to give to the user, and if there are some good and "logical" features you could add like setting other browsers as default, or letting UIWebView apps be as fast as web apps in Safari, then you just have to add them and make sure the security is as tight as possible. Add a sandbox if necessary and so on. Don't take the easy way out.
> What is the point of UIWebView, if it's meant to help developers write Javascript "native" apps
I'm not sure I buy the premise here. UIWebView is a class to help developers show web content in an app. That's all it was ever about.
> I'm pretty sure Apple is leaving this as it is on purpose so Javascript apps don't start to compete on performance with ObjectiveC apps
Why? Apple doesn't need to worry about this. Their platform-specific features mean that native apps will always win on user experience, regardless of performance. They don't need to hobble performance. Conspiracies sound cute to write about, and are fun to cook up, but it's much likelier that Apple just has better stuff to worry about.
They have a successful, widely-adopted solution for developers to create great apps for their platform.
They have a solution for users to have a great, fast browsing experience.
That's about all they need at the moment, in a world with finite time and resources. It's not Apple's goal to make every single nerdy desire or business model possible. It's their goal to sell a shitload of hardware by making users happy.
My mom isn't asking for super fast performance on a third party browser. She just wants her internet to work. Apple's already giving her that. QED.
> I'm not sure I buy the premise here. UIWebView is a class to help developers show web content in an app. That's all it was ever about.
I'm pretty sure it's still the case that when you add a HTML5 app to your home screen (so your users see the icon instead of a bookmark in Safari) all of a sudden it doesn't get run on the Nitro JS engine anymore.
> I'm pretty sure it's still the case that when you add a HTML5 app to your home screen (so your users see the icon instead of a bookmark in Safari) all of a sudden it doesn't get run on the Nitro JS engine anymore.
That is the reason of total control over their platform, and that's where industry is going - Microsoft is also imposing the same restrictions in Windows RT. That is quite sad, because it doesn't leave much freedom to the programmers, demoting them to just the "apps" coders, there is no place for hackers in its true meaning.
> Well guess what. A lot of stuff poses security issues. But you have to balance that out with the features and usability you want to give to the user
Just imagine if Microsoft had done the same starting with Windows 3.1. How much innovation would it have killed?
I recently tried using Adobe AIR to make something, but unlike C# the AIR API is severely sandboxed and limited that even simple things like GetDC or CreateShortcut are just near impossible to implement. End result is I never really completed my app.. something which would have taken me an hour at most to do in C#.
This new trend of technology where everything is being sandboxed and scrutinized for approval in the name of security is really very sad for hacker culture.
All we are talking about here is a loss of performance in Javascript benchmarks. In every day usage you simply don't notice a difference between Chrome and Safari.
So I think you have the volume turned to 11 on the idea of it killing innovation.
Well my reply was to the above poster wrt to Apple's inane policies in the name of security that kills innovations and and hacker culture.
For example: The most important app for me is iBlacklist for iPhone. It prevents nearly 20 spam text messages for me daily, which directly translates into less annoyance and added productivity daily. Yet, Apple will never approve this app for general public.
Same for Microsoft's on{x}, which is a genius innovation imo but because of the recent inane app store policies trend, even Microsoft had to release it for Android only.
While third-party browsers won't be able to compete with Safari on iOS due to the technical limitations, I still prefer Chrome on my iPhone because it ties in with my Google account, syncing everything for me. The loss in per-page performance is somewhat mitigated by the fact that I have to load fewer pages than before thanks to features such as Chrome to Mobile and syncing of tabs, bookmarks, and passwords.
Also, Chrome is so well designed for mobile as on my Galaxy Nexus that it is difficult to switch to any other browser. The way they handle tabs is the best I've seen. Incognito mode also offers an easy way to simulate a second browser session without switching to another browser app, something I as a web developer cannot live without.
I am also happy to take the performance hit in stride in exchange for the sync features. The "request desktop version" feature is also nicely implemented.
Can someone explain how an application developer with access to webkit+Nitro could cause problems? Would the developer have to write a malicious app, or would a maliciously crafted webpage be able to exploit the OS?
If the JIT engine in Nitro had a JIT Spray vulnerability and Nitro was a shared library could it allow an attacker to inject code into other applications that also use Nitro?
Not that shared libraries are a problem, just that JIT'ing introduces a new attack vector that is hard to secure.
iOS code signs all code that runs on the system. Compared to most other operating systems, this is a huge security win: without another exploit in that system, even a standard remote code execution vulnerability is useless. Nitro generates code at runtime, so it (by definition) needs to run unsigned code. With Safari, Apple can audit all the code necessary, but with third party apps, it would be easy for a developer to have their app exploited or even use the unsigned code ability to download new, possibly malicious code after the App Store review process.
So far, there have been two userland exploits of the iOS browser (Safari) since Apple implemented code signing in 2008, at JailbreakMe.com. Both of those required tons of extra work compared to what they would have required otherwise.
It's not a "weak argument", it's the reason why iOS is one of the most secure platforms out there, and way more secure than Android, Windows, (most) desktop Linux, and OS X. Other preventative technologies (e.g. ASLR, DEP/w^x, etc) are on those platforms, but none of them have the same kind of pervasive code signing that you see on iOS (and often video game consoles).
Code signing is the reason why iOS and game consoles are closed platforms, so only the first party controls what you can run on it. They're just protecting their profits.
It has yet to be shown that code signing helps significantly to improve security. It relies too much on the competency of those that write said signed software. Measures like sandboxing are much more effective.
> It has yet to be shown that code signing helps significantly to improve security.
Hah! I needed a good laugh today.
No, Apple has not blacklisted a developer's certificate that we know of to the extent that pre-existing apps on an arbitrary user's phone will stop working due to validation failure, but they have revoked certificates from developers that effectively prevent them from ever submitting another app to the store[1]. You're right that sandboxing is a stronger security measure in a general sense, but security isn't a black or white thing you can throw a single buzzword at and have all your problems taken care of. Code signing is an additional layer of protection for the average user so he/she doesn't download a fake AV program that grinds their device to a halt while offering to get rid of itself for the low price of $39.99. Yes, code signing also ensures that the manufacturer of the device can also get a cut of the profits of other people's hard work, but that is not it's only reason for existence and it doesn't always have to be employed as a revenue stream.
I'm not an expert at this so please correct me if I'm wrong, but if I remember correctly all I had to do to jailbreak my iphone was go to jailbreakme.com and click the button on it. That was it.
So it seems that if I can trick someone to click that button then it is possible for me to not only jailbreak their phone but also run any sort of malicious code afterwards (because instead of Cydia it can install just about anything).
Jailbreak me exploited a vulnerability in the FreeType library used while rendering PDF files. That has long been patched. While I'm sure that there are other exploits that we haven't discovered yet, a one-click jailbreak exploit hasn't happened since Jailbreakme, it it had, it would be ubiquitous. The odds are tremendously low for someone to accidentally jailbreak their phone.
I don't recall of ever hearing a story where someone accidentally jailbroke their phone, although I could be ill informed.
UIWebView runs in-process. There's no way for "part of" a process to be able to map executable pages without other parts able to, so either they let any app run whatever code it wants, disable Nitro, or rewrite large chunks of the UI to move WebKit out-of-process.
I think a Chrome engineer at I/O summed it up best, from the Campfire session for Chrome/OS:
There's raw performance, and there's usability. Both determine how fast you get your content. Where Safari wins out in performance due to restrictions on iOS, Chrome wins out in usability. The Omnibox, for example, recognizes my favorite sites after I type just a few characters. Plus, syncing.
It wouldn't surprise me to discover that Google's team did lots of their own performance tweaking and tuning to compensate for their disadvantage. I do love the responsiveness. Now their Gmail app on the other hand was painful for me to use.
Yeah I could never really tell how that even made it to the App Store. Some stupid wrapper around the web page, but the Chrome app is definitely more along the lines of what I'd expect from Google.
These tests are only JavaScript benchmarks and don't reflect real-world usage well. Chrome for iOS has a custom network stack and (like someone else said) page prefetching among other things.
The snappiness could be because iOS Chrome pre-fetches pages if you're on a wifi network. A lot of the lag of Safari on iOS seems to be in the actual fetching of pages.
Chrome is using the web view without JIT compiling for JavaScript that Safari can take advantage of. That being said, it's not something that's surprising. It's a known issue.
From what I understand, Chrome (and any non-native app) doesn't have access to the JavaScript engine that Safari does. That's why the JavaScript benchmark results are so disparate between Safari and Chrome for iOS.
I'm pretty sure Apple is leaving this as it is on purpose so Javascript apps don't start to compete on performance with ObjectiveC apps, and the security excuse they give is just the lazy one to get them off the hook, just like Microsoft is saying "WebGL poses security issues, so we won't even try to add it".
Well guess what. A lot of stuff poses security issues. But you have to balance that out with the features and usability you want to give to the user, and if there are some good and "logical" features you could add like setting other browsers as default, or letting UIWebView apps be as fast as web apps in Safari, then you just have to add them and make sure the security is as tight as possible. Add a sandbox if necessary and so on. Don't take the easy way out.