Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



"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)


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.


> because a webview inside the app had a payment form

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?


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.


Whilst that's arguably true, UIWebView being the poor cousin of mobile Safari isn't evidence for it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: