Apple Watch app closes when changing photo permissions in the iPhone app. App A is installed simultaneously on both the paired iPhone and Apple Watch. I'm running App A on both my iPhone and Apple Watch. When I change the photo permissions on App A installed on my iPhone, App A running on my Apple Watch automatically closes. At first, I assumed App A on my iPhone was abnormally closing, causing App A on my Apple Watch to also close. However, I've determined that changing the photo permissions is the cause of the app closing. I don't think this behavior existed before WatchOS/iOS 26. Is this behavior a natural addition to WatchOS/iOS 26? If I go to the home screen while running app A on my iPhone and change its photo permissions in the Settings app, app A running on my Apple Watch automatically closes.

Hi Community, I'm a developer considering building a health & wellness iOS app and want to verify compliance with Apple's guidelines before investing development time. BACKGROUND: I want to create an app that helps users understand their health patterns by analyzing various data inputs including screen time and health metrics from HealthKit. PLANNED APPROACH: The app would use a hybrid ML strategy: NEW USERS: Get insights from a generalized ML model trained on anonymized data from existing users (solves cold-start problem) AFTER ~30 DAYS: Transition to personalized on-device model trained on the user's own data for better accuracy DATA HANDLING: Users grant DeviceActivity & HealthKit permissions explicitly Users select which app categories they want to include Optional opt-in to share anonymized data for improving the generalized model Transition to fully on-device analysis after sufficient data QUESTIONS: Are there specific restrictions on using DeviceActivity data and sending them to a backend for ML training ? Are there specific restrictions on using HealthKit data and sending them to a backend for ML training ? Any guidance would be greatly appreciated before I proceed! Thanks!

I am developing a daemon-based product that needs a cryptographic, non-spoofable proof of machine identity so a remote management server can grant permissions based on the physical machine. I was thinking to create a signing key in the Secure Enclave and use a certificate signed by that key as the machine identity. The problem is that the Secure Enclave key I can create is only accessible from user context, while my product runs as a system daemon and must not rely on user processes or launchAgents. Could you please advise on the recommended Apple-supported approaches for this use case ? Specifically, Is there a supported way for a system daemon to generate and use an unremovable Secure Enclave key during phases like the pre-logon, that doesn't have non user context (only the my application which created this key/certificate will have permission to use/delete it) If Secure Enclave access from a daemon is not supported, what Apple-recommended alternatives exist for providing a hardware-backed machine identity for system daemons? I'd rather avoid using system keychain, as its contents may be removed or used by root privileged users. The ideal solution would be that each Apple product, would come out with a non removable signing certificate, that represent the machine itself (lets say that the cetificate name use to represent the machine ID), and can be validated by verify that the root signer is "Apple Root CA"

It seems it is not possible to give a CLI app (non .app bundle) full disk access in macOS 26.1. This seems like a bug and if not that is a breaking change. Anybody seeing the same problem? Our application needs full disk access for a service running as a LaunchDaemon. The binary is located in a /Library subfolder.

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.

TCC Permission Inheritance for Python Process Launched by Swift App in Enterprise Deployment We are developing an enterprise monitoring application that requires a hybrid Swift + Python architecture due to strict JAMF deployment restrictions. We must deploy a macOS application via ABM/App Store Connect, but our core monitoring logic is in a Python daemon. We need to understand the feasibility and best practices for TCC permission inheritance in this specific setup. Architecture Component Bundle ID Role Deployment Swift Launcher com.athena.AthenaSentry Requests TCC permissions, launches Python child process. Deployed via ABM/ASC. Python Daemon com.athena.AthenaSentry.Helper Core monitoring logic using sensitive APIs. Nested in Contents/Helpers/. Both bundles are signed with the same Developer ID and share the same Team ID. Required Permissions The Python daemon needs to access the following sensitive TCC-controlled services: Screen Recording (kTCCServiceScreenCapture) - for capturing screenshots. Input Monitoring (kTCCServiceListenEvent) - for keystroke/mouse monitoring. Accessibility (kTCCServiceAccessibility) - a prerequisite for Input Monitoring. Attempts & Workarounds We have attempted to resolve this using: Entitlement Inheritance: Added com.apple.security.inherit to the Helper's entitlements. Permission Proxy: Swift app maintains active event taps to try and "hold" the permissions for the child. Foreground Flow: Keeping the Swift app in the foreground during permission requests. Questions Is this architecture supported? Can a Swift parent app successfully request TCC permissions that a child process can then use? TCC Inheritance: What are the specific rules for TCC permission inheritance between parent/child processes in enterprise environment? What's the correct approach for this enterprise use case? Should we: Switch to a Single Swift App? (i.e., abandon the Python daemon and rewrite the core logic natively in Swift). Use XPC Services? (instead of launching the child process directly).

I'm developing an application for a client. This app is intended to be sold with a subscription. My client wants that at the time of registration, the user's data (name, date of birth, address, etc.) be sent to a server to be saved in a database for commercial purposes. What is Apple's policy knowing that the user will have the ability to give their consent

FB18383742 Setup 🛠️ Xcode 16.4 (16F6) 📱 iPhone 13 mini (iOS 18.0.1) ⌚️ Apple Watch Series 10 (watchOS 11.3.1) Observations As AccessorySetupKit does not request "Core Bluetooth permissions", when a watchOS companion app is installed after having installed the iOS app, the toggle in the watch settings for Privacy & Security > Bluetooth is turned off and disabled After removing the iPhone associated with the Apple Watch, Bluetooth works as expected in the watchOS app Upon reinstalling the iOS app, there's a toggle for Bluetooth in the iOS ASK app's settings and the ASK picker cannot be presented 🤨 From ASK Documentation: AccessorySetupKit is available for iOS and iPadOS. The accessory’s Bluetooth permission doesn’t sync to a companion watchOS app. But this doesn't address not being able to use Core Bluetooth in a watch companion app at all 🥲 Reproducing the bug Install the iOS + watchOS apps Launch iOS app, tap "start scan", observe devices can be discovered (project is set up to find heart rate monitors) Launch watchOS, tap allow on Bluetooth permission pop-up watchOS app crashes 💥 Meanwhile, in the iOS app, there should be a log entry for 💗 CBCentralManager state: poweredOff and the ASK picker is no longer able to discover any devices The state of the device permissions: iOS app has no paired accessories or Bluetooth permission watchOS app's Bluetooth permission shown as turned off & disabled Remove the iOS app Relaunch the watchOS app Notice the CBCentralManager state is unauthorized Remove and reinstall the watchOS app Tap allow on Bluetooth permission pop-up watchOS app does not crash and CBCentralManager state is poweredOn The state of the watch permissions: Bluetooth is turned on & the toggle is not disabled Note that at this time the iOS app is not installed, there is no way to remove Bluetooth permission for the watch app. Reinstall + launch the iOS app Notice a warning in the log: [##### WARNING #####] App has companion watch app that maybe affected if using CoreBluetooth framework. Please read developer documentation for AccessorySetupKit. Notice a log entry for 💗 CBCentralManager state: poweredOn before tapping start scan Tap start scan and observe another log entry: Failed to show picker due to: The operation couldn’t be completed. (ASErrorDomain error 550.) ASErrorDomain 550: The picker can't be used because the app is in the background. Is this the expected error? 🤔 The state of the iOS permissions: The app's settings show a Bluetooth toggle normally associated with Core Bluetooth, but the app never showed a Core Bluetooth pop-up The iOS ASK app now has Core Bluetooth permission 😵‍💫 Following up with Apple This is a known bug that should be fixed in watchOS 26 when Bluetooth permissions for watch apps can be set independently of the iOS app. I've yet to test it with watchOS 26. See repo for the same post with screenshots of the settings and demo code reproducing the bug: https://github.com/superturboryan/AccessorySetupKit-CoreBluetooth-watchOS-Demo

I have a project that need to get serial number and network SSID. I have looking anywhere to get those 2 value but no luck to find it. is there anyway i can get those information from the device?

Hello everyone, Our app, NumberBox, was rejected due to Guideline 5.1.1, with the review team saying it “collects information from public sources to build individual profiles.” We want to clarify: All data is 100% user-reported. Users voluntarily submit phone numbers (spam, scam, or telemarketing) and assign tags through the “Add Tag” feature. No data is collected from public sources or user contacts. No profiles are built automatically. All user submissions are reviewed by our support team before being displayed. The sole purpose of NumberBox is to help users avoid unwanted or scam calls, not to collect personal data. Our updated Privacy Policy is here: https://numberbox.app/privacypolicy Has anyone encountered a similar issue with Guideline 5.1.1? Any guidance on how to clearly communicate this to App Review would be greatly appreciated. Thanks in advance!

Documentation seems to say that privacySensitive is supposed to redact on the lockScreen. I've disabled "Allow Access when locked" for "Lock Screen Widgets" just in case. It does not work for me. If I add "redacted(reason:) into the view hierarchy it redacts all the content all the time including on the home screen. I've read articles. I gone through a lot of documentation. None of them seem to give the magic formula for redacting sensitive content on the lock screen. I'm using iOS 18.7 on a real iPhone 14 Pro Max.

Hello world! First post here. Developing my first app. It primarily targets supervised and MDM managed devices. A few questions: For supervised devices, is serial number available? I want to get the number and use it for app auto activation Is MDM required for supervised devices? Or, as long as a device is enrolled through Apple Business Manager? Which capacity shall I request for the app? Thanks so much!

Is it possible to create a sandboxed app that uses accessibility permission? And if so, how do I ask the user for that permission in a way that is allowed by the App Store? Im creating a small menubar app and my current (rejected) solution is to create a pop-up, with link to Security & Privacy > Accessibility and the pop-up asks the user to manually add the app to the list and check the checkbox. This works in sandbox. Reason for rejection: "Specifically, your app requires to grant accessibility access, but once we opened the accessibility settings, your app was not listed." I know it's not listed there and it has to be added manually. But its the only solution I've found to this issue. Is there perhaps any way to add the app there programmatically? Im a bit confused since I've seen other apps in App Store that work the same way, where you have to add the app to the list manually. Eg. Flycut. :man-shrugging: I know about this alternative solution, and it's not allowed in sandboxed apps. It also adds the app to the accessibility list automagically: func getPermission() { AXIsProcessTrustedWithOptions([kAXTrustedCheckOptionPrompt.takeUnretainedValue():true] as CFDictionary). } Does anyone have a solution for this? Best regards, Daniel

Hi , I have a requirement like, Develop an app for iPad and app uses .net core apis. App will be in kiosk mode, and app doesn't have any type of authentication even OTP also. As the apis will be publishing to all over internet, how can we achieve security to apis? Kindly provide suggestions for this implementation

Starting with macOS 15 (Sequoia), applications that perform network discovery operations now trigger a permission prompt: "Allow [AppName] to find devices on local networks". I am using sysctl() with NET_RT_FLAGS and RTF_LLINFO to access the ARP table and retrieve gateway MAC addresses: int mib[6]; mib[0] = CTL_NET; mib[1] = PF_ROUTE; mib[2] = 0; mib[3] = AF_INET; mib[4] = NET_RT_FLAGS; mib[5] = RTF_LLINFO; // This flag accesses ARP table entries if (sysctl(mib, 6, buf, &needed, NULL, 0) < 0) return nil; From my testing, the Local Network Access prompt does not always appear. It looks like if the MAC address is already cached in the ARP table, no prompt is shown, and the prompt only appears when the system needs to resolve a new MAC address. Is this correct behavior? Does ARP resolution by itself triggering the prompt?

Hello Developers, I have ran into a problem while sending mail to apple private relay email. We have built a mobile application where user can sign up through apple and they can sign up using hide-my-email feature. Which provides private relay address for us. Now we want to communicate with them using private relay mail address. The technology we are using to send emails are amazon SES, have done SPF, DMIK, DMARC and added domains in apple identity services for mail communication, passed an SPF check as well. But still mail is not getting delivered what am i doing wrong or apple doesn't support third party apps for sending emails to private relay? Is there any other way to achieve this please let me know Using the same body as attached in image is working fine for rest emails.

Hello, PrivacyInfo.xcprivacy Is primordial and without it the app is rejected from the Store I believe. All 5 ressources I had found related to it, mention XCODE, or explain how to add the code to langages that I don't use (Switf i think?) etc. I am building the app thought CI/CD, so prior to building it the app does not have privacy manifest and there is not way to generate it automatically without xcode it seems. My app is written in Flutter prior to becoming an iOS app. I am seeking for a method to do that. Thanks.

Hi, after upgrading to MacOS Sequoia, my connection to my local IP address does not work. The issue is with the PF (MacOS advanced firewall), as I confirmed that my local application works disabling it temporarily. Does anyone know how can I do to solve this problem? As APP developer, this is a big problem for me. Thanks in advance.

Hello everyone, I've noticed some unusual behavior while debugging my application on the iOS 26 beta. My standard testing process relies on the App Tracking Transparency (ATT) authorization status being reset whenever I uninstall and reinstall my app. This is crucial for me to test the permission flow. However, on the current beta, I've observed the following: 1 I installed my app on a device running the iOS 26 beta for the first time. The ATTrackingManager.requestTrackingAuthorization dialog appeared as expected. 2 I completely uninstalled the application. 3 I then reinstalled the app. Unexpected Result: The tracking permission dialog did not appear. And more importantly, the device's advertisingIdentifier appears to have remained unchanged. This is highly unusual, as the IDFA is expected to be reset with a fresh app installation. My question: Is this an intentional change, and is there a fundamental shift in how the operating system handles the persistence of the IDFA or the authorization status? Or could this be a bug in the iOS 26 beta? Any information or confirmation on this behavior would be greatly appreciated.