I've developed a Mac app distributed through the App Store that uses NSAppleScript to control Spotify and Apple Music. I'm experiencing inconsistent behavior with automation permission prompts that's affecting user experience. Expected Behavior: When my app first attempts to send Apple Events to Spotify or Apple Music, macOS should display the automation permission prompt, and upon user approval, the app should appear in System Preferences > Security & Privacy > Privacy > Automation. Actual Behavior: Initial permission prompts work correctly when both apps are actively used after my app download. If a user hasn't launched Spotify/Apple Music for an extended period, the permission prompt fails to appear when they later open the music app. The music app doesn't appear in the Automation privacy pane too. Once this happens, permission prompts never trigger again for that app Steps to Reproduce: Fresh install of my app Don't use Spotify for several days/weeks Launch Spotify Trigger Apple Events from my app to Spotify No permission prompt appears, app doesn't show in Automation settings If you're using Apple Music during this time it runs without any problems. Troubleshooting Attempted: Used tccutil reset AppleEvents [bundle-identifier] - no effect Verified target apps are fully launched before sending Apple Events Tried different AppleScript commands to trigger permissions Problem occurs inconsistently across different Macs Technical Details: macOS 13+ support Using standard NSAppleScript with simple commands like "tell application 'Spotify' to playpause" App Store distribution (no private APIs) Issue affects both Spotify and Apple Music but seems more prevalent with Apple Music Questions: Is there a reliable way to programmatically trigger the automation permission prompt? Are there timing dependencies for when macOS decides to show permission prompts? Could app priority/usage patterns affect permission prompt behavior? I use MediaManager to run the functions and initialize it on AppDidFinishLaunching method and start monitoring there. Any insights or workarounds would be greatly appreciated. This inconsistency is affecting user onboarding and app functionality.

Hi All, Like many others I'm a little confused with gaining access to the family controls capability. Our app is ready to push to testflight, and we sent the request to apple last week. However only learning today that we need to request for the shield extension as well. I wanted to ask what the expected timeline is for being approved? I've seen posts here saying less than a week, and some people having to wait longer than 6 weeks. Any advise or guidance on getting approved smoothly & swiftly would be highly appreciated

The capability associated with "FAMILY_CONTROLS" could not be determined. Please file a bug report at https://feedbackassistant.apple.com and include the Update Signing report from the Report navigator.

This issue keeps cropping up on the forums and so I decided to write up a single post with all the details. If you have questions or comments: If you were referred here from an existing thread, reply on that thread. If not, feel free to start a new thread. Use whatever topic and subtopic is appropriate for your question, but also add the Entitlements tag so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Determining if an entitlement is real In recent months there’s been a spate of forums threads involving ‘hallucinated’ entitlements. This typically pans out as follows: The developer, or an agent working on behalf of the developer, changes their .entitlements file to claim an entitlement that’s not real. That is, the entitlement key is a value that is not, and never has been, supported in any way. Xcode’s code signing machinery tries to find or create a provisioning profile to authorise this claim. That’s impossible, because the entitlement isn’t a real entitlement. Xcode reports this as a code signing error. The developer misinterprets that error [1] in one of two ways: As a generic Xcode code signing failure, and so they start a forums thread asking about how to fix that problem. As an indication that the entitlement is managed — that is, requires authorisation from Apple to use — and so they start a forums thread asking how to request such authorisation. The fundamental problem is step 1. Once you start claiming entitlements that aren’t real, you’re on a path to confusion. Note If you’re curious about how provisioning profiles authorise entitlement claims, read TN3125 Inside Code Signing: Provisioning Profiles. There are a couple of ways to check whether an entitlement is real. My preferred option is to create a new test project and use Xcode’s Signing & Capabilities editor to add the corresponding capability to it. Then look at what Xcode did. You might find that Xcode claimed a different entitlement, or added an Info.plist key, or did nothing at all. IMPORTANT If you can’t find the correct capability in the Signing & Capabilities editor, it’s likely that this feature is available to all apps, that is, it’s not gated by an entitlement or anything else. Another thing you can do is search the documentation. The vast majority of real entitlements are documented in Bundle Resources > Entitlements. IMPORTANT When you search for documentation, focus on the Apple documentation. If, for example, you search the Apple Developer Forums, you might be mislead by other folks who are similarly confused. If you find that you’re mistakenly trying to claim a hallucinated entitlement, the fix is trivial: Remove it from your .entitlements file so that your app starts to build again. Then add the capability using Xcode’s Signing & Capabilities editor. This will do the right thing. If you continue to have problems, feel free to ask for help here on the forums. See the top of this post for advice on how to do that. [1] It’d be nice if the Xcode errors were more clear in this case (r. 155327166). Commonly Hallucinated Entitlements This section lists some of the more commonly hallucinated entitlements: com.apple.developer.push-notifications — The correct entitlement is aps-environment (com.apple.developer.aps-environment on macOS), documented here. There’s also the remote-notification value in the UIBackgroundModes property. com.apple.developer.in-app-purchase — There’s no entitlement for in-app purchase. Rather, in-app purchase is available to all apps with an explicit App ID (as opposed to a wildcard App ID). com.apple.InAppPurchase — Likewise. com.apple.developer.storekit — Likewise. com.apple.developer.app-groups — The correct entitlement is com.apple.security.application-groups, documented here. And if you’re working on the Mac, see App Groups: macOS vs iOS: Working Towards Harmony. com.apple.developer.background-modes — Background modes are controlled by the UIBackgroundModes key in your Info.plist, documented here. UIBackgroundModes — See the previous point. com.apple.developer.voip-push-notification — There’s no entitlement for this. VoIP is gated by the voip value in the UIBackgroundModes property. com.apple.developer.family-controls.user-authorization — The correct entitlement is com.apple.developer.family-controls, documented here. IMPORTANT As explained in the docs, this entitlement is available to all developers during development but you must request authorisation for distribution. com.apple.developer.device-activity — The DeviceActivity framework has the same restrictions as Family Controls. com.apple.developer.managed-settings — If you’re trying to use the ManagedSettings framework, that has the same restrictions as Family Controls. If you’re trying to use the ManagedApp framework, that’s not gated by an entitlement. com.apple.developer.callkit.call-directory — There’s no entitlement for the Call Directory app extension feature. com.apple.developer.nearby-interaction — There’s no entitlement for the Nearby interaction framework. com.apple.developer.secure-enclave — On iOS and its child platforms, there’s no entitlement required to use the Secure Enclave. For macOS specifically, any program that has access to the data protection keychain also has access to the Secure Enclave [1]. See TN3137 On Mac keychain APIs and implementations for more about the data protection keychain. com.apple.developer.networking.configuration — If you’re trying to configure the Wi-Fi network on iOS, the correct entitlement is com.apple.developer.networking.HotspotConfiguration, documented here. [1] While technically these are different features, they are closely associated and it turns out that, if you have access to the data protection keychain, you also have access to the SE. Revision History 2025-09-22 Added com.apple.developer.storekit. 2025-09-05 Added com.apple.developer.device-activity. 2025-09-02 First posted.

I am trying to sign a enterprise app with provisioning profile which shows the tap to pay entitlement on Dev portal, but when downloaded on Xcode, it says the profile is missing the tap to pay capability and entitlement The capability was enabled by apple already, it was working fine until the provisioning profile got renewed.

The problem is described in full with log output in #16844 We are having an issue with TCC prompting users for access to the app group container despite signing with entitlements following all guidelines. This is a regression from the Feb 2025 Changes discussed in App Groups: macOS vs iOS: Working Towards Harmony The problem can only be reproduced with Xcode 16.0 and later. The entitlements for the app include access for the group container with [Key] com.apple.security.application-groups [Value] [Array] [String] G69SCX94XU.duck The documentation notes the group name can be arbitrary, e.g. <team identifier>.<group name>. Cyberduck uses G69SCX94XU.duck by default. Interestingly enough the alert is not shown when a group name matching the bundle identifier is used, e.g. G69SCX94XU.ch.sudo.cyberduck.