Hi Team, We intend to create a custom serial dispatch queue targetting a global queue. let serialQueue = DispatchQueue(label: "corecomm.tallyworld.serial", target: DispatchQueue.global(qos: .default)) The documentation for DispatchQueue init does not show any minimum OS versions. BUT DispatchSerialQueue init does show iOS 17.0+ iPadOS 17.0+ Mac Catalyst macOS 14.0+ tvOS 17.0+ visionOS watchOS 10.0+. Does that mean - I will not be able to create a custom serial dispatch queue below iOS 17?

I’m trying to enable Background Modes (specifically for audio, background fetch, remote notifications) in my iOS SwiftUI app, but I’m getting this error: Provisioning profile “iOS Team Provisioning Profile: [my app]” doesn’t include the UIBackgroundModes entitlement. On the developer website when I make the provision profile It doesnt give me the option to allow background modes. I added it to the sign in capabilities seccion in X code and matched the bundle ID to the provision profile and certificate etc but it still runs this error because the provision profile doesnt have the entitlements..

An XPC service’s process has a system-managed lifecycle: the process is launched on-demand when another process tries to connect to it, and the system can decide to kill it when system resources are low. XPC services can tell the system when they shouldn’t be killed using xpc_transaction_begin/end. Do extensions created with ExtensionFoundation and/or ExtensionKit have the same behavior?

I am developing the application in Mac. My requirement is to start the application automatically when user login. I have tried adding the plist file in launch agents, But it doesn't achieve my requirement. Please find the code added in the launch agents <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>com.sftk.secure</string> <key>ProgramArguments</key> <array> <string>/Applications/Testing.app/Contents/MacOS/Testing</string> </array> <key>RunAtLoad</key> <true/> <key>KeepAlive</key> <false/> </dict> </plist> I have tried by adding manually in the setting, but it was opened sometimes and closed suddenly. On open manually it works. Please provide a solution to start the application automatically on system starts

Hi everyone, We’re developing a macOS SwiftUI app that uses a local Swift Package (CasSherpaCore) to invoke an external compiled binary (sherpa-onnx-offline-tts) for text-to-speech synthesis using system calls. The package works flawlessly when tested from terminal or via a lightweight test C program. However, when we invoke it from a SwiftUI app (even with Full Disk Access granted to Xcode and Terminal), we consistently get the error: sh: /Users/xxxxxxxxxxx/SherpaONNX/sherpa-onnx/build/bin/sherpa-onnx-offline-tts: Operation not permitted We’ve tried: Granting Full Disk Access to Xcode and Terminal. Removing the quarantine flag with xattr -d com.apple.quarantine. Setting executable permission via chmod +x. Using both system() and Process in C and Swift contexts. Testing within a Swift Package that’s integrated into the app as a local dependency. Running the command manually from terminal (works perfectly). It appears that macOS (or Xcode’s runtime sandbox) is restricting execution of binaries from certain locations or contexts when launched via system() inside the app. Questions: Is there a specific entitlement or configuration that allows execution of local binaries from a SwiftUI macOS app? Is this related to System Integrity Protection (SIP) or a hardened runtime limitation? Are there best practices or alternative approaches to safely execute local TTS binaries from within a Swift app? Any help would be deeply appreciated. This is a core feature in our project and we’re stuck at this point. Thank you so much in advance!

My app is for personal use currently, so distribution won't be a problem. It registers a privileged helper using SMAppService, and I was wondering whether there is a way to customize the authorization dialog that the system presents to the user.

My app uses SMAppService to register a privileged helper, the helper registers without errors, and can be seen in System Settings. I can get a connection to the service and a remote object proxy, but the helper process cannot be found in Activity Monitor and the calls to the proxy functions seem to always fail without showing any specific errors. What could be causing this situation?

SMAppService Error 108 "Unable to read plist" on macOS 15 Sequoia - Comprehensive Test Case Summary We have a fully notarized SMAppService implementation that consistently fails with Error 108 "Unable to read plist" on macOS 15 Sequoia, despite meeting all documented requirements. After systematic testing including AI-assisted analysis, we've eliminated all common causes and created a comprehensive test case. Error: SMAppServiceErrorDomain Code=108 "Unable to read plist: com.keypath.helperpoc.helper" 📋 Complete Repository: https://github.com/malpern/privileged_helper_help What We've Systematically Verified ✅ Perfect bundle structure: Helper at Contents/MacOS/, plist at Contents/Library/LaunchDaemons/ Correct SMAuthorizedClients: Embedded in helper binary via CREATE_INFOPLIST_SECTION_IN_BINARY=YES Aligned identifiers: Main app, helper, and plist all use consistent naming Production signing: Developer ID certificates with full Apple notarization and stapling BundleProgram paths: Tested both Contents/MacOS/helperpoc-helper and simplified helperpoc-helper Entitlements: Tested with and without com.apple.developer.service-management.managed-by-main-app What Makes This Different Systematic methodology: Not a "help me debug" post - we've done comprehensive testing Expert validation: AI analysis helped eliminate logical hypotheses Reproduction case: Minimal project that demonstrates the issue consistently Complete documentation: All testing steps, configurations, and results documented Use Case Context We're building a keyboard remapper that integrates with https://github.com/jtroo/kanata and needs privileged daemon registration for system-wide keyboard event interception. Key Questions Does anyone have a working SMAppService implementation on macOS 15 Sequoia? Are there undocumented macOS 15 requirements we're missing? Is Error 108 a known issue with specific workarounds? Our hypothesis: This appears to be a macOS 15 system-level issue rather than configuration error, since our implementation meets all documented Apple requirements but fails consistently. Has anyone encountered similar SMAppService issues on macOS 15, or can confirm a working implementation?

Hello, I have a question regarding the behavior of BGProcessingTaskRequest when the app is force-quit by the user via the App Switcher. Based on common understanding and various discussions — including the following Apple Developer Forum threads: Waking up an iOS app after app is … | Apple Developer Forums Will BGAppRefreshTaskRequest will … | Apple Developer Forums Background fetch after app is forc… | Apple Developer Forums …it is widely understood that iOS prevents background execution (such as background fetch, push notifications, or BGTaskScheduler) after a user force-quits an app via the App Switcher. However, in my app, I have observed that a scheduled BGProcessingTaskRequest still executes even after the app has been explicitly terminated via App Switcher. The task is scheduled using submit(_:error:), and it is clearly running some time after the app has been closed by the user. That said, the task does run, but it appears to operate under tighter constraints — for example, it may be allowed to run for a shorter duration, and network requests appear to be more restricted compared to when the app is not force-quit. My questions are: Are there any documented or undocumented exceptions that allow this kind of behavior after force-quit? Could this be a bug or a behavior change in recent iOS versions? (I am observing this on iOS 18.3, 18.4, and 18.5) Any insights, experiences, or clarifications from Apple engineers or fellow developers would be greatly appreciated. Thank you!

Basically the title. I am trying to implement a local notification to trigger, regardless of internet connection, around 3-5pm if a certain array in the app is not empty to get the user to sync unsaved work with the cloud. I wanted to used the BGAppRefreshTask as I saw it was lightweight and quick for just posting a banner notification but after inspecting it in the console, it looks like it needs internet connection to trigger. Is this the case or am I doing something wrong? Should I be using the BGProcessingTask instead?

I am trying to create an app bundle with an xpc service. The main app creates a keychain item, and attempts to share (keychain access groups) with the xpc service it includes in its bundle. However, the xpc service always encounters a 'user interaction not allowed' error regardless of how I create the keychain item. kSecAttrAccessiblei is set to kSecAttrAccessibleWhenUnlockedThisDeviceOnly, the keychain access group is set for both the main app and the xpc service and in the provisioning profile. I've tried signing and notarizing. Is it ever possible for an xpc service to access the keychain? This all on macos 15.5.

my app need tracking location all the time both foreground and background. Please suggest how to prevent the app from being terminated. or detect when app is terminated.

Hello 👋 Our team added com.apple.security.temporary-exception.apple-events: com.apple.Terminal recently to our Mac app to be able to tell the terminal to execute a specific command line automatically for the user when clicking a button but we've been rejected during review because of this entitlement so for now we've deleted it and deleted the associated feature. It concerns the following feature (see attachment). Context: Among other things the application enable to review pull request changes (remote) and we would like a button to automatically clone the pull request on disk when user click a button. We would like to use terminal for security reason as when cloning using git command we need ssh keys or other credential and there's no reason (rather than technical ones) that the user provide us such private information that is stored in the ~/.ssh. We prefer think the other way around and tell the user what to execute instead (no credentials involved or shared). We referred to: https://developer.apple.com/library/archive/documentation/Miscellaneous/Reference/EntitlementKeyReference/Chapters/AppSandboxTemporaryExceptionEntitlements.html I admit it's unclear for me if this will imply a 100% rejection or if these entitlements are deprecated. Is "com.apple.security.temporary-exception.apple-events: com.apple.Terminal" an entitlement that is reserved for special Apple partners ? Is it an entitlement that we should demonstrate usage first ? Or should we completely remove the feature if we distribute through the App Store ? Is Apple advice for other APIs to develop such features (execute command line for the user) when distributing through the App Store ? As said we've disabled the feature for now. Thank you in advance for those who will take time to answer this,

I've discovered that a system network extension can communicate with a LaunchDaemon (loaded using SMAppService) over XPC, provided that the XPC service name begins with the team ID. If I move the launchd daemon plist to Contents/Library/LaunchAgents and swap the SMAppService.daemon calls to SMAppService.agent calls, and remove the .privileged option to NSXPCConnection, the system extension receives "Couldn't communicate with a helper application" as an error when trying to reach the LaunchAgent advertised service. Is this limitation by design? I imagine it is, but wanted to check before I spent any more time on it.

when we use raise in GCD, the signal handler is executed asynchronously, whereas in pthread, it is executed synchronously as expected. example: #include <Foundation/Foundation.h> #include <pthread/pthread.h> static void HandleSignal(int sigNum, siginfo_t* signalInfo, void* userContext) { printf("handle signal %d\n", sigNum); printf("begin sleep\n"); sleep(3); printf("end sleep\n"); } void InstallSignal(void) { static const int g_fatalSignals[] = { SIGABRT, SIGBUS, SIGFPE, SIGILL, SIGPIPE, SIGSEGV, SIGSYS, SIGTRAP, }; int fatalSignalsCount = sizeof(g_fatalSignals) / sizeof(int); struct sigaction action = {{0}}; action.sa_flags = SA_SIGINFO | SA_ONSTACK; #if defined(__LP64__) action.sa_flags |= SA_64REGSET; #endif sigemptyset(&action.sa_mask); action.sa_sigaction = &HandleSignal; struct sigaction pre_sa; for(int i = 0; i < fatalSignalsCount; i++) { int sigResult = sigaction(g_fatalSignals[i], &action, &pre_sa); } } void* RaiseAbort(void *userdata) { raise(SIGABRT); printf("signal handler has finished\n"); return NULL; } int main(int argc, const char * argv[]) { InstallSignal(); dispatch_async(dispatch_get_global_queue(0, 0), ^{ raise(SIGABRT); // abort(); // abort() is ok RaiseAbort(nullptr); }); // pthread is ok // pthread_t tid; // int ret = pthread_create(&tid, NULL, RaiseAbort, NULL); // if (ret != 0) { // fprintf(stderr, "create thread failed\n"); // return EXIT_FAILURE; // } [[NSRunLoop mainRunLoop] run]; return 0; } console log: signal handler has finished handle signal 6 begin sleep end sleep

I'm developing a safety-critical monitoring app that needs to fetch data from government APIs every 30 minutes and trigger emergency audio alerts for threshold violations. The app must work reliably in background since users depend on it for safety alerts even while sleeping. Main Challenge: iOS background limitations seem to prevent consistent 30-minute intervals. Standard BGTaskScheduler and timers get suspended after a few minutes in background. Question: What's the most reliable approach to ensure consistent 30-minute background monitoring for a safety-critical app where missed alerts could have serious consequences? Are there special entitlements or frameworks for emergency/safety applications? The app needs to function like an alarm clock - working reliably even when backgrounded with emergency audio override capabilities.

Hello, We're seeing some strange crashes and noticed the following. It's unclear if related or not. The contract for xpc_main, which internally calls dispatch_main, is This function never returns. and they are appropriately peppered with __attribute__((__noreturn__)). Documentation states: This function “parks” the main thread and waits for blocks to be submitted to the main queue. However, internally, dispatch_main calls pthread_exit. pthread_exit's documentation states that: After a thread has terminated, the result of access to local (auto) variables of the thread is undefined. Thus, references to local variables of the exiting thread should not be used for the pthread_exit() value_ptr parameter value. I'd say the two contracts of This function never returns. and thread exiting with its storage released are diametrically opposed and can create nuanced issues. Consider the following code: struct asd { int a; }; struct asd* ptr; void fff(void* ctx) { while(true) { printf("%d\n", ptr->a); ptr->a = (ptr->a + 1); usleep(100000); } } int main(int argc, const char * argv[]) { struct asd zxc; zxc.a = 1; ptr = &zxc; dispatch_async_f(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), NULL, fff); dispatch_main(); return 0; } This is a ***** over-simplification of the code we have, but in the same "spirit". We have a C++ object that is created on the stack and exposes one of its members as a global pointer, with the assumption that it would never release. What I understand from This function never returns is that the calling thread remains dormant and its stack remains alive. What I understand from pthread_exit is that the thread is killed (this is verified with a debugger attached) and its stack storage is released. Another thing that is throwing me off is that no sanitizer that is provided by clang/Xcode catches this issue. I don't see any special handling of the internal pthread_t in libdispatch to keep the stack storage alive. Our code is more complex, but can be solved by allocating the initial object on the heap, rather than on the stack. But still I would like to understand if this is the expected behavior. Perhaps my preconception of __attribute__((__noreturn__)) is wrong, and accessing stack variables post call to a __attribute__((__noreturn__)) function is UB? Thanks

Every time macOS goes to sleep the processes get suspended which is expected. But during the sleep period, all processes keep coming back and they all get a small execution window where they make some n/w requests. Regardless of what power settings i have. It also does not matter whether my app is a daemon or not Is there any way that i can disable this so that when system is in sleep, it stays in suspended, no intermittent execution window? I have tried disabling Wake for network access setting but processes still keep getting intermittent execution window. Is there any way that i can prevent my app from coming back while in sleep. I don't want my app to get execution window, perform some executions and then get suspended not knowing when it will get execution window again?

I have been experimenting with the BGContinuedProcessingTask API recently (and published sample code for it https://github.com/infinitepower18/BGContinuedProcessingTaskDemo) I have noticed that if I lock the phone, the code that runs as part of the task stops executing. My sample code simply updates the progress each second until it gets to 100, so it should be completed in 1 minute 40 seconds. However, after locking the phone and checking the lock screen a few seconds later the progress indicator was in the same position as before I locked it. If I leave the phone locked for several minutes and check the lock screen the live activity says "Task failed". I haven't seen anything in the documentation regarding execution of tasks while the phone is locked. So I'm a bit confused if I encountered an iOS bug here?

The application is placed into the idle state. Subsequently, the device enters a sleep state. While the device is in sleep, App start background task within the application successfully receives its expirationHandler callback. App received the expiration callback and App called the end BGtask OS did not released the Assertion. Resulting in App getting terminated by the OS for exceeding the BG task Apple Feedback- FB19192371