Open Radar

 
Background:

Our app (Delicious Library 2) provides users the ability to run scripts. Previously we ran those scripts in our app directly via NSAppleScript, but that approach is too limiting when our app runs in a sandbox. Currently the least-bad solution is to have users save their scripts as .app bundles, and run them by having our app call Launch Services (which can then do quarantine checks and whatever).

We also ship some sample scripts, which we include inside our app bundle (as .scpt). When the user turns them on, we run osacompile to app-ify them, with the .app output going into Library/Scripts/Applications/Delicious Library 2/ (inside our container). This causes the .app bundles to be quarantined (as expected / desired). Note that .app bundles saved from AppleScript Editor aren't quarantined (also reasonable, as it's an explicit user action).

So far so good. Unfortunately I hit what seem to be a few bugs in Launch Services.

Using LSOpenCFURLRef() to open the script app intermittently works. If the file was quarantined, it will sometimes log the quarantine message to the console, and return userCanceledErr.

2012-02-14 12:21:43.435 AM Delicious Library 2: You are opening the application “Create new Book.app” for the first time. Are you sure you want to open this application?:  The application is in a folder named “Delicious Library 2.” To see the application in the Finder without opening it, click Show Application.


Bug 1:

But this often happens even if the file isn't quarantined. (There is no quarantine xattr, and double-clicking in the Finder runs immediately.) Other times (quarantined or not), it returns kLSNoExecutableErr. Sometimes simply opening the folder containing the script app in the Finder, then waiting for Finder to write out to com.apple.LaunchServices-034506.csstore, allows the /next/ launch to succeed. Subsequent launches still fail with kLSNoExecutableErr, until you stare down the file again. Judicious use of LSRegisterURL() didn't seem to help.


Workaround 1:

If an app isn't quarantined, asking the Finder to open it ([[NSWorkspace sharedWorkspace] openFile:self.filePath withApplication:@"Finder"]) works as expected. Which leads to

Bug 2:

If the app /is/ quarantined, the above technique (-openFile:withApplication:) fails to launch the app, but returns YES, indicating success. The following message is logged:

2012-02-14 1:07:16.622 PM CoreServicesUIAgent: Quarantine resolution refused to pid 9228 because it is not allowed to read /Users/jonathon/Library/Containers/com.delicious-monster.library2/Data/Library/Scripts/Applications/Delicious Library 2/Sample AppleScripts/Create new Book.app


Workaround 2:

My current workaround is to explicitly check if the app is quarantined before I pass it to -openFile:withApplication:, using LSCopyItemAttribute(…, kLSItemQuarantineProperties, …). If it is quarantined, we show an alert telling the user they need to launch it first from the Finder, with the default button revealing the app. When the user double-clicks the app from the Finder, the quarantine alert is shown, and the user can proceed if she desires.

Bug 3:

When the user launches a quarantined script app from the Finder, clicking "Open" clears the quarantine, but the app fails to launch. The following is logged:

2012-02-14 1:15:09.980 PM com.apple.launchd.peruser.506: ([0x0-0xd60d6].Create new Book[9704]) posix_spawn("/Users/jonathon/Library/Containers/com.delicious-monster.library2/Data/Library/Scripts/Applications/Delicious Library 2/Sample AppleScripts/Create new Book.app/Contents/MacOS/applet", ...): Operation not permitted
2012-02-14 1:15:09.980 PM com.apple.launchd.peruser.506: ([0x0-0xd60d6].Create new Book[9704]) Exited with code: 1
2012-02-14 1:15:09.984 PM Dock: no information back from LS about running process
2012-02-14 1:15:12.132 PM CoreServicesUIAgent: Unable to continue stopped application -- error 4294966696

(Note that this third bug doesn't seem to be related to sandboxing, as I'm launching the un-sandboxed script app directly from un-sandboxed Finder.)