4 ms·

You are entering the discussion of native apps running UIWebView because (according to Gruber) that is exactly how home-screen web apps are implemented. "My on

You are entering the discussion of native apps running UIWebView because (according to Gruber) that is exactly how home-screen web apps are implemented. "My only comment is on home-screen web apps, which are 100% equivalent to opening the page on your browser." From Gruber: "Web apps that are saved to the home screen do not run within Mobile Safari. They’re effectively saved as discrete apps — thin wrappers around the UIWebView control." "I'm just telling it like it is when people make nonsensical arguments." Your failure to read and understand his arguments have made them sound nonsensical to you. This is not his fault.

tolmasky 16y ago
I initially thought you were just splitting hairs, but seeing as you've used this argument somewhere else in this thread I think this might be a genuine thought you have so I will take the time to explain why home-screen web apps are absolutely nothing like other native apps on the system, and actually essentially the same as loading a web page in MobileSafari. So for starters, let us observe that there are three instances where JS can run on iOS that we care about: 1. MobileSafari, from a web page loaded from a URL. 2. Home-Screen Web Apps, web pages loaded from a URL that the user then 'saves to the homes screen' which are loaded in some mysterious, but APPLE WRITTEN, "wrapper" process X. 3. UIWebViews within native apps that you buy on the App Store. Now, my position is that (1) and (2) are for all intents and purposes the same, and (3) is possibly different. So, the whole argument about turning it off for UIWebView is that the interaction between native code and Nitro might offer an additional vector of security concern. Well, in both (1) and (2), there is no user native code. It literally just either downloads the JS off the web, or reloads it straight from the web. All the native code is written PURELY by Apple. So in a world where the only user modifiable code comes from the web, then clearly this is the same as where we started with MobileSafari. The additional thing to realize, is that unlike native apps (3), home-screen web apps (2) are NOT code signed, just like web pages (1). So that also nullifies the argument that allowing Nitro on home-screen web apps would go against Apple's code signing policies. Hopefully that explains my thinking a little bit clearer. Once again, I am very willing to believe that they had a deadline to meet, and turning it on for home-screen web apps got punted. That makes perfect sense. The security argument however falls flat on its face.
- bandushrew 16y ago
  You seem to be missing a key point. The way Apple implemented Home-Screen Web Apps was by placing a thin wrapper around a UIWebView. Hence, Home-Screen Web Apps are not like Mobile Safari at all in actual implementation. They are, instead, exactly like an iOS application developed by a third party developer who put a thin wrapper around a UIWebView. Hence, they do not get the same special privileges as Safari Mobile. That is a fact of their implementation.
  - boucher 16y ago
    You seem to confusing facts with claims on a blog written by a third party. It's not hard to believe Web.app (the process which runs home screen apps) uses UIWebView or a close cousin, but neither you nor Gruber (or anyone on this site) has offered any evidence of that fact.
    - bandushrew 16y ago
      I find the fact that Web.app behaves exactly like every other application that uses a UIWebView to be very compelling evidence that Web.app is an application uses UIWebView. The alternative appears to be that to create Web.app they went to all the trouble of reusing the Mobile Safari code, and then methodically went through and broke things such that it behaves exactly like every other application that uses UIWebView. This would seem like an unreasonable way to get an application that behaves exactly like an application that uses UIWebView.
  - cpeterso 16y ago
    I think Tolmasky's point was that, even though Web.app embeds the same UIWebView as non-Apple native apps, Web.app was written by Apple. Apple could enable Nitro JIT for Web.app because its native code was written (and audited) by Apple. The only third-party code executed by Web.app is JavaScript that is already assumed to be safe enough to use the Nitro JIT in Mobile Safari.
    - bandushrew 16y ago

tolmasky 16y ago

I initially thought you were just splitting hairs, but seeing as you've used this argument somewhere else in this thread I think this might be a genuine thought you have so I will take the time to explain why home-screen web apps are absolutely nothing like other native apps on the system, and actually essentially the same as loading a web page in MobileSafari. So for starters, let us observe that there are three instances where JS can run on iOS that we care about: 1. MobileSafari, from a web page loaded from a URL. 2. Home-Screen Web Apps, web pages loaded from a URL that the user then 'saves to the homes screen' which are loaded in some mysterious, but APPLE WRITTEN, "wrapper" process X. 3. UIWebViews within native apps that you buy on the App Store. Now, my position is that (1) and (2) are for all intents and purposes the same, and (3) is possibly different. So, the whole argument about turning it off for UIWebView is that the interaction between native code and Nitro might offer an additional vector of security concern. Well, in both (1) and (2), there is no user native code. It literally just either downloads the JS off the web, or reloads it straight from the web. All the native code is written PURELY by Apple. So in a world where the only user modifiable code comes from the web, then clearly this is the same as where we started with MobileSafari. The additional thing to realize, is that unlike native apps (3), home-screen web apps (2) are NOT code signed, just like web pages (1). So that also nullifies the argument that allowing Nitro on home-screen web apps would go against Apple's code signing policies. Hopefully that explains my thinking a little bit clearer. Once again, I am very willing to believe that they had a deadline to meet, and turning it on for home-screen web apps got punted. That makes perfect sense. The security argument however falls flat on its face.

bandushrew 16y ago
You seem to be missing a key point. The way Apple implemented Home-Screen Web Apps was by placing a thin wrapper around a UIWebView. Hence, Home-Screen Web Apps are not like Mobile Safari at all in actual implementation. They are, instead, exactly like an iOS application developed by a third party developer who put a thin wrapper around a UIWebView. Hence, they do not get the same special privileges as Safari Mobile. That is a fact of their implementation.
- boucher 16y ago
  You seem to confusing facts with claims on a blog written by a third party. It's not hard to believe Web.app (the process which runs home screen apps) uses UIWebView or a close cousin, but neither you nor Gruber (or anyone on this site) has offered any evidence of that fact.
  - bandushrew 16y ago
    I find the fact that Web.app behaves exactly like every other application that uses a UIWebView to be very compelling evidence that Web.app is an application uses UIWebView. The alternative appears to be that to create Web.app they went to all the trouble of reusing the Mobile Safari code, and then methodically went through and broke things such that it behaves exactly like every other application that uses UIWebView. This would seem like an unreasonable way to get an application that behaves exactly like an application that uses UIWebView.
- cpeterso 16y ago
  I think Tolmasky's point was that, even though Web.app embeds the same UIWebView as non-Apple native apps, Web.app was written by Apple. Apple could enable Nitro JIT for Web.app because its native code was written (and audited) by Apple. The only third-party code executed by Web.app is JavaScript that is already assumed to be safe enough to use the Nitro JIT in Mobile Safari.
  - bandushrew 16y ago