4 ms·
Didn't Apple have some rules preventing apps from downloading code from the Internet?
by ajasmin 15y ago
Didn't Apple have some rules preventing apps from downloading code from the Internet?
- objclxt 15y agoThey do, but this isn't really downloading 'code'. "Apps that download code in any way will be rejected", but you're not downloading it: you're executing JavaScript, which is totally permissible. To put it another way: this idea isn't unique, although the packaging might be - there are several frameworks that do similar things (some proprietary internal tools, similar to how this seems to have started) with live apps on the store.
- greendestiny 15y agoActually I think the rule is more like - the only scripting is javascript and it must be downloaded and executed by a UIWebkit view.
- bri3d 15y agoThey allow data to be downloaded, and they allow web content (HTML + JavaScript) to be downloaded. Hence, it's possible to use a combination of native-interfaced templating and sandboxed JavaScript (i.e. "put native button with title n here and attach it to this JS action") to make native-feeling downloaded apps. Presumably these restrictions are designed so that the only code which hasn't been through their static analysis tool is sandboxed, and they trust their JS sandbox to keep the JS where it belongs. Just like most of the Apple restrictions, it's pretty arbitrary in practice, because their "prevent private API usage" static analyzer is not very good (Camera+ was able to use restricted APIs simply by invoking a selector constructed via interpolation).
- pkghost 15y agoApple's static analyzer will catch you if you import/include private framework headers, but it can't stop you from sending messages to private framework objects that are sitting around at runtime because it's a dynamically typed language, which means it resolves method calls at runtime, and static analysis can't touch runtime[1]. http://www.youtube.com/watch?v=otCpCn0l4Wo#t=21s http://www.youtube.com/watch?v=otCpCn0l4Wo#t=21s 1. Otherwise, it would be dynamic analysis.
- bri3d 15y agoYou can easily detect most trivial methods of performing direct message sends to private framework objects via static analysis - both the name of the class and the message are used as string data. You can even find a naive message send using strings and grep, regardless of the use or non-use of a header! The use of the header is irrelevant - using [NSClassFromString(@"WebView") _enableRemoteInspector]; is going to show up the same way in a static analysis tool regardless of whether I made a WebView.h header defining +(void) enableRemoteInspector; or not - it compiles to the exact same thing! You have to be at least one level more clever to defeat Apple's static analysis tool - it looks at the values of the objc_msgSend's message only. Hence, using methodForSelector defeats it - the static analyzer sees a "methodForSelector" message (which isn't blacklisted), ignores the parameters, and then sees a straight function call (also not blacklisted).
- natesm 15y agoTwitter for Mac also does this to call private things on Snow Leopard. https://github.com/twitter/twui/blob/master/lib/UIKit/TUIScrollView.m#L989 https://github.com/twitter/twui/blob/master/lib/UIKit/TUIScr...