4 ms·
Stupid and uninformed question here: Given Apple's well-known antipathy to the idea of browser engines other than WebKit and scripting languages other than Jav
by cstross 12y ago
Stupid and uninformed question here:
Given Apple's well-known antipathy to the idea of browser engines other than WebKit and scripting languages other than JavaScript on iOS (yes, yes, I know you can find Python/Lua/Lisp/whatever apps on iOS; I mean as a general rule and for inter-app automation), could this be a prelude to allowing some sort of sandboxed-app automation interface on iOS? That is, allow a JavaScript implementation running on iOS to "drive" apps via this object model?
(Genuine question here. I have no idea whether I'm blowing smoke or whether this is a plausible long-term direction for Apple to take iOS.)
- nexuist 12y agoI'm not sure if this answers your question, but you've been able to execute native javascript in your apps since iOS 7: https://developer.apple.com/library/mac/documentation/Carbon/Reference/WebKit_JavaScriptCore_Ref/_index.html https://developer.apple.com/library/mac/documentation/Carbon...
- stevejohnson 12y agoGenuine answer here. There's no need to apologize for not constantly immersing yourself in the workings of Apple platforms. :-) JavaScript is just another interface to Apple's "Open Scripting Architecture (OSA)." Previously, AppleScript was the only way to use it. The fact that they added another language indicates nothing about whether OSA will ever come to iOS. My guess is it won't; the new extensions APIs will likely handle any inter-app communication Apple wants to allow, because they are designed with iOS's sandbox model in mind already. Put another way, Javascript is to AppleScript with respect to OS X automation, as Scala is to Java on the JVM. The existence of Scala does not indicate that the JVM will be ported to the Haiku OS. (There may be a better analogy but that's what I came up with.)
- steveax 12y agoThere are other language interfaces to OSA. Frontier's UserTalk was an early implementation (and much more useful than AppleScript IMO) IIRC, there are also Python and Ruby bindings as well.
- draegtun 12y agoYes and a Perl bridge as been part of OS X for even longer time (just type man PerlObjCBridge form terminal). Additional refs: - https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man3/PerlObjCBridge.3pm.html https://developer.apple.com/library/mac/documentation/Darwin... - http://www.macosxautomation.com/applescript/features/scriptingbridge.html http://www.macosxautomation.com/applescript/features/scripti... - https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man5/BridgeSupport.5.html https://developer.apple.com/library/mac/documentation/Darwin...
- 0x0 12y agoFor developers, I think you can write ui automation tests in javascript for your own app during debugging/testing. In the general case, for published apps, I'm not seeing it happen. Apple seems to be super focused on sandboxing and separating components on iOS. Even with the new iOS8 extensions, everything needs to be user triggered and even then, extensions live on separate islands. It's doubtful they'll change that model since it would defeat the "you can't break your idevice even if you tried" feeling for end users and the app store.
- gilgoomesh 12y agoJavascript in this case has nothing to do with web browsers. It is simply a scripting language used to manipulate OSA (Apple's cross-application automation API in Mac OS X). Since OSA is not part of iOS, this likely won't affect iOS at all. You actually can use Javascript to automate iOS apps running in Instruments (one of Apple's developer tools). This is used for automated UI testing in the iOS simulator or while your iOS device is tethered to a Mac. This has been around for a couple years and there's no indication that it will ever be permitted in released applications. There's actually no reason to enable it – it's only useful for snooping on apps (good for developers, bad for users).