iOS 5 finally brings Nitro JavaScript speed to home screen Web apps | Hacker News Reader

iOS 5 finally brings Nitro JavaScript speed to home screen Web apps

arstechnica.com

55 pointsshawndumas28 comments

Anyone else notice that the slug in the URL doesn't contain the word "finally?" I guess the original headline wasn't snarky or sexy enough.

A while ago I read that the Huffington Post AB tests headline titles, presumably other big publishers do the same thing:

http://www.niemanlab.org/2009/10/how-the-huffington-post-use...

What's wrong with adding finally? Sure, it's light editorialization, but it succinctly adds accurate additional context that someone unfamiliar with the situation would not otherwise have.

Well, if one takes finally to mean "at long last", it would be more appropriate to use it for something that took a long time to ship, like Longhorn or a new version of IE. How long did this take?

Approximately three months.

Well, there goes the conspiracy theory that Apple was doing this to handicap web based apps.

Heh :) I've also noticed that many of these "conspiracies" are based on an expectation that A) just because Apple hasn't done something right away, they're never going to do it, and B) if Apple files a patent for something, they're absolutely going to do it.

See also: Stories regarding Apple disabling camera at concerts, etc.

have you considered that Apple files patents defensively i.e. to make sure no one makes a product which hinders the vision of their ecosystem?

What you described generally isn't considered defensive use of a patent.

I imagine all the conspiracy theorists will now go "oh, okay then", like the birthers did.

You're right. It's unheard of for companies to react to consumer outrage. Apple's never done that. They certainly didn't back pedal on their ToS for AppStore apps, they certainly didn't react to negative feedback from the irremovable tracking, they certainly didn't react to publishers and users outraged about 30% that was being, uh rightfully taken from them.

It was never a conspiracy theory. It was never people hating Apple. It was people worried that Apple would use their mite to try to crush web apps in order to lock people into their native platform.

It's really not that unreasonable to be concerned about that (see every other thing I listed and notice how they're ALL related to locking in users and developers to the iOS platform.

>You're right. It's unheard of for companies to react to consumer outrage.

A dozen nerds on a message board ranting about JS performance is nothing close to a consumer outrage. More likely Apple has a roadmap and optimizes it based on what effort will help the most users the earliest.

I'm not saying that didn't happen. I believe that it did too. I think it's absurd to dismiss everyone that had concerns about it.

Can anyone actually explain the downvotes? Did I not contribute to the discussion? Is it unfair to question Apple's motives when they make absolutely NO bones about the fact that they're heavily invest even possibly in the exclusive use, of their platform?

Oh well, apparently my defense of skepticism is either too radical for HN or caused me to be lumped in with Apple haters. Oh well, can't say I'm shocked.

Oh, you guys. You are so cute/silly. press the arrow, walk away, don't bother actually engaging in a discussion. Because calling people "conspiracy theorists" in regards to a company with a track record is completely fair. What a bunch of jokesters.

How does this mean it wasn't true that Apple was doing this to handicap web apps?

I guess it's time for me to start giving Apple the benefit of the doubt a little more often.

I haven't checked yet, but I'm hoping they've done something with multitasking and home-screen web apps; right now web apps reload from scratch every time you re-enter them, which makes for a pretty terrible user experience compared to native.

Doesn't seem like it. A web app I tried just reloaded when quitting and relaunching and it simply crashed when I used gestures to switch apps.

This is a major annoyance for me as well, especially since the Facebook app is still not available for the iPad I've been using the touch.facebook.com interface instead, but each time I switch apps it has to reload the page and destroys any state as to where I was last/what I was looking at.

I was hoping this would also apply to UIWebView in third party apps, but no suck luck. Would have been a great improvement for apps built with Sencha + PhoneGap.

They can't, however, without removing much of the security mechanisms in iOS. Excepting the possibility that they could move WebKit (and Nitro) to a separate process, allowing App Store apps to use Nitro would completely disable their (generally effective) codesigning and W^X protection.

Couldn't they sandbox Nitro processes?

All processes (at least, ones in the App Store) are already sandboxed, as are Safari and Web.app (although the latter two are sandboxed more heavily than ones from the App Store, since Apple knows exactly what things they might want to access). However, since Nitro is run in-process (as is WebKit as a whole), it can't be too sandboxed, or the app that's using it wouldn't be able to do a lot of the things that a native app can do.

It's a tradeoff between functionality and security with the sandboxes, and right now (for native third party apps) Apple has gone with functionality (address book access, camera access, etc).

Interesting, thank you.

So what would be the security implications of allowing Nitro to create code dynamically within a sandboxed process? AFAIK, only compiled code (ObjC,C,C++) can call private APIs, and the app review process guards against that; so what could a Nitro process do that compiled code couldn't?

Any (machine) code can call private APIs, so it's simply a matter of getting/hacking Nitro to generate the correct machine code to do it. I think that's what they would worry about. Remember Jailbreakme.com? It was PDF (and kernel, so no sandbox could have helped) I believe, but a real problem to consider if you can get custom code running.

the gist is that in a 3rd party compiled app, they wouldn't be able to tell if it was nitro turning data into code, or some part of your app recompiling itself. they don't like your app recompiling itself, they want updates to come through the app store ecosystem.

IMO this could have been easily done with an update, since this is based on a whitelist of processes I think.

Is there actually some difference between an update and a new version other than number of changes made at once?

I think that's what delta updates over the air will provide.

Reply on news.ycombinator.com