Mac App Store Bundle Downloads

Question

After reading through the extensive App Store guidelines (mac app store specifically), I've noticed a contradiction....

On one hand, under functionality, it clearly states:

2.7 Apps that download code in any way or form will be rejected
2.8 Apps that install or launch other executable code will be rejected

Yet when you read up further about purchase types, it often refers to in App Purchase 'downloads' and I'm pretty sure I remember reading in the bundle development guide (specifically plugin development) that these could be considered as in app purchases?

in 2.7 and 2.8 above, do they refer to code that they haven't checked i.e myAppPurchase.bundle which wasn't submitted at the app submission time, or is this concrete that absolutely NO bundles checked or unchecked by apple can be downloaded at all?

So in short, should an app be created in it's entirety i.e. with all the 'in app purchase extras' or can it be done modular i.e. an in app purchase downloads an approved bundle from the app store?

Cheers,

A

Answer 1

Although you can download content for in-app purchase, you aren't allowed to download code for later incorporation into the application. There are some theoretical edge cases, as you might have your own interpreter and might be able to download some amount of interpretable code in that case, you cannot download native code which will be executed either as part of the application (plugin) or an externally launched application.

As for the question of why Apple would cover this in the docs, it's likely because its the way that OS X and iOS apps are stored in the file system. Until Apple decides to allow downloadable binary executables, we're stuck using Plugin bundles in OS X only, ditto for non-OS framework bundles, which would arguably be even more useful. In particular, we have some bundles that are iOS/OSX cross-platform that we have to statically link under iOS, which is a shame.

Apple's apparent take is that if we can load code dynamically, then it is an opportunity to circumvent their review process by downloading an offending code module after the initial (or subsequent) program load. Imagine, for example, an application that talks to a server to download code which violates one of Apple's guidelines. If the version that is making the request has not yet been "released" by the malicious developer, no code is returned, and it just looks like it's checking in for an informative message of some kind. However, once Apple approves the App, the developer tells the server to start sending back a dynamic library, framework, or plugin which is then executed at the appropriate time by the now-malicious code.

The difficulty is that to prevent this from happening (through dyld or similar), you need to either whitelist everything that can be loaded, or you need to just prevent its use by application code altogether.

There's certainly the possibility that some kind of approved code whitelist could be used in the future, but until then, Apple has apparently chosen the route of just preventing the use of dynamic linking of non-system frameworks.