[garretruh]

They claim on their Kickstarter that they can get around this:

The Apple Review process restrictions are very specific. Apple forbids the dynamic loading of remote code. But this is not what Air-Control does, our library contains all the code it needs so no code is loaded dynamically. Our library only downloads content and configurations, which is permitted by Apple.

For a very similar use case we can reference our existing tool, nativeCSS, which is a dynamic styling library for iOS and Android. This is very similar to what Air-Control does, it downloads styles and applies them to a running app. This has been installed in a wide range of Apps, and has been approved by Apple since its launch in December 2012.

Whether or not Apple actually goes for this is another question entirely.

[rst]

The App Store review guidelines present a large number of specific rules, but before that, they say right up front that "This is a living document, and new Apps ... may result in new rules at any time. Perhaps your App will trigger this." In other words, they reserve the right to reject any App at any time for any reason that strikes their fancy; the guidelines are just a list of reasons they've used in the past, presented for ready reference.

(And while the text of their license agreements is covered by NDA, versions that have leaked in the past have been even more explicit about Apple's right to kick apps and developers out of the app store at any time, for any reason.)

So, a library designed for the specific purpose of doing an end-run around the review process does not sound like a good bet.

[ssharp]

This sounds like a semantic argument that Apple could easily reject.

[carlosdp]

"configurations" can be used to change code behavior, which is what the rule is designed to prevent. My money is on Apple rejecting this.

[coldcode]

Trying end arounds with Apple is doomed to failure.