General: DevForums subtopic: App & System Services > Core OS Core OS is a catch-all subtopic for low-level APIs that don’t fall into one of these more specific areas: Processes & Concurrency Resources Files and Storage Resources Networking Resources Network Extension Resources Security Resources Virtualization Resources Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

I read this thread https://developer.apple.com/forums/thread/788979 thoroughly, but I’m still confused regarding indexing files content. I'm building a notes app where the notes are stored in files. A file can contain several notes (think paragraphs). Each note and the file document itself have a unique ID, all embedded in the file. So far so good, when the user opens a file in the app, I index all the notes in it using several CSSearchableItem, one for each note. Each CSSearchableItem gets a unique ID based on the note and file IDs. The notes are then visible in Spotlight search and when the user taps one of them, the app is called with a Spotlight activity and I present the note. I learned that I should create a CSImportExtension to allow the system to index files when app is not running. But the only method is update(_:forFileAt:), which allows to provide back to the system a single attributes set. How can I index the notes in a file as separate items? What happens if an iCloud document file is edited remotely and the app is not running, or is editing another file? Does the system detect it and run CSImportExtension on the file? All the notes and documents IDs are unique, and when the user duplicates the document file from within the app, new unique IDs are set in the duplicate file. But the user can also duplicate files outside the app, in which case the IDs remain the same in the duplicate file. How does Spotlight react to indexing two distinct items, with the same ID, but different 'contentURL'? What if I index a note from a file, and set the current contentURL of the file, and then the user moves the file. Next time when I index a note from this file, Spotlight will get an item with the same uniqueIdentifier but with a different contentURL. Won't this confuse the system? How to handle the case of deleted files: Unless a file is pending editing, the app doesn’t know it has been deleted, so it won’t remove the corresponding items from Spotlight. I should mention that I use a Core Data database, which stores the mapping from file document IDs to file URLs, actually to bookmarks, so I can track the files even if the user renames or moves them.

I just saw another post regarding bookmarks on iOS where an Apple engineer made the following statement: [quote='855165022, DTS Engineer, /thread/797469?answerId=855165022#855165022'] macOS is better at enforcing the "right" behavior, so code that works there will generally work on iOS. [/quote] So I went back to my macOS code to double-check. Sure enough, the following statement: let bookmark = try url.bookmarkData(options: .withSecurityScope) fails 100% of the time. I had seen earlier statements from other DTS Engineers recommending that any use of a URL be bracketed by start/stopAccessingSecurityScopedResource. And that makes a lot of sense. If "start" returns true, then call stop. But if start returns false, then it isn't needed, so don't call stop. No harm, no foul. But what's confusing is this other, directly-related API where a security-scoped bookmark cannot be created under any circumstances because of the URL itself, some specific way the URL was initially created, and/or manipulated? So, what I'm asking is if someone could elaborate on what would cause a failure to create a security-scoped bookmark? What kinds of URLs are valid for creation of security-scoped bookmarks? Are there operations on a URL that will then cause a failure to create a security-scoped bookmark? Is it allowed to pass the URL and/or bookmark back and forth between Objective-C and Swift? I'm developing a new macOS app for release in the Mac App Store. I'm initially getting my URL from an NSOpenPanel. Then I store it in a SQLite database. I may access the URL again, after a restart, or after a year. I have a login item that also needs to read the database and access the URL. I have additional complications as well, but they don't really matter. Before I get to any of that, I get a whole volume URL from an NSOpen panel in Swift, then, almost immediately, attempt to create a security-scoped bookmark. I cannot. I've tried many different combinations of options and flows of operation, but obviously not all. I think this started happening with macOS 26, but that doesn't really matter. If this is new behaviour in macOS 26, then I must live with it. My particular use requires a URL to a whole volume. Because of this, I don't actually seem to need a security-scoped bookmark at all. So I think I might simply get lucky for now. But this still bothers me. I don't really like being lucky. I'd rather be right. I have other apps in development where this could be a bigger problem. It seems like I will need completely separate URL handling logic based on the type of URL the user selects. And what of document-scoped URLs? This experience seems to strongly indicate that security-scoped URLs should only ever be document-scoped. I think in some of my debugging efforts I tried document-scoped URLs. They didn't fix the problem, but they seemed to make the entire process more straightforward and transparent. Can a single metadata-hosting file host multiple security-scoped bookmarks? Or should I have a separate one for each bookmark? But the essence of my question is that this is supposed to be simple operation that, in certain cases, is a guaranteed failure. There are a mind-bogglingly large number of potential options and logic flows. Does there exist a set of options and logic flows for which the user can select a URL, any URL, with the explicit intent to persist it, and that my app can save, share with helper apps, and have it all work normally after restart?

It's quite common for app bundles to be distributed in .zip files, and to be stored on-disk as filesystem-compressed files. However, having them both appears to be an edge case that's broken for at least two major releases! (FB19048357, FB19329524) I'd expect a simple ditto -x -k appbundle.zip ~/Applications (-x: extract, -k: work on a zip file) to work. Instead it spits out countless errors and leaves 0 Byte files in the aftermath 😭 Please fix.

I need to detect the triggering of an auto-mount operation when accessing the path to a formerly unknown mount point at the file system (BSD, POSIX, NSURL) level, and how to wait for it to finish the operation. Network shares can have sub-volumes on them Consider a Windows server. Let's say there's a SMB sharepoint at C:\Shared. It has some folders, one of which is at C:\Shared\More. Furthermore, there's another partition (volume) on the PC, which is mounted at C:\Shared\More\OtherVol. If you mount the initial share on a Mac with a recent macOS, macOS initially only sees a single mount point at /Volumes/Shared, which can be checked with the "mount" command. Now, if you use Finder to dive into the Shared/More folder, Finder will trigger an auto-mount action on the containing OtherVol folder, and after that, the "mount" command will list two mount points from this server, the second being at /Volumes/Shared/More/OtherVol. (This was a bit surprising to me - I'd have thought that Windows or SMB would hide the fact that the share has sub-volumes, and simply show them as directories - and that's what it did in older macOS versions indeed, e.g. in High Sierra. But in Sequoia, these sub-volumes on the Windows side are mirrored on the Mac side, and they behave accordingly) Browse the volume, including its sub-volumes Now, I have a program that tries to dive into all the folders of this Shared volume, even if it was just freshly mounted and there's no mountpoint at /Volumes/Shared/More/OtherVol known yet (i.e. the user didn't use Finder to explore it). This means, that if my program, e.g. using a simple recursive directory scan, reaches /Volumes/Shared/More/OtherVol, the item will not appear as a volume but as an empty folder. E.g, if I get the NSURLIsVolumeKey value, it'll be false. Only once I try to enter the empty dir, listing its contents, which will return no items, an auto-mount action will get triggered, which will add the mountpoint at the path. So, in order to browse the actual contents of the OtherVol directory, I'd have to detect this auto-mount operation somehow, wait for it to finish mounting, and then re-enter the same directory so that I now see the mounted content. How do I do that? I.e. how do I tell that a dir is actually a auto-mount point and how do I wait for it to get auto-mounted before I continue to browse its contents? Note that newer macOS versions do not use fstab any more, so that's of no help here. Can the DA API help? Do I need to use the old Disk Arbitration functions for this, somehow? I have used the DA framework in the part to prevent auto-mounting, so I imagine I could hook into that handler, and if I get a callback for a mount operation, I could then queue the newly mounted volume for scanning. The problem, however, is that my scanning code may, having only seen an empty directory at the not-yet-mounted mountpoint, already decided that there's nothing there and finished its operation. I'd need some reliable method that lets my recursive scanning code know whether an auto-mount has been triggered and it therefore needs to wait for the DA callback. So, is there some signal that will let me know IMMEDIATELY after entering the empty mountpoint directory that an auto-mount op is on the way? Because I suspect that the DA callbacks come with a delay, and therefore would come too late if I used that as the notifier that I have to wait.

In the context of a FPUIActionExtensionViewController module the prepare method is defined like this: override func prepare(forAction actionIdentifier: String, itemIdentifiers: [NSFileProviderItemIdentifier]) { So you would expect the itemIdentifiers list to be the item identifier but instead it is a list of the internal fileprovider IDs like: __fp/fs/docID(6595461) So this is a bit problematic because the only way to recover the ID is by using getUserVisibleURL to get the path which is not great. Is there a better way ? Am I missing something ? Thanks,

I have a working XIB App to run a Linux VM with graphics interface. I am trying to rewrite it in SwiftUI but fall into all sorts of problems when using a combination of a Representable of the VZVirtualMachineView, an associated Coordinator, and @StateObjects. a) The VM display is not updated when running but is displayed if I close the window and reopen it. As the underlying VZVirtualMachineView is created/dismantled many times, there are warnings about negative scanouts that end up crashing the App b) Keyboard focus is not really working. https://developer.apple.com/forums/thread/766014 reports that there is probably a solution making a NSViewControllerReporesentable rather than a VZVirtualMachineViewRepresentable. I think I am fighting against proper SwiftUI lifecycle and would love to have a hint at what shall be the right organization of model and SwiftUI constructs.

I regularly receive emails from my customers asking why my app, which copies files from a source folder to a destination folder, gives an error during the copy operation, usually when some kind of NAS is involved. I then ask if copying the same file works in the Finder and they usually say yes. Then it’s up to me to contact the NAS vendor and ask why their NAS doesn’t work correctly with the copyfile function which my app uses to copy files, and provide them with a sample Xcode project that reproduces the issue. It would be so much easier for me, and probably other developers as well, if my customers could test their NAS with the Finder, then if it doesn’t work, contact their NAS vendor and solve the issue, or if it works, rest assured that file copies will work for any other app that uses the same API as the Finder. I could spend my time doing much more productive and interesting work rather than checking why every other NAS doesn’t work with my app which, after all, uses the most basic file copy mechanism available on macOS. Is there any chance that in the future (hopefully sooner than later) there will be an API to copy files like the Finder with progress information, or is there a reason why this won't ever be possible? I created FB20929181.

iPhone7 : iOS 14.0 Beta 5 Xcode-beta Mac OS : 10.15.5 (19F101) crash info : ** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[PHPhotoLibrary presentLimitedLibraryPickerFromViewController:]: unrecognized selector sent to instance xxxxxx' terminating with uncaught exception of type NSException my code: (void)viewDidAppear:(BOOL)animated {   [super viewDidAppear:animated];   if (@available(iOS 14, *)) {     [[PHPhotoLibrary sharedPhotoLibrary] presentLimitedLibraryPickerFromViewController:self];   } }

macOS 14.8.2 is released (xnu-10063.141.1.707.11~1), no KDK for it either, or any other 14.8.x (14.8, 14.8.1, 14.8.2) macOS. Last KDK for macOS 14.x was released in July, for 14.7.7. Is there any explanation from Apple why?

Hello, I am currently researching for ways to get the versions of all of the Mach-O executables and dylibs installed on my MacOS machine. Based on my initial research, I am able to get the information of installed applications from commands like "lsappinfo" and "system_profiler SPApplicationsDataType". However, the above commands only give me information about applications installed in my machine, not all the Mach-O binaries and dylibs. I also saw otool -L output is not very reliable as some dylibs don't show the current version. Are there any alternate commands I can try to get this information? Can this be achievable through any frameworks on MacOS? Any pointers will help me a lot.

Hello, I would like to change the system timezone in macOS, given a timezone identifier in the IANA timezone database. is 'systemsetup -settimezone' the only available tool or API that can be used to change the timezone? I have observed that TimeZone(identifier:) can initialize a TimeZone from any identifier in the tz database, but many identifiers are missing from the list accepted by systemsetup. For example, if the user has set the timezone to "Mumbai - India" in system settings, the timezone identifier returned by 'systemsetup -gettimezone' is Asia/Kolkata, which is not in the list printed by 'systemsetup -listtimezones'. What is the recommended way to map a IANA timezone name (or a TimeZone object) to one of the timezone names accepted by 'systemsetup'?

Since macOS 26.1, creating bookmark data based on a NSOpenPanel URL, does not return the expected bookmark data when the selected source concerns a Windows NTFS fileshare. When the returned data is being resolved, the returned URL points to the local drive of the current Mac. Which is of course super confusing for the user. This issue did not occur in macOS 26.0 and older. In essence, the following code line with 'url' based on an URL from a NSOpenPanel after selecting the root of a Windows NTFS share, creates an incorrect bookmark in macOS 26.1: let bookmark = try url.bookmarkData(options: .withSecurityScope, includingResourceValuesForKeys: nil, relativeTo: nil) I have tested this on two different Macs with macOS 26.1 with two different Windows PC both hosting NTFS files shares via SMB. My questions: Have anyone else encountered this issue in macOS 26? Perhaps even with other fileshare types? Is there a workaround or some new project configuration needed in Xcode to get this working?

This script from man hdiutil no longer works: devnode=$(hdiutil attach -nomount ram://102400) newfs_hfs “$devnode” mount -t hfs “$devnode” /path/to/ramdisk because $devnode contains spaces and tabs!! $ hdiutil attach -nomount ram://1 | xxd 00000000: 2f64 6576 2f64 6973 6b34 2020 2020 2020 /dev/disk4 00000010: 2020 2020 0920 2020 2020 2020 2020 2020 . 00000020: 2020 2020 2020 2020 2020 2020 2020 2020 00000030: 2020 2020 090a # remember to clean up afterwards $ hdiutil detach /dev/disk4 Please properly quote your variables in CI test scripts to catch such regression. It could pass because unquoted expansion of $devnode undergoes word splitting after the variable is substituted, removing the trailing whitespaces. FB20303191

Hi, We can easily get drive throughput using the iostat command, but it only outputs plain text that needs to be parsed, and I’m not sure if the format or column order is consistent across macOS versions. Is there any API that provides the same disk I/O metrics that iostat reports, but in a way that can be safely called from a notarized app?

I'm developing an App that works with BLE connection based devices. The BLE connection process, which connects well to the iPhone 16 without any problems, has not worked at all since the iPhone 17. Even when using the same iOS26 version, iPhone 17 is the only one having problems. Progress is stuck after frame 124 in the entire snoop below. Please check if it is a known problem or if there is a solution. 123 2025-11-04 02:01:39.262000 0.000000 localhost () 7c:c6:b6:91:10:04 () ATT 12 Sent Exchange MTU Response, Server Rx MTU: 232 124 2025-11-04 02:01:39.265000 0.003000 localhost () 7c:c6:b6:91:10:04 () ATT 16 Sent Read By Group Type Request, GATT Primary Service Declaration, Handles: 0x0001..0xffff

I am using a Raspberry Pi 5 (BLE 5.0) to read sensor data and send it via D-Bus and BlueZ to a Flutter application (flutter_blue_plus) for both iOS and Android. The goal is to display these real-time sensor updates directly on the device. On Android, the data transmission is immediate and the real-time visualization is extremely smooth and fast. However, on iOS, both BLE write and notification commands appear with noticeable latency—not only in real-time displays, but also when comparing ordinary notification feedback between the Raspberry Pi terminal and the iOS app. It seems that iOS buffers several BLE packets internally and then dispatches them in batches, which always introduces an additional delay. Additional setup details: I sample and transmit data every 25ms, sending binary packets of 20 bytes (length shouldn’t be a limiting factor). On the iOS side I am using an iPhone 15 Pro with iOS 18.6.2 (BLE 5.3). The Raspberry Pi (using btmon for logging) confirms after connection setup that the connection interval is fixed at 30ms (and cannot be changed). I have tried sending BLE packets every 30ms so that exactly one packet arrives per interval, but this made no difference—the latency and batch delivery remain. Interestingly, faster transmission rates (e.g. sending every 10ms) make the real-time display look smoother on iOS, but the guaranteed overall system latency does not improve. Also these methods used: write-without-response, using app in release modus (no debugging) Is there anyone familiar with this problem or a potential solution? Or is iOS simply not optimized for true real-time BLE data streaming and visualization? Any pointers, technical insights or workarounds would be greatly appreciated.

iPhone12 ， iOS26 NFCTagReaderSession cannot read NFCTagTypeISO7816Compatible anymore

My process running with root privilege, but got below error with API SecStaticCodeCreateWithPath(::_:) to create static code object for Cortex XDR Agent app, it working fine for other app like Safari on same device. 2025-07-22 02:02:05.857719(-0600)[23221:520725] DBG Found /Library/Application Support/PaloAltoNetworks/Traps/bin/Cortex XDR Agent.app,/Library/Application Support/PaloAltoNetworks/Traps/bin/Cortex XDR Agent.app running. Will verify the process now 2025-07-22 02:02:05.859209(-0600)[23221:520725] ERR Failed to create static code for path /Library/Application Support/PaloAltoNetworks/Traps/bin/Cortex XDR Agent.app/Contents/MacOS/Cortex XDR Agent. Error: Optional(UNIX[Operation not permitted]) Code Snippet let fileURL = URL(fileURLWithPath: processPath) var code: SecStaticCode? let rc = SecStaticCodeCreateWithPath(fileURL as CFURL, [], &code) if rc == errSecSuccess, let code = code { staticCode = code } else { ZSLoggerError("Failed to create static code for path \(processPath). Error: \(String(describing: SecCopyErrorMessageString(rc, nil)))") return nil }

Modern versions of macOS use a file system permission model that’s far more complex than the traditional BSD rwx model, and this post is my attempt at explaining that model. If you have a question about this, post it here on DevForums. Put your thread in the App & System Services > Core OS topic area and tag it with Files and Storage. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" On File System Permissions Modern versions of macOS have five different file system permission mechanisms: Traditional BSD permissions Access control lists (ACLs) App Sandbox Mandatory access control (MAC) Endpoint Security (ES) The first two were introduced a long time ago and rarely trip folks up. The second two are newer, more complex, and specific to macOS, and thus are the source of some confusion. Finally, Endpoint Security allows third-party developers to deny file system operations based on their own criteria. This post offers explanations and advice about all of these mechanisms. Error Codes App Sandbox and the mandatory access control system are both implemented using macOS’s sandboxing infrastructure. When a file system operation fails, check the error to see whether it was blocked by this sandboxing infrastructure. If an operation was blocked by BSD permissions or ACLs, it fails with EACCES (Permission denied, 13). If it was blocked by something else, it’ll fail with EPERM (Operation not permitted, 1). If you’re using Foundation’s FileManager, these error are both reported as Foundation errors, for example, the NSFileReadNoPermissionError error. To recover the underlying error, get the NSUnderlyingErrorKey property from the info dictionary. App Sandbox File system access within the App Sandbox is controlled by two factors. The first is the entitlements on the main executable. There are three relevant groups of entitlements: The com.apple.security.app-sandbox entitlement enables the App Sandbox. This denies access to all file system locations except those on a built-in allowlist (things like /System) or within the app’s containers. The various “standard location” entitlements extend the sandbox to include their corresponding locations. The various “file access temporary exceptions” entitlements extend the sandbox to include the items listed in the entitlement. Collectively this is known as your static sandbox. The second factor is dynamic sandbox extensions. The system issues these extensions to your sandbox based on user behaviour. For example, if the user selects a file in the open panel, the system issues a sandbox extension to your process so that it can access that file. The type of extension is determined by the main executable’s entitlements: com.apple.security.files.user-selected.read-only results in an extension that grants read-only access. com.apple.security.files.user-selected.read-write results in an extension that grants read/write access. Note There’s currently no way to get a dynamic sandbox extension that grants executable access. For all the gory details, see this post. These dynamic sandbox extensions are tied to your process; they go away when your process terminates. To maintain persistent access to an item, use a security-scoped bookmark. See Accessing files from the macOS App Sandbox. To pass access between processes, use an implicit security scoped bookmark, that is, a bookmark that was created without an explicit security scope (no .withSecurityScope flag) and without disabling the implicit security scope (no .withoutImplicitSecurityScope flag)). If you have access to a directory — regardless of whether that’s via an entitlement or a dynamic sandbox extension — then, in general, you have access to all items in the hierarchy rooted at that directory. This does not overrule the MAC protection discussed below. For example, if the user grants you access to ~/Library, that does not give you access to ~/Library/Mail because the latter is protected by MAC. Finally, the discussion above is focused on a new sandbox, the thing you get when you launch a sandboxed app from the Finder. If a sandboxed process starts a child process, that child process inherits its sandbox from its parent. For information on what happens in that case, see the Note box in Enabling App Sandbox Inheritance. IMPORTANT The child process inherits its parent process’s sandbox regardless of whether it has the com.apple.security.inherit entitlement. That entitlement exists primarily to act as a marker for App Review. App Review requires that all main executables have the com.apple.security.app-sandbox entitlement, and that entitlements starts a new sandbox by default. Thus, any helper tool inside your app needs the com.apple.security.inherit entitlement to trigger inheritance. However, if you’re not shipping on the Mac App Store you can leave off both of these entitlement and the helper process will inherit its parent’s sandbox just fine. The same applies if you run a built-in executable, like /bin/sh, as a child process. When the App Sandbox blocks something, it might generates a sandbox violation report. For information on how to view these reports, see Discovering and diagnosing App Sandbox violations. To learn more about the App Sandbox, see the various links in App Sandbox Resources. For information about how to embed a helper tool in a sandboxed app, see Embedding a Command-Line Tool in a Sandboxed App. Mandatory Access Control Mandatory access control (MAC) has been a feature of macOS for many releases, but it’s become a lot more prominent since macOS 10.14. There are many flavours of MAC but the ones you’re most likely to encounter are: Full Disk Access (macOS 10.14 and later) Files and Folders (macOS 10.15 and later) App bundle protection (macOS 13 and later) App container protection (macOS 14 and later) App group container protection (macOS 15 and later) Data Vaults (see below) and other internal techniques used by various macOS subsystems Mandatory access control, as the name suggests, is mandatory; it’s not an opt-in like the App Sandbox. Rather, all processes on the system, including those running as root, as subject to MAC. Data Vaults are not a third-party developer opportunity. See this post if you’re curious. In the Full Disk Access and Files and Folders cases, users grant a program a MAC privilege using System Settings > Privacy & Security. Some MAC privileges are per user (Files and Folders) and some are system wide (Full Disk Access). If you’re not sure, run this simple test: On a Mac with two users, log in as user A and enable the MAC privilege for a program. Now log in as user B. Does the program have the privilege? If a process tries to access an item restricted by MAC, the system may prompt the user to grant it access there and then. For example, if an app tries to access the desktop, you’ll see an alert like this: “AAA” would like to access files in your Desktop folder. [Don’t Allow] [OK] To customise this message, set Files and Folders properties in your Info.plist. This system only displays this alert once. It remembers the user’s initial choice and returns the same result thereafter. This relies on your code having a stable code signing identity. If your code is unsigned, or signed ad hoc (Signed to Run Locally in Xcode parlance), the system can’t tell that version N+1 of your code is the same as version N, and thus you’ll encounter excessive prompts. Note For information about how that works, see TN3127 Inside Code Signing: Requirements. The Files and Folders prompts only show up if the process is running in a GUI login session. If not, the operation is allowed or denied based on existing information. If there’s no existing information, the operation is denied by default. For more information about app and app group container protection, see the links in Trusted Execution Resources. For more information about app groups in general, see App Groups: macOS vs iOS: Working Towards Harmony On managed systems the site admin can use the com.apple.TCC.configuration-profile-policy payload to assign MAC privileges. For testing purposes you can reset parts of TCC using the tccutil command-line tool. For general information about that tool, see its man page. For a list of TCC service names, see the posts on this thread. Note TCC stands for transparency, consent, and control. It’s the subsystem within macOS that manages most of the privileges visible in System Settings > Privacy & Security. TCC has no API surface, but you see its name in various places, including the above-mentioned configuration profile payload and command-line tool, and the name of its accompanying daemon, tccd. While tccutil is an easy way to do basic TCC testing, the most reliable way to test TCC is in a VM, restoring to a fresh snapshot between each test. If you want to try this out, crib ideas from Testing a Notarised Product. The MAC privilege mechanism is heavily dependent on the concept of responsible code. For example, if an app contains a helper tool and the helper tool triggers a MAC prompt, we want: The app’s name and usage description to appear in the alert. The user’s decision to be recorded for the whole app, not that specific helper tool. That decision to show up in System Settings under the app’s name. For this to work the system must be able to tell that the app is the responsible code for the helper tool. The system has various heuristics to determine this and it works reasonably well in most cases. However, it’s possible to break this link. I haven’t fully research this but my experience is that this most often breaks when the child process does something ‘odd’ to break the link, such as trying to daemonise itself. If you’re building a launchd daemon or agent and you find that it’s not correctly attributed to your app, add the AssociatedBundleIdentifiers property to your launchd property list. See the launchd.plist man page for the details. Scripting MAC presents some serious challenges for scripting because scripts are run by interpreters and the system can’t distinguish file system operations done by the interpreter from those done by the script. For example, if you have a script that needs to manipulate files on your desktop, you wouldn’t want to give the interpreter that privilege because then any script could do that. The easiest solution to this problem is to package your script as a standalone program that MAC can use for its tracking. This may be easy or hard depending on the specific scripting environment. For example, AppleScript makes it easy to export a script as a signed app, but that’s not true for shell scripts. TCC and Main Executables TCC expects its bundled clients — apps, app extensions, and so on — to use a native main executable. That is, it expects the CFBundleExecutable property to be the name of a Mach-O executable. If your product uses a script as its main executable, you’re likely to encounter TCC problems. To resolve these, switch to using a Mach-O executable. For an example of how you might do that, see this post. Endpoint Security Endpoint Security (ES) is a general mechanism for third-party products to enforce custom security policies on the Mac. An ES client asks ES to send it events when specific security-relevant operations occur. These events can be notifications or authorisations. In the case of authorisation events, the ES client must either allow or deny the operation. As you might imagine, the set of security-relevant operations includes file system operations. For example, when you open a file using the open system call, ES delivers the ES_EVENT_TYPE_AUTH_OPEN event to any interested ES clients. If one of those ES client denies the operation, the open system call fails with EPERM. For more information about ES, see the Endpoint Security framework documentation. Revision History 2025-11-04 Added a discussion of Endpoint Security. Made numerous minor editorial changes. 2024-11-08 Added info about app group container protection. Clarified that Data Vaults are just one example of the techniques used internally by macOS. Made other editorial changes. 2023-06-13 Replaced two obsolete links with links to shiny new official documentation: Accessing files from the macOS App Sandbox and Discovering and diagnosing App Sandbox violations. Added a short discussion of app container protection and a link to WWDC 2023 Session 10053 What’s new in privacy. 2023-04-07 Added a link to my post about executable permissions. Fixed a broken link. 2023-02-10 In TCC and Main Executables, added a link to my native trampoline code. Introduced the concept of an implicit security scoped bookmark. Introduced AssociatedBundleIdentifiers. Made other minor editorial changes. 2022-04-26 Added an explanation of the TCC initialism. Added a link to Viewing Sandbox Violation Reports.  Added the TCC and Main Executables section. Made significant editorial changes. 2022-01-10 Added a discussion of the file system hierarchy. 2021-04-26 First posted.

I’d like to propose that Apple consider introducing a controlled entitlement for the SIM Application Toolkit (STK) on iOS, allowing limited developer access through a secure, user-consented API layer. While I understand the historical restrictions around SIM access for privacy and carrier security, there are legitimate, high-impact use-cases in emerging markets where STK remains a critical part of everyday digital transactions. Currently, developers have no sanctioned way to trigger or interact with STK flows — which leaves millions of iPhone users unable to complete basic offline payment or authentication actions that their Android counterparts can. The Problem In regions such as Sub-Saharan Africa, South Asia, and Southeast Asia, entire financial ecosystems still depend on SIM-based STK interactions (commonly through USSD or encrypted STK sessions). On iOS: The “SIM Applications” menu is buried under Settings → Cellular → SIM Applications, often missing depending on carrier provisioning. Third-party developers cannot programmatically open or trigger STK actions. This results in incomplete or inconsistent payment experiences for iOS users — even when the same SIM card supports rich offline capabilities on Android devices. Proposed Solution Introduce a “SIMToolkitAccess” entitlement, gated behind the following controls: User Consent Prompt When first triggered, the system displays a native dialog: “App ‘X’ would like to initiate a SIM Toolkit action (e.g., payment or balance check). Do you allow this?” The user can approve once, always, or deny. Scoped Access Model Allow only STK command initiation (e.g., “Launch STK Menu,” “Send STK Request”) Prohibit background execution or passive SIM data reading. Require entitlement approval from Apple Developer Relations, similar to CarPlay, CallKit, or HealthKit. Secure Sandbox STK sessions run in a system-managed sandbox with zero data exposure to the calling app. The app simply receives a completion callback with a generic status code (e.g., .completed, .cancelled, .timeout). Key Use-Cases That Would Benefit Offline Mobile Payments (M-PESA, Airtel Money, T-Kash) Many users rely on STK-based menus for sending or receiving money, paying bills, and topping up accounts. → Enabling secure triggers from native apps would unify the payment UX between Android and iOS, increasing inclusivity. SIM-based Authentication / OTP Requests Telecoms and banks in these regions use STK channels for encrypted session-level identity verification. → Allowing STK initiation would enable secure, offline identity confirmation flows. Carrier Value-Added Services (Data Bundles, Utility Payments) Network operators still deliver bundles, electricity token purchases, and airtime loans via STK sessions. → Secure developer access would allow modern iOS apps to wrap these flows in more intuitive interfaces while maintaining carrier security. Offline Resilience / Disaster-Recovery Flows During power or data outages, STK is often the only operational payment method, as it runs directly on the GSM layer. → Allowing iOS apps to gracefully degrade to STK ensures users can still transact safely without internet access. Why It Matters This is not about exposing low-level carrier interfaces — it’s about giving developers the ability to deliver consistent, accessible, and inclusive financial experiences to iPhone users in markets where connectivity cannot be assumed. Apple’s leadership in privacy and safety would make it the perfect platform to define the secure standard for modernized STK integration — something Android’s open access model lacks. A gated entitlement model would preserve integrity while unlocking transformative use-cases for millions.