6 ms·

That's not Facebook's fault its Apple's. iOS's UIWebView uses an older version of webkit and a much older version of there javascript engine. Apple doesn't want

by DonnyV 14y ago

That's not Facebook's fault its Apple's. iOS's UIWebView uses an older version of webkit and a much older version of there javascript engine. Apple doesn't want you building web apps they can't monetize.

taligent 14y ago
You know it takes talent to write a statement that is so completely wrong. Others have addressed the JS point but Apple originally wanted developers to only build web apps and it took a lot of convincing to get them to change their mind. Also Apple has a lot of free apps. So this idea that Apple is somehow obsessed with monetizing apps is simply not true.
- DonnyV 14y ago
  Not really... if you write an app that's native, then in-app purchases are controlled by Apple and they get a 30% cut of those sales. If you build an app using UIWebView then you could by pass those in-app purchases and get 100% of the sale. ref: https://developer.apple.com/appstore/in-app-purchase/index.html https://developer.apple.com/appstore/in-app-purchase/index.h...
  - taligent 14y ago
    I'm well aware that in app purchases exist. And absolutely nothing is stopping you from offering payments from a website in a UIWebView. So not really sure what your point is ?
    - cageface 14y ago
      Wrong. Quoting from earlier post in this thread: That's simply not true. 1) A year ago Apple rejected one of our app updates because a webview inside the app had a payment form. (They told us that they do not allow any other payment option other than Apple in app purchases) 2) Yesterday they rejected yet another update for our app because it had a form where users could enter bonus codes.
tnorthcutt 14y ago
So really, it's Facebook's fault for using UIWebView, vs. a true native app.
objclxt 14y ago
I don't know if you're an iOS developer, but that's plain mis-information. The reason native apps use a different flavour of WebKit to Safari is because the latter operates in a privileged security mode, whereas the former are all sandboxed. Mobile Safari uses a JIT compiler, but this introduces the possibility for remote code execution. It's not that Apple 'doesn't want you building web apps they can't monetize' - it's that JIT compilation of JavaScript doesn't sit well with the current iOS security model. People seem to easily forget that Mobile Web was originally the only way to get apps onto the iPhone. A number of Apple's own apps (the App Store, for example) are HTML based rather than ObjC based.
- DominikR 14y ago
  "It's not that Apple 'doesn't want you building web apps they can't monetize'" That's simply not true. 1) A year ago Apple rejected one of our app updates because a webview inside the app had a payment form. (They told us that they do not allow any other payment option other than Apple in app purchases) 2) Yesterday they rejected yet another update for our app because it had a form where users could enter bonus codes. Their explanation: We don't know if you are not selling those bonuscodes to your customers somewhere else on the web. (We don't, thats just bonus codes from promotion agreements with blogs/newspapers etc)
  - bsaul 14y ago
    That's insane, I just had the same 2) rejection and spent literally weeks thinking that I wasn't able to properly explain what the codes where for, because it didn't make any sense for them to reject that. But since you've had the same issue, i guess they really start to be seriously deranged.
  - estel 14y ago
    Whilst that's arguably true, UIWebView being the poor cousin of mobile Safari isn't evidence for it.
  - lazerwalker 14y ago
    Of everything that irks me about the app store (and I say this as someone who uses almost exclusively Apple computers / mobile devices), this is pretty high up there. It makes it damn near impossible to run a successful marketplace businesses on iOS: if your business is based on skimming a percentage fee off the top of your user's transactions, Apple taking 30% is more often than not a dealbreaker. That being said, that's not an issue of native apps vs. web apps. If you want your application distributed through the app store, anything payment-related (or even potentially payment-related) needs to go through Apple's payment services. Period. Apple would complain just as much if you had a native app that had your own payment form, and they'd be 100% fine if you built a pure webapp (i.e. not on the app store) that accepted non-Apple payment.
viscanti 14y ago
This seems like a silly argument. You can release a free app in the iOS app store with a UIWebView or as a native app. It seems like Apple is optimizing for safety (a sandboxed version of the web view) and encouraging app performance. I don't see any monetization strategy at the heart of this (since Apple's cut of a free app is still 0).
raganwald 14y ago
That issue is not as simple as you make it out to be. Just in time compilation of Javascript requires an app to have permission to execute code that is generated as data on the fly. Applications with this permission are vulnerable to exploits. The standard UIWebView available to applications doesn't include just-in-time compilation because 3rd party applications don't have this permission. This is the biggest reason why its Javascript engine is slower than the one built into Safari. Apple doesn't want you building apps that open up exploit vectors into iOS.
- aboodman 14y ago
  But it's OK to write web pages that do?
  - guan 14y ago
    No, but web pages (including apps that are installed to the home screen and run full screen) run inside the MobileSafari process, which is much more carefully audited than your typical iOS app.
    - MatthewPhillips 14y ago
      Can you give an example of an exploit that would do harm from within a UIWebView but would not do harm from within Mobile Safari? Not questioning you, I'm genuinely interested.
      - raganwald 14y ago
        Given the current architecture, if UIWebkitView within an application can execute data, then the entire application can execute data. So you could have a buffer overrun anywhere in the app. For example, if they are silly, you could go to the preferences for Facebook and enter a very, very, very long user name, overrun the name buffer, and have executable code. That's not an exploit of UIWebkitView, it's an exploit of giving the application the permission it needs to have UIWebkitView use a JIT compiler for JS.
    - 14y ago
rburhum 14y ago
And that is somehow a valid justification for writing an inadequate "native" app? Why would you choose to do it this way then if the platform you are targeting is 1) important and 2) doesn't have good support for whatever technology you are using?!?! This is equivalent to being hired by a bank to re-write an entire enterprise timesheet app and then I decide on using Websockets and WebGL. Of course I will blame the fact that the app doesn't work on any of the internal bank computers because "they run crappy IE8 and nobody should be running it anyway". Nevermind that 50% of the bank's computers have those constraints. Sometimes, you have to face reality and write the best application that you can considering the current constraints that you presently have.
jcromartie 14y ago
> Apple doesn't want you building web apps they can't monetize. This doesn't even make sense. You have it backwards. If you run a web app in Safari, or save it as a web app in the home screen, it's going to run full-speed. If you wrap it in a UIWebView and sell it in the App Store (hello monetization) it's going to be slower.
Flow 14y ago
If UIWebView is the cause, how come the Android Facebook app is also really slow? And to be honest, even surfing to mobile.facebook.com in Mobile Safari the app was really slow.

by DonnyV 14y ago

taligent 14y ago

You know it takes talent to write a statement that is so completely wrong. Others have addressed the JS point but Apple originally wanted developers to only build web apps and it took a lot of convincing to get them to change their mind. Also Apple has a lot of free apps. So this idea that Apple is somehow obsessed with monetizing apps is simply not true.

DonnyV 14y ago
Not really... if you write an app that's native, then in-app purchases are controlled by Apple and they get a 30% cut of those sales. If you build an app using UIWebView then you could by pass those in-app purchases and get 100% of the sale. ref: https://developer.apple.com/appstore/in-app-purchase/index.html https://developer.apple.com/appstore/in-app-purchase/index.h...
- taligent 14y ago
  I'm well aware that in app purchases exist. And absolutely nothing is stopping you from offering payments from a website in a UIWebView. So not really sure what your point is ?
  - cageface 14y ago
    Wrong. Quoting from earlier post in this thread: That's simply not true. 1) A year ago Apple rejected one of our app updates because a webview inside the app had a payment form. (They told us that they do not allow any other payment option other than Apple in app purchases) 2) Yesterday they rejected yet another update for our app because it had a form where users could enter bonus codes.

tnorthcutt 14y ago

So really, it's Facebook's fault for using UIWebView, vs. a true native app.

objclxt 14y ago

I don't know if you're an iOS developer, but that's plain mis-information. The reason native apps use a different flavour of WebKit to Safari is because the latter operates in a privileged security mode, whereas the former are all sandboxed. Mobile Safari uses a JIT compiler, but this introduces the possibility for remote code execution. It's not that Apple 'doesn't want you building web apps they can't monetize' - it's that JIT compilation of JavaScript doesn't sit well with the current iOS security model. People seem to easily forget that Mobile Web was originally the only way to get apps onto the iPhone. A number of Apple's own apps (the App Store, for example) are HTML based rather than ObjC based.

DominikR 14y ago
"It's not that Apple 'doesn't want you building web apps they can't monetize'" That's simply not true. 1) A year ago Apple rejected one of our app updates because a webview inside the app had a payment form. (They told us that they do not allow any other payment option other than Apple in app purchases) 2) Yesterday they rejected yet another update for our app because it had a form where users could enter bonus codes. Their explanation: We don't know if you are not selling those bonuscodes to your customers somewhere else on the web. (We don't, thats just bonus codes from promotion agreements with blogs/newspapers etc)
- bsaul 14y ago
  That's insane, I just had the same 2) rejection and spent literally weeks thinking that I wasn't able to properly explain what the codes where for, because it didn't make any sense for them to reject that. But since you've had the same issue, i guess they really start to be seriously deranged.
- estel 14y ago
  Whilst that's arguably true, UIWebView being the poor cousin of mobile Safari isn't evidence for it.
- lazerwalker 14y ago
  Of everything that irks me about the app store (and I say this as someone who uses almost exclusively Apple computers / mobile devices), this is pretty high up there. It makes it damn near impossible to run a successful marketplace businesses on iOS: if your business is based on skimming a percentage fee off the top of your user's transactions, Apple taking 30% is more often than not a dealbreaker. That being said, that's not an issue of native apps vs. web apps. If you want your application distributed through the app store, anything payment-related (or even potentially payment-related) needs to go through Apple's payment services. Period. Apple would complain just as much if you had a native app that had your own payment form, and they'd be 100% fine if you built a pure webapp (i.e. not on the app store) that accepted non-Apple payment.

viscanti 14y ago

This seems like a silly argument. You can release a free app in the iOS app store with a UIWebView or as a native app. It seems like Apple is optimizing for safety (a sandboxed version of the web view) and encouraging app performance. I don't see any monetization strategy at the heart of this (since Apple's cut of a free app is still 0).

raganwald 14y ago

That issue is not as simple as you make it out to be. Just in time compilation of Javascript requires an app to have permission to execute code that is generated as data on the fly. Applications with this permission are vulnerable to exploits. The standard UIWebView available to applications doesn't include just-in-time compilation because 3rd party applications don't have this permission. This is the biggest reason why its Javascript engine is slower than the one built into Safari. Apple doesn't want you building apps that open up exploit vectors into iOS.

aboodman 14y ago
But it's OK to write web pages that do?
- guan 14y ago
  No, but web pages (including apps that are installed to the home screen and run full screen) run inside the MobileSafari process, which is much more carefully audited than your typical iOS app.
  - MatthewPhillips 14y ago
    Can you give an example of an exploit that would do harm from within a UIWebView but would not do harm from within Mobile Safari? Not questioning you, I'm genuinely interested.
    - raganwald 14y ago
      Given the current architecture, if UIWebkitView within an application can execute data, then the entire application can execute data. So you could have a buffer overrun anywhere in the app. For example, if they are silly, you could go to the preferences for Facebook and enter a very, very, very long user name, overrun the name buffer, and have executable code. That's not an exploit of UIWebkitView, it's an exploit of giving the application the permission it needs to have UIWebkitView use a JIT compiler for JS.
  - 14y ago

rburhum 14y ago

And that is somehow a valid justification for writing an inadequate "native" app? Why would you choose to do it this way then if the platform you are targeting is 1) important and 2) doesn't have good support for whatever technology you are using?!?! This is equivalent to being hired by a bank to re-write an entire enterprise timesheet app and then I decide on using Websockets and WebGL. Of course I will blame the fact that the app doesn't work on any of the internal bank computers because "they run crappy IE8 and nobody should be running it anyway". Nevermind that 50% of the bank's computers have those constraints. Sometimes, you have to face reality and write the best application that you can considering the current constraints that you presently have.

jcromartie 14y ago

> Apple doesn't want you building web apps they can't monetize. This doesn't even make sense. You have it backwards. If you run a web app in Safari, or save it as a web app in the home screen, it's going to run full-speed. If you wrap it in a UIWebView and sell it in the App Store (hello monetization) it's going to be slower.

Flow 14y ago

If UIWebView is the cause, how come the Android Facebook app is also really slow? And to be honest, even surfing to mobile.facebook.com in Mobile Safari the app was really slow.