Since mobile is their biggest growth platform and considering that they have the resources, I just don't see this as a strong argument. I always thought it was very silly that the website ran better and faster in Safari vs the "native" app.
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.
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)
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.
You didn't get rejected because it was inside a webview. You got rejected because you were selling something outside of In-App Purchases. You know this.
Why do webviews have anything to do with it?
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.
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.
Edit: I think a better hypothesis is that Apple wants to be able to analyze app code, and thus disallows executable memory, which also rules out JITs. See: http://apple.slashdot.org/comments.pl?sid=2044470&cid=35...
The propblem is that if you allow executable memory you open aup a lot of exploit vectors. Now, that's true of Mobile Safari as well, but they trust their own team more than they trust you, and they have one app to watch instead of 100,000, and if an exploit os found they can push out a fix immediately, whereas 3rd party apps have a tortuous process for pushing out bug fixes.
Remember, it's part of their value proposition that apps from the app store appear to be relatively safe in comparison to the clusterfuck that is downloading random desktop apps, especially on Windows.
Then that's what they need to do, JIT is a requirement for fast JavaScript and 2012 JS speeds cannot be the end of the line.
Pure conjecture on my part.
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.
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.
ref: https://developer.apple.com/appstore/in-app-purchase/index.h...
So not really sure what your point is ?
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.
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.