I requested permission to use the Family Controls entitlement two weeks ago, and I have not received a response or status update. I have been to that page where it says "Thank you! We'll get back to you soon!" so many times.

I work on an app that has the com.apple.developer.mail-client entitlement. We're interested in trying out Xcode Cloud, and one of the project and workspace requirements is to use automatic code signing. We do not do this at the moment because it's not compatible with the additional entitlement. My understanding is that we can migrate to automatic code signing if we migrate the additional entitlement to a capability and that to accomplish this our account holder needs to submit a request (see the last section of that page). We submitted the request a little over 3 weeks ago, but so far we haven't heard any updates. We also tried reaching out directly to the email address linked in the com.apple.developer.mail-client docs, but have not heard back. We're now posting here to see if anyone can provide some guidance on whether there are other steps to complete or contacts to whom we should reach out. Thanks!

I’m attempting to make an app that uses Disk Arbitration to intercept a disk mount (by creating and returning a dissenter in the appropriate callback) and then mount the disk with certain options (specifically, read-only, nobrowse, or both, depending on user options). For example: DADiskMountWithArguments(disk, nil, DADiskMountOptions(kDADiskMountOptionDefault), nil, nil, kReadOnly) …where kReadOnly is a pointer to an array only containing a “rdonly” CFString. While DADiskMountWithArguments seems to be usable in a sandboxed app for disk images, it doesn’t work when the disk is an external disk (e.g. connected via USB). I see lines like this in Console.app when this happens: Sandbox denied authorizing right 'system.volume.external.mount' by client '/path/to/exe' [17934] (engine 580) I’ve identified two workarounds that allow this to work in a sandbox, but both have their own problems: If a LaunchDaemon (even a sandboxed one, which is required for registration with SMAppService.daemon from the sandboxed app) does the call to DADiskMountWithArguments, it will succeed. But App Store policies don’t allow escalation to root. If I use the undocumented entitlement com.apple.security.temporary-exception.sbpl with a value of (allow authorization-right-obtain (right-name "system.volume.external.mount")), the mount works without escalation to root. But I understand that App Review is likely to reject the use of this entitlement, and that this entitlement isn't supported to begin with. Specifically, these are the behaviors I see on macOS Sequoia 15.3.1 and Xcode 16.2. Since I would like to try to publish this app on the App Store, neither of these seem like acceptable solutions. I don’t see why this should be restricted if the sandboxed app is not declaring a special path (i.e. the path in DADiskMountWithArguments is set to nil) and still does not have access to the mounted filesystem - am I missing something/is there a way to accomplish this?

I am developing an app that can help users disable selected apps at a specified time, so that users can get away from their phones and enjoy real life. Here is my data structure: extension ActivityModel { @NSManaged public var id: UUID @NSManaged public var name: String @NSManaged public var weeks: Data @NSManaged public var weekDates: Data @NSManaged public var appTokens: Data } Among them, weeks is of [Bool] type, indicating which weeks from Sunday to Saturday are effective; weekDates is of [[Date,Date]] type, indicating the effective time period; appTokens is of Set type, indicating the selected apps。 At the beginning, I will open a main monitor: let deviceActivityCenter = DeviceActivityCenter() do{ try deviceActivityCenter.startMonitoring( DeviceActivityName(activityModel.id), during: DeviceActivitySchedule( intervalStart: DateComponents(hour: 0,minute: 0,second: 0), intervalEnd: DateComponents(hour: 23,minute: 59,second: 59), repeats: true ) ) }catch { return false } Since the time range may be different every day, I will start the sub-monitoring of the day every time the main monitoring starts： override func intervalDidStart(for activity: DeviceActivityName) { super.intervalDidStart(for: activity) if activity.rawValue.hasPrefix("Sub-") { ActivityModelManager.disableApps( Tools.getUUIDFromString(activity.rawValue) ) return } let weekIndex = Calendar.current.component(.weekday, from: .now) let weeks = ActivityModelManager.getWeeks(activity.rawValue) if weeks[weekIndex] { let weekDates = ActivityModelManager.getWeekDates(activity.rawValue) let deviceActivityCenter = DeviceActivityCenter() do{ try deviceActivityCenter.startMonitoring( DeviceActivityName("Sub-" + activityModel.id), during: DeviceActivitySchedule( intervalStart: getHourAndMinute(weekDates[weekIndex][0]), intervalEnd: getHourAndMinute(weekDates[weekIndex][1]), repeats: false ) ) }catch { return } }esle { return } } I will judge whether it is main monitoring or sub monitoring based on the different activity names. When the sub-monitor starts, I will get the bound application and then disable it: static func disableApps(_ id : UUID){ let appTokens = ActivityModelManager.getLimitAppById(id) let name = ManagedSettingsStore.Name(id.uuidString) let store = ManagedSettingsStore(named: name) store.shield.applications = appTokens return } When the child monitoring is finished, I resume the application: static func enableApps(_ id : UUID){ let name = ManagedSettingsStore.Name(id.uuidString) let store = ManagedSettingsStore(named: name) store.shield.applications = [] } The above is my code logic. When using DeviceActivityMonitorExtension, I found the following problems: intervalDidStart may be called multiple times, resulting in several sub-monitors being started. After a period of time, the monitoring is turned off. The static methods enableApps and disableApps are sometimes not called

Hello, My current app bundle structure is I have a sandboxed GUI and a unsandboxed launch agent that does the core logic of my app. Our pkg post install scripts handles bootstrapping the Launch Agent plists defined in /Library/Launch Agents. I have been tasked with creating a restart/exit button on the UI which terminates the Launch Agent (essentially bootout command in launchctl) and terminates the UI as well. I have attempted to follow the SMAppServcice.agent(plistName) and changed Program key to BundleProgram and changed the value to the relative path as in example provided in Apple Docs (old launch agent plist attached, and new bundle build phase style attached. I have been unable to register or unregister the launch agent via the UI, and in the initial case when trying to call unregister the launch agent got removed and i got "Operation not permitted" with error kSMErrorInvalidSignature seems like some code signature issue im not aware of. I wasnt even able to bootstrap the launch agent back until I found a script which reset such launchctl settings. My question is: is the sandboxed UI not able to do this (and why is this not documented in the dev docs I have no idea), and if so then how would I go about terminating both services and also being able to restart them? This seems like a common use case the UI should be able to handle as far as ownership of running/booting out its resources. ).

I'm working on a Password Manager app that integrates with the AutoFill Credential Provider to provide stored passwords and OTPs to the user within Safari and other apps. Password AutoFill works perfectly. I'm unable to get iOS to register that the app supports OTPs though. I've followed the Apple documentation here: https://developer.apple.com/documentation/authenticationservices/providing-one-time-passcodes-to-autofill and added "ProvidesOneTimeCodes" to the AutoFill extension's Info.plist, but iOS just doesn't seem to notice the OTP support. <key>ASCredentialProviderExtensionCapabilities</key> <dict> <key>ProvidesOneTimeCodes</key> <true/> <key>ProvidesPasswords</key> <true/> </dict> Any help would be greatly appreicated!

I have some questions regarding App Group Id's and use of the FileManager during an Appstore iOS transfer. I've read a lot of the topics here that cover app groups and iOS, but it's still unclear exactly what is going to happen during transfer when we try to release an updated version of the app from the new account. We're using this method FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: "group.com.foo.bar") to store files on the device that are important for app launch and user experience. Once we transfer the app and begin the process of creating a new version under the new account will we be able to read the files that are stored using this app group id under the new account? What steps do we need to take in order to handle this and continue being able to access these files? It seems like the app group is not transferred in the process? I've seen some users mention they removed the app group from the original account and created it again under the receiving account (with notes mentioning this is undocumented behavior). These conversations we're centered around Shared user defaults, and that applies as well but I'm more concerned with reading the values from the file system. Thanks!

I have added 2 command line tools in my swiftUI app for macOS, it was working fine locally, but it gives error when i try to make archive of it. I am not sure about the reason, but it was related to sandboxing the command line tools, after this i have tried multiple solutions but i am unable to resolve this issue, how should i handle the helper command line tools

I use shared UserDefaults in my Swift FileProvider extension app suite. I share data between the containing app and the extension via User Defaults initialized with init(suiteName:). Everything was working fine before macOS 15 (Sequoia). I know that Sequoia changed the way the app group should be configured. My app group is know set to "$(TeamIdentifierPrefix)com.my-company.my-app". But the containing (UI) app and the Extension read and write from and to different plist locations although the same app-group is specified for both targets in XCode. The containing app reads and writes to "~/Library/Preferences/$(TeamIdentifierPrefix)com.my-company.my-app.plist" The Extension reads and writes to "~/Library/Containers/com.my-company.my-app.provider/Data/Library/Preferences$(TeamIdentifierPrefix)com.my-company.my-app.plist" Both of these locations seem completely illogical for shared UserDefaults. I checked the value returned by FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: "$(TeamIdentifierPrefix)com.my-company.my-app" in both the containing app and the Extension and the value in both of them is the same but has nothing to do with the actual paths where the data is stored as provided above. (The value is as expected - "~/Library/Group Containers/$(TeamIdentifierPrefix)com.my-company.my-app/" P.S. Of course, $(TeamIdentifierPrefix), my-company and my-app here are placeholders for my actual values.

My app is a Safari extension. When trying to validate the app, I get the following error: App sandbox not enabled. The following executables must include the "com.apple.security.app-sandbox" entitlement with a Boolean value of true in the entitlements property list: [( "app.rango.Rango.pkg/Payload/Rango for Safari.app/Contents/MacOS/Rango for Safari" )] Refer to App Sandbox page at https://developer.apple.com/documentation/security/app_sandbox for more information on sandboxing your app. I don't know why this is happening. I have app sandbox enabled in both the app and the extension target. I have both entitlement files. When executing codesign -d --entitlements :- /path/to/binary I get the following: <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"><dict><key>com.apple.security.app-sandbox</key><true/><key>com.apple.security.files.user-selected.read-only</key><true/><key>com.apple.security.get-task-allow</key><true/><key>com.apple.security.network.client</key><true/></dict></plist> If I check on Activity Monitor, on the sandbox column it shows true. I have no idea why I keep getting this error when all indicates that the app is actually sandboxed.

I noticed the time sensitive entitlement says it's only for iOS and macOS. But without the entitlement, the time sensitive toggle doesn't show in my app's notification settings on visionOS. When I archive my visionOS app for App Store Connect, the entitlement seems to be taken out as it doesn't show in my entitlement list for the build in App Store Connect. I'm confused at this point if the entitlement is really necessary, since it seems to be needed to debug on the simulator at least. I don't have a physical device to test it on unfortunately.