zlacker

There's a huge difference. An URL is an absolute black box, a binary that you have to give Apple for certification on each change and that has to call Apple APIs to do anything useful (like network) is not.

Apple will scan your App to check for basic violations, that's all automated. For instance is there a specific flag that you can initialize a socket with to listen in background. This is only allowed if your app is supposed to stream music in background or do some VoIP thing. So if you're app is not that and the software detects you have that flag set anywhere in the code no way you will get it through the certification. There's simply no possibility for such analysis with a URL.

>>inflag+(OP)
It sounds like you're assuming the majority of (iOS) App Store rejections deal with using unofficial/restricted APIs. My guess is that's relatively rare.

Most of the apps caught in the review process are probably those that fail other guidelines (usefulness, privacy concerns, illegal/inappropriate content, poor UX/quality, excessive crashing, etc). Most of those things can't be caught by automated means, and the content-related things can certainly be changed after initial review.

I've personally worked on several apps that significantly modify app behavior after being published - not so much to bypass any review requirements, but rather to adapt to changing business needs without waiting to publish a new release.

>>inflag+(OP)
Another interesting thing about iOS- they enforce code signing on the page level. You cannot create a RW page, write new code (from the network) into it, and then remap it as RX; every instruction needs to be approved by Apple. So changing behavior at runtime in a way that's subtle enough to pass certification is a lot harder than it would be on some hypothetical walled-garden Android (where you can, AFAIK, pull down a JNI extension over HTTP and load it.)

>>inflag+(OP)
This is kind of missing the whole point. Which is, as a developer, you can slip anything into the Apple appstore that you could have slipped into Alexa's, so the point the article is making about certification is silly. Of course there are more security implications in Apple's case, but the fact remains that numerous apps have done the bait and switch and were pulled after Apple discovered it much later.

>>inflag+(OP)
There's a big exception to the automated checking. You can download new JavaScript code any time after your app is approved, as long as your app runs the code under the built-in WebKit. I don't think there is any automated checking of what your new code does - how could there be? It's just a violation of the terms of service if you change the app into something completely different:

> 3.3.2 An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exception to the foregoing is scripts and code downloaded and run by Apple's built-in WebKit framework or JavascriptCore, provided that such scripts and code do not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store.

https://developer.apple.com/programs/ios/information/

http://info.meteor.com/blog/apple-hot-code-push-mobile