There are very few conditions under which you'll be able to launch another application and have the desired outcome. com.apple.security.temporary-exception.files.absolute-path.read-write doesn't gain you anything with regard to LaunchServices so you can remove that entitlement.
As a sandboxed application you are fairly limited in what you can actually sub-launch, this is an intentional behavior as launching another application is technically a violation of the sandbox model. the ways available to you are:
- include an XPC Service in your application and have launchd launch it for you
- you can run an application via NSTask, which will cause this application to inherit your sandbox when launched
- you can launch an application by name, though from what i've seen this generally only works if the application is in your /Applications folder, i.e. -[NSWorkspace launchApplication:]
- you can launch an application that encloses your app, but only if you've been SMLoginItemSetEnabled()
I'd say the osascript call works because its doing roughly the same as -[NSWorkspace launchApplication:]. none of the LS calls that accept bundle identifiers or absolute/relative paths are going to work.
|
Thanks! Succeeded to launch from XPC Services! –
noridon
Dec 28 '12 at 2:17
| ||
|
that should work as long as you're not intending to submit to the MacAppStore and aren't sandboxing the XPC Service. If you are submitting to the app store they're going to force you to sandbox the XPC Service. –
rudy
Dec 29 '12 at 0:41
|