The support URL provided in App Store Connect must direct to a support page with links to a loan services privacy policy. The support page must also reference the lender or lending license. The privacy policy provided in App Store Connect must include references to the lender. The verified email domains associated with your Apple Developer Program account must match domains for the submitting company or partnered financial institution.

One challenging aspect of Swift concurrency is flow control, aka backpressure. I was explaining this to someone today and thought it better to post that explanation here, for the benefit of all. If you have questions or comments, start a new thread in App & System Services > Processes & Concurrency and tag with Swift and Concurrency. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Why is flow control important? In Swift concurrency you often want to model data flows using AsyncSequence. However, that’s not without its challenges. A key issue is flow control, aka backpressure. Imagine you have a network connection with a requests property that returns an AsyncSequence of Request values. The core of your networking code might be a loop like this: func processRequests(connection: Connection) async throws { for try await request in connection.requests { let response = responseForRequest(request) try await connection.reply(with: response) } } Flow control is important in both the inbound and outbound cases. Let’s start with the inbound case. If the remote peer is generating requests very quickly, the network is fast, and responseForRequest(_:) is slow, it’s easy to fall foul of unbounded memory growth. For example, if you use AsyncStream to implement the requests property, its default buffering policy is .unbounded. So the code receiving requests from the connection will continue to receive them, buffering them in the async stream, without any bound. In the worst case scenario that might run your process out of memory. In a more typical scenario it might result in a huge memory spike. The outbound case is similar. Imagine that the remote peer keeps sending requests but stops receiving them. If the reply(with:) method isn’t implemented correctly, this might also result in unbounded memory growth. The solution to this problem is flow control. This flow control operates independently on the send and receive side: On the send side, the code sending responses should notice that the network connection has asserted flow control and stop sending responses until that flow control lifts. In an async method, like the reply(with:) example shown above, it can simply not return until the network connection has space to accept the reply. On the receive side, the code receiving requests from the connection should monitor how many are buffered. If that gets too big, it should stop receiving. That causes the requests to pile up in the connection itself. If the network connection implements flow control properly [1], this will propagate to the remote peer, which should stop generating requests. [1] TCP and QUIC both implement flow control. Use them! If you’re tempted to implement your own protocol directly on top of UDP, consider how it should handle flow control. Flow control and Network framework Network framework has built-in support for flow control. On the send side, it uses a ‘push’ model. When you call send(content:contentContext:isComplete:completion:) the connection buffers the message. However, it only calls the completion handler when it’s passed that message to the network for transmission [2]. If you send a message and don’t receive this completion callback, it’s time to stop sending more messages. On the receive side, Network framework uses a ‘pull’ model. The receiver calls a receive method, like receiveMessage(completion:), which calls a completion handler when there’s a message available. If you’ve already buffered too many messages, just stop calling this receive method. These techniques are readily adaptable to Swift concurrency using Swift’s CheckedContinuation type. That works for both send and receive, but there’s a wrinkle. If you want to model receive as an AsyncSequence, you can’t use AsyncStream. That’s because AsyncStream doesn’t support flow control. So, you’ll need to come up with your own AsyncSequence implementation [3]. [2] Note that this doesn’t mean that the data has made it to the remote peer, or has even been sent on the wire. Rather, it says that Network framework has successfully passed the data to the transport protocol implementation, which is then responsible for getting it to the remote peer. [3] There’s been a lot of discussion on Swift Evolution about providing such an implementation but none of that has come to fruition yet. Specifically: The Swift Async Algorithms package provides AsyncChannel, but my understanding is that this is not yet ready for prime time. I believe that the SwiftNIO folks have their own infrastructure for this. They’re driving this effort to build such support into Swift Async Algorithms. Avoid the need for flow control In some cases you can change your design to avoid the need for control. Imagine that your UI needs to show the state of a remote button. The network connection sends you a message every time the button is depressed or released. However, your UI only cares about the current state. If you forward every messages from the network to your UI, you have to worried about flow control. To eliminate that worry: Have your networking code translate the message to reflect the current state. Use AsyncStream with a buffering policy of .bufferingNewest(1). That way there’s only ever one value in the stream and, if the UI code is slow for some reason, while it might miss some transitions, it always knows about the latest state. 2024-12-13 Added a link to the MultiProducerSingleConsumerChannel PR. 2024-12-10 First posted.

All the nuances of when and whether a background task runs aside, does launching the app cancel the currently scheduled refresh task? As an example, consider the following case: 8AM - user launches app. This launch schedules a background refresh for 12 hours later, at 8PM 12PM (noon) - user launches the app, views some content, then exits the app. Does the scheduled refresh for 8PM still exist, or does the launch at noon invalidate that task, since the refresh could conceivably be handled during that noon launch? Hopefully this is articulated clearly enough, but I'm trying to understand the specifics of background refresh behavior, since I don't want to run that refresh every time the app is opened. However, if opening the app invalidates scheduled refreshes, I will need to include logic that will reschedule the refresh accordingly.

I've written an app that uses On Idle (RunHandler) to prompt me to get up and stretch every 30 minutes. Is there anyway to query the running app to determine how long it's been since it last woke up and prompted me? Something like thru the apps properties by right clicking on the icon in the dock?

Hey, I have a user script that I have set up to run daily with launchd, the launchd logs indicate that the script is started but it's almost immediately exited with status 0. The odd thing is that it doesn't say that the script was killed or stopped in anyway, even though that is what seems to happen. 2024-12-04 14:15:04.970214 (gui/501/com.me.test) <Notice>: internal event: WILL_SPAWN, code = 0 2024-12-04 14:15:04.970320 (gui/501/com.me.test) <Notice>: service state: spawn scheduled 2024-12-04 14:15:04.970325 (gui/501/com.me.test) <Notice>: service state: spawning 2024-12-04 14:15:04.970431 (gui/501/com.me.test) <Notice>: launching: xpc event 2024-12-04 14:15:04.972067 (gui/501/com.me.test [26446]) <Notice>: xpcproxy spawned with pid 26446 2024-12-04 14:15:04.972096 (gui/501/com.me.test [26446]) <Notice>: internal event: SPAWNED, code = 0 2024-12-04 14:15:04.972107 (gui/501/com.me.test [26446]) <Notice>: service state: xpcproxy 2024-12-04 14:15:04.972160 (gui/501/com.me.test [26446]) <Notice>: internal event: SOURCE_ATTACH, code = 0 2024-12-04 14:15:04.998157 (gui/501/com.me.test [26446]) <Notice>: service state: running 2024-12-04 14:15:04.998180 (gui/501/com.me.test [26446]) <Notice>: internal event: INIT, code = 0 2024-12-04 14:15:04.998199 (gui/501/com.me.test [26446]) <Notice>: Successfully spawned shell_wrapper.sh[26446] because xpc event 2024-12-04 14:15:05.217482 (gui/501/com.me.test [26446]) <Notice>: exited due to exit(0), ran for 246ms 2024-12-04 14:15:05.217494 (gui/501/com.me.test [26446]) <Notice>: service state: exited 2024-12-04 14:15:05.217502 (gui/501/com.me.test [26446]) <Notice>: internal event: EXITED, code = 0 2024-12-04 14:15:05.217506 (gui/501 [100003]) <Notice>: service inactive: com.me.test 2024-12-04 14:15:05.217523 (gui/501/com.me.test [26446]) <Notice>: service state: not running In the script itself I log at the end to indicate that it finished successfully, when ran with launchd I never reach this point however. The script also do two network requests and make a pause for between 5-10 seconds with time.sleep(paus) (python script). However the launchd log indicates that the script finished in 246ms. Not sure what is going on, the script itself does not require any privileges above a normal user. I have tried running the script directly, and it works as expected. I have also tried evoking the script from launchd explicitly with: launchctl kickstart which starts the job but gives the same result as the scheduled job, except the log now says: `launching: non-ipc demand' instead. I have also tried to remove the networking requests and replace them by reading data from a file without any sleep, no difference in outcome though. I have generated the launchd plist file using Lingon.app and it's placed in ~/Library/LaunchAgents Not sure what more information I can provide, but need some suggestion on how I can proceed help solving this.

I’ve been experimenting with Dispatch, and workloops in particular. I gather that they’re similar to serial queues, except that they reorder work items by QoS. I suspect there’s more to workloops than meets the eye, though; calling dispatch_set_target_queue on them has no effect, in spite of the <dispatch/workloop.h> saying that workloops “can be passed to all APIs accepting a dispatch queue, except for functions from the dispatch_sync() family”. Workloops keep showing up in odd places like Metal and Network.framework backtraces, and <dispatch/workloop.h> includes functionality for tying workloops to os_workgroups (?!). What exactly is a workloop beyond just a serial queue with priority ordering, and why can’t I set the target queue of one?

I have an app, that when enters the background schedules a task to run. The earliest possible time value is set, as is the completion handler when the task eventually runs. It seems to run pretty reliably for the 1st few interations and then (from looking at the streaming Console logs), doesn't seem to reach a high CP score to execute next time around. eg '......background.task:EDBC23' CurrentScore: 0.648418, ThresholdScore: 0.808034 DecisionToRun:0 looking at the previous entries before this, I can see the breakdown... {name: Application Policy, policyWeight: 50.000, response: {0, 0.35}} {name: Device Activity Policy, policyWeight: 5.000, response: {0, 0.50}} ], Decision: CP Score: 0.648418} and I understand certain elements are outside of our control; however, is there a preferred method to get a background task (which ultimately runs an API call) to trigger consistently? The silent-push method has come up a few times - but of course, if the user disables / doesn't consent to push notifications, that fails Any suggestions?

I'm looking into a newer XPC API available starting with macOS 14. Although it's declared as a low-level API I can't figure it how to specify code signing requirement using XPCListener and XPCSession. How do I connect it with xpc_listener_set_peer_code_signing_requirement and xpc_connection_set_peer_code_signing_requirement which require xpc_listener_t and xpc_connection_t respectively? Foundation XPC is declared as a high-level API and provides easy ways to specify code signing requirements on both ends of xpc. I'm confused with all these XPC APIs and their future: Newer really high-level XPCListener and XPCSession API (in low-level framework???) Low-level xpc_listener_t & xpc_connection_t -like API. Is it being replaced by newer XPCListener and XPCSession? How is it related to High-level Foundation XPC? Are NSXPCListener and NSXPCConnection going to be deprecated and replaced by XPCListener and XPCSession??

I need to check how long we can run an app in background which act as a consumer of data / control filter. What is the max time we get to run our app in background without any of these app strategies? https://developer.apple.com/documentation/backgroundtasks/choosing-background-strategies-for-your-app

I am encountering an issue when making an API call using URLSession with DispatchQueue.global(qos: .background).async on a real device running tvOS 18. The code works as expected on tvOS 17 and in the simulator for tvOS 18, but when I remove the debug mode, After the API call it takes few mintues or 5 to 10 min to load the data on the real device. Code: Here’s the code I am using for the API call: appconfig.getFeedURLData(feedUrl: feedUrl, timeOut: kRequestTimeOut, apiMethod: ApiMethod.POST.rawValue) { (result) in self.EpisodeItems = Utilities.sharedInstance.getEpisodeArray(data: result) } func getFeedURLData(feedUrl: String, timeOut: Int, apiMethod: String, completion: @escaping (_ result: Data?) -> ()) { guard let validUrl = URL(string: feedUrl) else { return } var request = URLRequest(url: validUrl, cachePolicy: .useProtocolCachePolicy, timeoutInterval: TimeInterval(timeOut)) let userPasswordString = "\(KappSecret):\(KappPassword)" let userPasswordData = userPasswordString.data(using: .utf8) let base64EncodedCredential = userPasswordData!.base64EncodedString(options: .lineLength64Characters) let authString = "Basic \(base64EncodedCredential)" let headers = [ "authorization": authString, "cache-control": "no-cache", "user-agent": "TN-CTV-\(kPlateForm)-\(kAppVersion)" ] request.addValue("application/json", forHTTPHeaderField: "Content-Type") request.httpMethod = apiMethod request.allHTTPHeaderFields = headers let response = URLSession.requestSynchronousData(request as URLRequest) if response.1 != nil { do { guard let parsedData = try JSONSerialization.jsonObject(with: response.1!, options: .mutableContainers) as? AnyObject else { print("Error parsing data") completion(nil) return } print(parsedData) completion(response.1) return } catch let error { print("Error: \(error.localizedDescription)") completion(response.1) return } } completion(response.1) } import Foundation public extension URLSession { public static func requestSynchronousData(_ request: URLRequest) -> (URLResponse?, Data?) { var data: Data? = nil var responseData: URLResponse? = nil let semaphore = DispatchSemaphore(value: 0) let task = URLSession.shared.dataTask(with: request) { taskData, response, error in data = taskData responseData = response if data == nil, let error = error { print(error) } semaphore.signal() } task.resume() _ = semaphore.wait(timeout: .distantFuture) return (responseData, data) } public static func requestSynchronousDataWithURLString(_ requestString: String) -> (URLResponse?, Data?) { guard let url = URL(string: requestString.checkValidUrl()) else { return (nil, nil) } let request = URLRequest(url: url) return URLSession.requestSynchronousData(request) } } Issue Description: Working scenario: The API call works fine on tvOS 17 and in the simulator for tvOS 18. Problem: When running on a real device with tvOS 18, the API call takes time[enter image description here] when debug mode is disabled, but works fine when debug mode is enabled, Data is loading after few minutes. Error message: Error Domain=WKErrorDomain Code=11 "Timed out while loading attributed string content" UserInfo={NSLocalizedDescription=Timed out while loading attributed string content} NSURLConnection finished with error - code -1001 nw_read_request_report [C4] Receive failed with error "Socket is not connected" Snapshot request 0x30089b3c0 complete with error: <NSError: 0x3009373f0; domain: BSActionErrorDomain; code: 1 ("response-not-possible")> tcp_input [C7.1.1.1:3] flags=[R] seq=817957096, ack=0, win=0 state=CLOSE_WAIT rcv_nxt=817957096, snd_una=275546887 Environment: Xcode version: 16.1 Real device: Model A1625 (32GB) tvOS version: 18.1 Debugging steps I’ve taken: I’ve verified that the issue does not occur in debug mode. I’ve confirmed that the API call works fine on tvOS 17 and in the simulator (tvOS 18). The error suggests a network timeout (-1001) and a socket connection issue ("Socket is not connected"). Questions: Is this a known issue with tvOS 18 on real devices? Are there any specific settings or configurations in tvOS 18 that could be causing the timeout error in non-debug mode? Could this be related to how URLSession or networking behaves differently in release mode? I would appreciate any help or insights into this issue!

Hi, we are in the process of exploring how to create an installer for our array of apps. We have come to the conclusion that regular .pkg installers produced by pkgbuild and productbuild are unfulfilling of our expectations. [1] Regardless, our installer needs to place files at privileged locations (/Library/Application Support) so we are looking into how to best solve this problem, with the user having the largest clarity on what they are about to do (so no shady "wants to make changes" dialogs) the least steps to do to install these files in the right place (so no targeted NSSavePanel-s) Now, we have done our light reading via some nicely collected posts on the topic (https://forums.developer.apple.com/forums/thread/708765 for example) and the single missing option in the list of privilege escalation models seems to be a one-time privilege escalation from a GUI app. Our reasons for declaring so: AuthorizationExecuteWithPrivileges is long deprecated and we are trying to build a futureproof solution NSAppleScript is just putting up a shady ("wants to make changes") dialog when trying something like this: $ osascript -e "set filePath to \"/Library/Application Support\"" -e "do shell script \"touch \" & the quoted form of filePath & \"/yyy.txt\" with administrator privileges" Is there another way to request a one-time authorization from the admin to perform such a simple operation as copying a file to a protected location? I know it's possible to externalize and internalize Authorization Rights, but they are just an interface to create extra rights and use them as barriers, because they don't actually pass the required right to further operations based on this documentation. Using SMAppService to register a daemon, which has to be manually allowed by the user adds a lot to the complexity of this installation process, and is something we would like to avoid if possible. (And it's also not the right security model if we want to be honest - we don't want ongoing administrator rights and a daemon) Is there something we haven't taken into consideration? [1] preinstall scripts run after the choices are presented during installation and we would need advanced logic (not the limited JavaScript system/files API provided by Installer JS) - plus, the GUI is obviously very limited in a .pkg :(

I have a process [command line cpp application] which i want to run always such as it should relaunch after a crash, after device startup etc. I created a launchd Property List File with KeepAlive true and placed under /Library/LaunchDaemons. Problem Statements: I have a bash script to start and stop this process. start using: launchctl bootstrap. stop involve these two steps: send SIGTERM signal and wait untill process stops after doing some cleanups launchctl bootout [It doesn't sends SIGTERM] during steps 1 - Process is getting stop, but also getting immediate relaunch by launchctl during step 2 - it getting stop again. is there a proper way so that we can disable KeepAlive temporarily so that process will not launch during step 1? or suggest other ways to handle this?

Hello everyone! I'm having a problem with background tasks running in the foreground. When a user enters the app, a background task is triggered. I've written some code to check if the app is in the foreground and to prevent the task from running, but it doesn't always work. Sometimes the task runs in the background as expected, but other times it runs in the foreground, as I mentioned earlier. Could it be that I'm doing something wrong? Any suggestions would be appreciated. here is code: class BackgroundTaskService { @Environment(\.scenePhase) var scenePhase static let shared = BackgroundTaskService() private init() {} // MARK: - create task func createCheckTask() { let identifier = TaskIdentifier.check BGTaskScheduler.shared.getPendingTaskRequests { requests in if requests.contains(where: { $0.identifier == identifier.rawValue }) { return } self.createByInterval(identifier: identifier.rawValue, interval: identifier.interval) } } private func createByInterval(identifier: String, interval: TimeInterval) { let request = BGProcessingTaskRequest(identifier: identifier) request.earliestBeginDate = Date(timeIntervalSinceNow: interval) scheduleTask(request: request) } // MARK: submit task private func scheduleTask(request: BGProcessingTaskRequest) { do { try BGTaskScheduler.shared.submit(request) } catch { // some actions with error } } // MARK: background actions func checkTask(task: BGProcessingTask) { let today = Calendar.current.startOfDay(for: Date()) let lastExecutionDate = UserDefaults.standard.object(forKey: "lastCheckExecutionDate") as? Date ?? Date.distantPast let notRunnedToday = !Calendar.current.isDate(today, inSameDayAs: lastExecutionDate) guard notRunnedToday else { task.setTaskCompleted(success: true) createCheckTask() return } if scenePhase == .background { TaskActionStore.shared.getAction(for: task.identifier)?() } task.setTaskCompleted(success: true) UserDefaults.standard.set(today, forKey: "lastCheckExecutionDate") createCheckTask() } } And in AppDelegate: BGTaskScheduler.shared.register(forTaskWithIdentifier: "check", using: nil) { task in guard let task = task as? BGProcessingTask else { return } BackgroundTaskService.shared.checkNodeTask(task: task) } BackgroundTaskService.shared.createCheckTask()

I was experimenting with Service Management API and Xcode project from https://developer.apple.com/documentation/servicemanagement/updating-your-app-package-installer-to-use-the-new-service-management-api and faced some issues with the API. I replaced agent with XPC service and tried to re-register it. Use case is a new app package installation with a newer service binary. In order to get the running service restarted with the new binary it's required to unregister old version and register new one. Otherwise the old version would be still running after app upgrade. The problem is that register fails with "Operation not permitted" error after running unregister which seems to work fine. Experiments with some delays (500ms) between unregister and register seem to help but it's a not a good solution to work around the problem. I'm using open func unregister() async throws with description: The completion handler will be invoked after the running process has been killed if successful or will be invoked whenever an error occurs. After the completion handler has been invoked it is safe to re-register the service. Sample output with no 500ms sleep between unregister and register calls: /Library/Application\ Support/YourDeveloperName/SMAppServiceSampleCode.app/Contents/MacOS/SMAppServiceSampleCode unregister &amp;&amp; /Library/Application\ Support/YourDeveloperName/SMAppServiceSampleCode.app/Contents/MacOS/SMAppServiceSampleCode register Successfully unregistered LaunchDaemon(com.xpc.example.service.plist) Unable to register LaunchDaemon(com.xpc.example.service.plist): Error Domain=SMAppServiceErrorDomain Code=1 "Operation not permitted" UserInfo={NSLocalizedFailureReason=Operation not permitted} In fact it doesn't seem to be safe to re-register. Any explanation would much appreciated! ===================================================== Side issue #2: I tried to add a similar helper executable as in the original project with register/unregister and put it inside the same app bundle but at a different location like Contents/Helpers/ folder instead of Contents/MacOS. And it always fails with this error: Error Domain=SMAppServiceErrorDomain Code=3 "Codesigning failure loading plist: com.okta.service.osquery code: -67028" UserInfo={NSLocalizedFailureReason=Codesigning failure loading plist: com.okta.service.osquery code: -67028} When I moved the helper binary to Contents/MacOS/ folder along with the main app executable it starts working fine again. Other folders like Resources/XPCServices also don't work. Is it a hard requirement for an executable to be located inside main Contents/MacOS folder in order to be able to call SMAppService register/unregister APIs? I haven't found any documentation regarding this requirement. Thanks, Pavel

When using conformance to ObservableObject and then doing async work in a Task, you will get a warning courtesy of Combine if you then update an @Published or @State var from anywhere but the main thread. However, if you are using @Observable there is no such warning. Also, Thread.current is unavailable in asynchronous contexts, so says the warning. And I have read that in a sense you simply aren't concerned with what thread an async task is on. So for me, that begs a question. Is the lack of a warning, which when using Combine is rather important as ignoring it could lead to crashes, a pretty major bug that Apple seemingly should have addressed long ago? Or is it just not an issue to update state from another thread, because Xcode is doing that work for us behind the scenes too, just as it manages what thread the async task is running on when we don't specify? I see a lot of posts about this from around the initial release of Async/Await talking about using await MainActor.run {} at the point the state variable is updated, usually also complaining about the lack of a warning. But ow years later there is still no warning and I have to wonder if this is actually a non issue. On some ways similar to the fact that many of the early posts I have seen related to @Observable have examples of an @Observable ViewModel instantiated in the view as an @State variable, but in fact this is not needed as that is addressed behind the scenes for all properties of an @Observable type. At least, that is my understanding now, but I am learning Swift coming from a PowerShell background so I question my understanding a lot.

I updated my computer to Sonoma, and now my LaunchDaemon will not load. I have the following setup : File in /Library/LaunchDaemons/com.startup.plist like this : <?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.startup</string> <key>ProgramArguments</key> <array> <string>/usr/local/bin/bash</string> <string>/Library/Scripts/Startup/startup.sh</string> </array> <key>RunAtLoad</key> <true/> <key>StandardErrorPath</key> <string>/tmp/com.startup.stderr</string> <key>StandardOutPath</key> <string>/tmp/com.startup.stdout</string> </dict> </plist> File in File in /Library/Scripts/Startup/startup.sh #!/bin/zsh PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users:/Users/root:/Users/root/Scripts:/Library/Scripts:/Library/Scripts/Startup #Load modules for Fuse /Library/Filesystems/macfuse.fs/Contents/Resources/load_macfuse /usr/sbin/sysctl -w vfs.generic.macfuse.tunables.allow_other=1 #Connect to XXXXXX_net /bin/sleep 28 myip=0 while [ $myip = 0 ] do /bin/sleep 3 myip=$(ifconfig -l | xargs -n1 ipconfig getifaddr) done /usr/local/bin/sshfs XXXX@XXXXXX.net: /Volumes/XXXXXX.net -o local,auto_cache,reconnect,ServerAliveInterval=15,ServerAliveCountMax=3,ConnectTimeout=5,daemon_timeout=60,iosize=2097152,volname=XXXXXX.net,allow_other,defer_permissions,async_read,Ciphers=aes128-gcm@openssh.com,Cipher=aes128-gcm@openssh.com,compression=no And then we need some commands to be run as root user during boot : /private/etc/sudoers.d/startup-script-nopasswd username ALL = (root) NOPASSWD: /usr/sbin/sysctl username ALL = (root) NOPASSWD: /usr/local/bin/sshfs As of now, I cant even get the /Library/LaunchDaemons/com.startup.plist to run after i updated the macOS to Sonoma ….

Hi, I want to create a custom application launcher, so I'd like the app to be able to just list the apps installed and launch them when touched. My idea is to have a Minimalist UI in order to enhance productivity. Is it possible? I see there is already one App doing it https://apps.apple.com/us/app/dumb-phone/id6504743503 I want to do something similar, so how does the App in the link obtains the Apps installed on the device?

I created a macOS app, added an XPC service target, and also added a source editor extension. in The source editor extension‘s perform function. It doesn't work - (void)performCommandWithInvocation:(XCSourceEditorCommandInvocation *)invocation completionHandler:(void (^)(NSError * _Nullable nilOrError))completionHandler { self.xpcConnect = [[NSXPCConnection alloc] initWithServiceName:@"test.TestNewXPCApp.NewXPC"]; NSXPCInterface *interface = [NSXPCInterface interfaceWithProtocol:@protocol(NewXPCProtocol)]; self.xpcConnect.remoteObjectInterface = interface; [self.xpcConnect resume]; [[self.xpcConnect remoteObjectProxy] performCalculationWithNumber:@231 andNumber:@119 withReply:^(NSNumber *reply) { // We have received a response. NSLog(@"ui success%@", reply); }]; But In ViewControler.m, executing the same code , it can work. So why is it possible to connect to the XPC service from within the macOS app, but not from the source editor extension?

Let's say I queue some tasks on DispatchQueue.global() and then switch to another app or locking screen for a while. The app was not terminated but stayed in the background. Is there a chance that some tasks queued but not yet start could be discarded, even if the app hasn’t been terminated, after switching to another app or locking the screen for a while?

我这边用了几台机器升级iOS 18.1并没有测试出来问题，但是审核员测试出来了问题，并将崩溃报告发给了我。 以下是审核员发给我的的测试环境及崩溃报告： Device type: iPad Air (5th generation) OS version: iOS 18.1 崩溃报告如下： Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0 Crashed: 0 libobjc.A.dylib 0x196ae7c38 objc_msgSend + 56 1 UIKitCore 0x19bf9c0f4 -[UIView bounds] + 32 2 UIKitCore 0x19c14e15c -[UIScrollView _didEndDirectManipulationWithScrubbingDirection:] + 108 3 UIKitCore 0x19d4cd3e8 -[UIScrollView _stopScrollingNotify:pin:tramplingAnimationDependentFlags:] + 108 4 UIKitCore 0x19d4cd548 -[UIScrollView _stopScrollingAndZoomingAnimationsPinningToContentViewport:tramplingAnimationDependentFlags:] + 52 5 UIKitCore 0x19c385a28 -[UIScrollView dealloc] + 88 6 libsystem_blocks.dylib 0x221c29860 bool HelperBase::disposeCapture<(HelperBase::BlockCaptureKind)3>(unsigned int, unsigned char*) + 68 7 libsystem_blocks.dylib 0x221c29570 HelperBase::destroyBlock(Block_layout*, bool, unsigned char*) + 160 8 libsystem_blocks.dylib 0x221c29030 _call_dispose_helpers_excp + 72 9 libsystem_blocks.dylib 0x221c28fcc _Block_release + 256 10 libdispatch.dylib 0x1a14fe0d0 _dispatch_client_callout + 20 11 libdispatch.dylib 0x1a150c9e0 _dispatch_main_queue_drain + 980 12 libdispatch.dylib 0x1a150c5fc _dispatch_main_queue_callback_4CF + 44 13 CoreFoundation 0x1997fc204 CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE + 16 14 CoreFoundation 0x1997f9440 __CFRunLoopRun + 1996 15 CoreFoundation 0x1997f8830 CFRunLoopRunSpecific + 588 16 GraphicsServices 0x1e57d81c4 GSEventRunModal + 164 17 UIKitCore 0x19c35eeb0 -[UIApplication _run] + 816 18 UIKitCore 0x19c40d5b4 UIApplicationMain + 340 19 BXT 0x104d90090 0x104aa4000 + 3063952 20 dyld 0x1bf1e6ec8 start + 2724 Thread 1: 0 libsystem_pthread.dylib 0x221c2c480 start_wqthread + 0 Thread 2: 0 libsystem_pthread.dylib 0x221c2c480 start_wqthread + 0 Thread 3: 0 libsystem_pthread.dylib 0x221c2c480 start_wqthread + 0 Thread 4 name: com.apple.uikit.eventfetch-thread Thread 4: 0 libsystem_kernel.dylib 0x1e9bba688 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x1e9bbdd98 mach_msg2_internal + 80 2 libsystem_kernel.dylib 0x1e9bbdcb0 mach_msg_overwrite + 424 3 libsystem_kernel.dylib 0x1e9bbdafc mach_msg + 24 4 CoreFoundation 0x1997f9a84 __CFRunLoopServiceMachPort + 160 5 CoreFoundation 0x1997f9130 __CFRunLoopRun + 1212 6 CoreFoundation 0x1997f8830 CFRunLoopRunSpecific + 588 7 Foundation 0x1984a0500 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212 8 Foundation 0x1984a0350 -[NSRunLoop(NSRunLoop) runUntilDate:] + 64 9 UIKitCore 0x19c372358 -[UIEventFetcher threadMain] + 420 10 Foundation 0x1984b16c8 NSThread__start + 724 11 libsystem_pthread.dylib 0x221c3137c _pthread_start + 136 12 libsystem_pthread.dylib 0x221c2c494 thread_start + 8 Thread 5: 0 libsystem_pthread.dylib 0x221c2c480 start_wqthread + 0 Thread 6: 0 libsystem_pthread.dylib 0x221c2c480 start_wqthread + 0 Thread 7: 0 libsystem_pthread.dylib 0x221c2c480 start_wqthread + 0 Thread 8: 0 libsystem_pthread.dylib 0x221c2c480 start_wqthread + 0 Thread 9: 0 libsystem_pthread.dylib 0x221c2c480 start_wqthread + 0 Thread 10 name: JavaScriptCore libpas scavenger Thread 10: 0 libsystem_kernel.dylib 0x1e9bbff90 __psynch_cvwait + 8 1 libsystem_pthread.dylib 0x221c2ea50 _pthread_cond_wait + 1204 2 JavaScriptCore 0x1b156aca4 scavenger_thread_main + 1512 3 libsystem_pthread.dylib 0x221c3137c _pthread_start + 136 4 libsystem_pthread.dylib 0x221c2c494 thread_start + 8 Thread 11 name: WebThread Thread 11: 0 libsystem_kernel.dylib 0x1e9bba688 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x1e9bbdd98 mach_msg2_internal + 80 2 libsystem_kernel.dylib 0x1e9bbdcb0 mach_msg_overwrite + 424 3 libsystem_kernel.dylib 0x1e9bbdafc mach_msg + 24 4 CoreFoundation 0x1997f9a84 __CFRunLoopServiceMachPort + 160 5 CoreFoundation 0x1997f9130 __CFRunLoopRun + 1212 6 CoreFoundation 0x1997f8830 CFRunLoopRunSpecific + 588 7 WebCore 0x1ad46bb18 RunWebThread(void*) + 780 8 libsystem_pthread.dylib 0x221c3137c _pthread_start + 136 9 libsystem_pthread.dylib 0x221c2c494 thread_start + 8 Thread 0 crashed with ARM Thread State (64-bit): x0: 0x00000003029b1840 x1: 0x0000000208981838 x2: 0x0000000000000000 x3: 0x0000000000000000 x4: 0x0000000000000001 x5: 0x00000f0300000000 x6: 0x0000000000000002 x7: 0x0000000000000000 x8: 0x00000000000000a0 x9: 0x0000000208981838 x10: 0x00000000024b036c x11: 0x00000000024b036c x12: 0x0000000000000000 x13: 0x00000000024b036c x14: 0x00000003029b1bc0 x15: 0x00000003029b1bc0 x16: 0x00000003029b1bc0 x17: 0x0000000205f46018 x18: 0x0000000000000000 x19: 0x0000000136841400 x20: 0x00000001fd5f4588 x21: 0xffffffffffffffff x22: 0x00000000000006d8 x23: 0x0000000136841ad8 x24: 0x0000000000000000 x25: 0x00000001fd5969e0 x26: 0x00000003032b7640 x27: 0x000000000000000f x28: 0x0000000000000000 fp: 0x000000016b35a4e0 lr: 0x000000019bf9c0f4 sp: 0x000000016b35a4e0 pc: 0x0000000196ae7c38 cpsr: 0x20001000 far: 0x00000000024b036c esr: 0x92000006 (Data Abort) byte read Translation fault