I understand that sandbox was introduced in Mac OS X Lion (10.7) but temporary exception entitlements, specifically com.apple.security.temporary-exception.files.home-relative-path.read-write, were introduced in a later 10.7.x update (which one?)
Similarly security scoped bookmarks were introduced in 10.7.3.
My Mac app (not currently sandboxed) is a document based app that creates documents that have references to pictures on users' mac. Once a user uses some pictures in his document we simply save the path (for eg. /Users/myname/Desktop/pic.jpg) of used picture in that document. When a user quits the app and reopens the saved document, our app can simply get access to the picture using the path from the document. Since our app is not sandboxed this works on all versions 10.6.x, 10.7.x, and 10.8.x
We would now like to sandbox our app and ensure that it continues to work on all versions (10.6.x, 10.7.x, and 10.8.x) of Mac OS X. To achieve this, we will
Ask for a temporary exception entitlement, specifically com.apple.security.temporary-exception.files.absolute-path.read-write and this will enable random file access for 10.7.3 onwards. But what do we do for 10.7, 10.7.1, and 10.7.2?
Beyond 10.7.3 we will start using security scoped bookmarks.
Related
How to add loginItem on macOS Mojave?
Solution I have found:
macOS Swift: How to properly add application as Login Item
but function called LSSharedFileListInsertItemURL is deprecated since macOS 10.11 (but still works on Mojave).
While using it, XCode gives note:
'kLSSharedFileListSessionLoginItems' is deprecated: first deprecated in macOS 10.11 - Use a LaunchAgent, XPCService or the ServiceManagement APIs instead.
Following that note, I have taken a look into ServiceManagement. And the file SMLoginItem.h defines SMLoginItemSetEnabled and documentation https://developer.apple.com/documentation/servicemanagement/1501557-smloginitemsetenabled says
Enable a helper application located in the main application bundle’s Contents/Library/LoginItems directory.
which does not apply to my case because I want to maintain LoginItems of applications which aren't located in my application bundle, for example I want to add /Applications/Books.app as LoginItem.
CFStringRef thePath = (__bridge CFStringRef)#"/Applications/Books.app";
return SMLoginItemSetEnabled(thePath, YES);
Above sniped of code returns
Could not locate login item /Applications/Books.app in the caller's bundle
Could not enable login item: /Applications/Books.app: 107: Malformed bundle
Secondly, how to remove LoginItem from system programmably?
I am not creating app for AppleStore so it isn't sandboxed (I have read kLSSharedFileListSessionLoginItems is deprecated for sandboxed apps)
I have apps both in the App Store and outside. I’m using each of the methods for adding login items depending on the distribution way. There is no other way to manage this at the moment.
SMLoginItemSetEnabled only applies to agents inside your own app bundle. For apps outside of App Store you can use LSSharedFileListInsertItemURL. It’s deprecated but there’s no adequate replacement and it’s still available in macOS 10.15 Beta SDK. Look out for further API changes next year.
Have a Sandboxed Mac App. It downloads files to a location, and I want other files to be able to edit and overwrite the files.
Currently, I'm saving to the Documents Container via my App:
let path = manager.URLsForDirectory(NSSearchPathDirectory.DocumentDirectory, inDomains: NSSearchPathDomainMask.UserDomainMask).first!
I then am modifying via Preview and saving the file.
In OSX 10.11 El Capitan, this is fine. However, on Mac OS 10.12 Sierra Beta when the User attempts to save, we get the warning: "The original document can't be changed, so a duplicate with your changes has been created."
The same problem occurs when saving to Application Support.
Of course, this does make sense in that many use cases for Sandboxed Apps is that they won't want other Apps touching their content. Though is there a shared space in which Sandboxed Apps can allow other Apps modify their contents?
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 have an OS X/iOS App that uses the old style ubiquitous container id TEAMID.com.companyname.product, and is built using NSDocument on OS X and UIDocument on iOS.
File opening has been working fine on OS X 10.8, 10.9 and 10.10 using the built in NSDocumentController openDocument: panel. In 10.10 this panel was extended by Apple to permit iCloud Drive access. At the top of the panel the selector titled “iCloud Library” shows “Appname - iCloud” and “iCloud Drive” as options.
Selecting the former gives access to documents in the App ubiquity container, and the later shows available iCloud Drive folders.
In 10.11 El Capitan, selecting “Appname - iCloud” - the view doesn’t change (you see the top level view of iCloud Drive Folders). There is no warning message. Selecting the Appname under iCloud in the sidebar has the same result.
Given the nature of the application (the data is private and isn’t designed to be read by any other application) it isn’t ideal to make the ubiquity folder public - so I would prefer not to go down that path.
A work around is to search for the appropriate file type (kind) in the request panel and select Search: This Mac - this works fine, as do saved URLs from previous opens. So App sandboxing isn’t causing the problem.
Obviously I would like the 10.10 behaviour to continue - but it isn't obvious how to achieve this or if it is a bug. It may be that Apple assume all apps built using NSDocument would wish to make their App containers public.
It does appear that this issue is a bug in OS X 10.11, and the standard NSDocument file open/save/move panel fails to be coerced into the old behaviour. However a reasonably simple solution is to provide two new application menu items:
Open iCloud listing all available documents in the (private) ubiquity container,
Move to iCloud using [NSDocument moveDocumentToUbiquityContainer:].
You need to make the apps iCloud container Public by adding the following to your info.plist file.
<key>NSUbiquitousContainers</key>
<dict>
<key>HHWT75NS6T.au.com.ossh.appName</key>
<dict>
<key>NSUbiquitousContainerIsDocumentScopePublic</key>
<true/>
<key>NSUbiquitousContainerSupportedFolderLevels</key>
<string>None</string>
</dict>
</dict>
After upgrading to Mac OS X 10.9 and running my app (which executes various AppleScripts as part of its execution) I get a dialog that the app has to be specifically enabled via the System Preferences Security/Privacy screen. So I do this and the app then functions properly.
However, when I recompile and build the app, it will no longer execute the AppleScripts and does not show the dialog. When I look in the System Preferences Security/Privacy I see that my app is still listed there but has been disabled (i.e. checkbox reset).
BY trial and error, I have found the following:
If you change the Bundle Version string in the apps info.plist and rebuild the app even without making any other changes such as code, etc this will happen; it will be disabled from accessibility.
If you make all kinds of changes to the app (code, resources, etc) but do not change the Bundle Version string in info.plist, it will still be allowed to have accessibility access.
My question is: is there a way to circumvent disabling after rebuilding?