current I am using some applescripts to the commands in mac machine.is apple allow applescripts in reviewing process or I have to look on alternatives but applescripts is working fine as for my requiremnts
Yes. Apple allows AppleScript in the Mac OS app development. You just need to add sandboxing in side your project and list all the app for you are using in AppleScript inside your apps entitlements file.
If you not added any entitlements then it will not allowed by apple. Try your app in sandboxing mode and you can see AppleScript not working because of no entitlements added for app.
Note : Some of the app not allowed to access using AppleScript. You app will be rejected by apple review team
To use AppleScript:
ON App sandbox in project.
Add all entitlements required for AppleScript access.
(Only If you wish to deploy through Mac App Store)
Few things before starting your work I suggests that you should go through this links in order to be sure that after your hard work you get want to want.
Determine Whether Your App Is Suitable for Sandboxing
Enabling App Sandbox
App Sandbox Temporary Exception Entitlements
Apple script doesn't work in Sandbox (As far as I know)
Your app should have a temporary exception (Doc mentions it)
Determine Whether Your App Is Suitable for Sandboxing
Sending Apple events to arbitrary apps With App Sandbox, you can
receive Apple events and respond to Apple events, but you cannot send
Apple events to arbitrary apps.
However, for applications that specifically provide scripting access
groups, you can send appropriate Apple events to those apps if your
app includes a scripting targets entitlement.
For other applications, by using a temporary exception entitlement,
you can enable the sending of Apple events to a list of specific apps
that you specify, as described in Entitlement Key Reference.
Finally, your app can use the subclasses of NSUserScriptTask class to
run user-provided AppleScript scripts out of a special directory,
NSApplicationScriptsDirectory (~/Library/Application
Scripts/code-signing-identifier/). Although your app can read files
within this directory, it cannot write files into this directory; the
user must manually place scripts here. For details, see the
documentation for NSUserScriptTask and WWDC 2012: Secure Automation
Techniques in OS X.
A complimentary
A Strategy for UI Scripting in AppleScript
Scripting from a Sandbox
Related
I want my Electron app could open *.txt-files (generated by my app) with system default application (default text editor).
I use shell.openItem(path) to perform it - and it worked fine... until I've packed (mas) and signed the app. I suppose I have to add some entitlements when signing, but already tried bunch of them without success :(
Could anyone give me a hand with that?
Unfortunately Electron disables the shell.openItem() API in Mac App Store builds. From their signing guide:
[shell.openItem()] will fail when the app is signed for distribution in the Mac App Store. Subscribe to #9005 for updates.
However, there is a work-around that will enable you to have the same functionality:
shell.openExternal('file://' + myFilePath);
This approach is also confirmed to pass the Apple Store Reviews (see here).
On the Apple Developer website it states:
To deliver an OS X app extension, it’s recommended that you submit
your containing app to the App Store, but it’s not required.
However, to make a Today Extension from what I understand: I must create a Cocoa OS X application then add a "Today Extension" as a target. However, I do not want/need this main containing app. All I need is the extension.
So, how do I create an extension without a containing app? Even though technically I need to develop the containing app to create an extension target.
I think you are misreading this: what they are saying is that an OS X app extension may be distributed OUTSIDE the app store - if you continue reading, you will see the following:
If you distribute an OS X app extension outside of the Mac App Store, Gatekeeper prevents the extension from running until the user opens and approves the containing app. Further, if you code sign with a certificate other than your Developer ID, users must explicitly override Gatekeeper to open the containing app to make your extension available.
All extensions, at this writing, must be part of a container app and Apple devotes a large number of pages describing how, why, etc. My understanding (and work on extensions) is that all extensions must be part of a containing application. If there is a way to do so without the container app, Apple has not indicated it.
I'm not understanding if a containing app is needed alongside a Today Extension for OSX. I have a very simple and straightforward widget, it does not need nor rely on a main or containing app. With that said, how can I create an Today Extension without a containing app.
What I have so far is that I have a blank app with a today extension.
You cannot create a today extension without having an app. They don't work that way. All iOS app extensions are just that-- extensions to an app. There must be an app, and it must do something to be accepted into the app store (Apple rejects apps for "minimal functionality"). Extensions cannot exist on iOS outside of an app bundle, until or unless Apple decides to change things in the future.
A container app is not needed. Read up the Apple documentation on it. It says:
To deliver an OS X app extension, it’s recommended that you submit your containing app to the App Store, but it’s not required.
I have create in sandbox, an app which use a helper to start at login, as presented here.
It works ok, but the next messages are logged in the console:
lsboxd[1560]: Not allowing process 15208 to launch "/Applications/SandboxApp.app/Contents/Library/LoginItems/SandboxHelper.app" because it has not been launched previously by the user
lsboxd[1560]: Not allowing process 15208 to register app "/Applications/SandboxApp.app/Contents/Library/LoginItems/SandboxHelper.app" for launch.
I see that this messages are about the helper, but I don't know what to do, to prevent them.
My only concern is that Apple may reject the app because of this messages.
Is someone who prevent the raise of those sandbox messages, or is someone who sent an app, which raise sandbox messages, to Apple and was accepted on Appstore?
See http://blog.timschroeder.net/2012/07/03/the-launch-at-login-sandbox-project/ - according to this it is a code-signing issue that probably won't be an issue with the AppStore build as the AppStore build gets resigned.
This should work in the final build. According to Apple Documentation (Section “Launching Helpers with Launch Services”):
Launching Helpers with Launch Services
A sandboxed app is allowed to
launch a helper using Launch Services if at least one of these
conditions has been met:
Both the app and helper pass the Gatekeeper assessment. By default
that means both are signed by the Mac App Store or with a Developer
ID. Note: This does not include your development ("Mac Developer") or
distribution ("3rd Party Mac Developer Application") signing
identities.
The app is installed in /Applications and the app bundle
and all contents are owned by root.
The helper has been (manually) run
at least once by the user.
The first and/or second one should cover your case when your app was installed through the Mac App Store.
I have made one sandboxed app which calls NSWorkspace's showSearchResultsForQueryString but this method doesn't work.
I guess this error can be associated with entitlement key, but i could't find answer.
How can I implement entitlement key for this?
That method won't work for a sandboxed app. It sends an Apple event to the Finder.
Have a look at this link in the sandbox design guide:
Determine Whether Your App Is Suitable for Sandboxing
and you'll see the following text:
With App Sandbox, you can receive Apple events and respond to Apple events, but you cannot send Apple events to arbitrary apps.
This method can not be used in sandboxed application.
Because this method should be fixed to run within sandboxed application in future.