Colin Holgate <co...@verizon.net> wrote:
>>Apple do allow code that could also appear in Safari pages, HTML and >>Javascript would be ok, but no other code really. This is not quite true - you're only allowed to download HTML and JavaScript (+ CSS) and execute it within a standard UIWebView. This is why there are no genuine alternative browsers for iOS, they're limited to wrapping an alternate UI around Apple's web view implementation. I think they're going to have to give in on this one eventually or get left behind - native apps are trending towards continuous deployment and A/B testing options like the web. The boundaries are also incredibly hard to define. A recent boundary pusher is Pathmapp, which lets you A/B test native apps on the fly by creating alternate .xib files (essentially native UI layout files for those not into iOS dev) and dynamically downloading and switching them from a remote server. You could argue this is data, not code but clearly even this technical capability lets you change a live app from something Apple approved to something they would not have, since the layouts can reference new images and include controls that are connected up to code that wasn't used in the approved version. Adobe's solution has the same security hole, in that you have a whole bunch of code included that was not testable at review time. Mark _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
