Update1: Correcting a typo New: Example: The sample background task is to count 60s in multiple of 10s. Old: Example: The sample background task is to count 10s in multiple of 10s.

Update 2: Missed to add some details and another question :( Expiration handler doesn't get called (unlike the case with beginBackgroundTask(name:expirationHandler:))? Environment: Xcode 14.2, iOS 16.0, Debug and Release build, Console app (to check logs).

After reading this post in swift forums about #if, @available and #available, I see that in this case, #if must be used... since any version of tvOS should not see the userNotificationCenter(_:didReceive:withCompletionHandler:) delegate method.

I raised a TSI to AppleDTS and they informed me that the scene(_ :continue:) method is for a UIKit app. For SwiftUI app, we have to use the onOpenURL(_:perform:) view modifier to handle universal links (and other URL based launches like file launch, deep link etc.) as shown below. WindowGroup { ContentView() .onOpenURL(perform: { (universalLink: URL) in Log(String(format: "universalLink = %@", universalLink.absoluteString)) // Handle universal link }) }

I followed all the instructions, downloaded the sysdiagnose thing... it's a watchOSconfig.mobileconfig file. I installed the profile on AppleWatch and I still didn't get any logs on Console App. But I do get logs on Xcode console when I run the app from Xcode, but I don't want to attach debugger. My env: watchOS 10.0, iOs 17.3.1, Xcode 15.1. Any ideas? :(

Same problem here. There are some alternates like this, but I'd like to capture the actual event (if it exists).

You say the iteration is part of the initialization process, hence its a one time operation, why therefore cannot it be performed by the app (I use the term app to not include the extension) the first time the app runs, and then the results of that made available to the extension? I've not thought about it until now... since I didn't know extensions will fail like this. Also an extension doesn't simply run for 30 seconds, it will run until the completion handler is called, if the handler is not called within 30 seconds then the system will call the handler for you. If you have to do the iteration within the extension, you will need to delay calling the completion handler until the iterations have completed. I am delaying the invocation of completion handler until the iterations are completed. In the app, these 65k iterations take 2 sec. In the extension, after 38k interactions (roughly), the process is killed... and the default notification is displayed as is. This does not take the whole 30 sec... after 1 or 2 sec, process is killed. So, I'm not hitting the time limit. The extension has a set memory limit, which is much less than that of an app. The 2D array is static. So, memory usage shouldn't spike suddenly. But CPU usage will spike when the iterations begin. So, is there similar restriction on CPU usage? Are all these restrictions, whether its CPU or memory or any other system resource consumption, documented somewhere? I'd like to know the boundaries when rethinking initialise step.

As you said, even after arriving at zero at runtime, the result is still 0 and the flow 'walks over' that instruction. However, that doesn’t generate SIGFPE because to get that you have to enable such trapping on the CPU. Instead it generates a result of 0. Is this something I'm supposed to be doing? If not, then, how to catch division by zero? What is the expectation?

This will start working when you implement application(_:configurationForConnecting:options:) in the AppDelegate and return a UISceneConfiguration with the same name as the one mentioned in the info.plist file. According to documentation, the SceneDelegate should get set without implementing application(_:configurationForConnecting:options:), but Idk why, SceneDelegate doesn't get set without the implementing application(_:configurationForConnecting:) in addition to specifying in the info.plist file. If you don’t implement this method, you must provide scene-configuration data in your app’s Info.plist file.

Thank you for the response. I tried editing this /etc/nsmb.conf file by putting some default response timeout but the same timeout is observed. Is there any other way to set the timeout for obtaining these durable handles for macOS? Or is there a way to obtain a non-durable handle?

First off, as a quick confirmation, do you see this behavior when you’re using another Mac as the SMB server? I don't think you will, but that's worth confirming. Even with a different Mac running as a server, 10 min timeout was observed. I think passing "O_EVTONLY" into open would work; however, I'm not sure that's really usable for I/O. O_EVENTONLY is only used for watching files like file modification, file renamed, deleted etc. It can't be used in this context. Note that the other option here would also be to pass in O_NONBLOCK and shift to non-blocking I/O. I'm currently using blocking I/O. Shifting to non-blocking I/O is the only way for faster timeouts?

Bug number: FB20072274 Title: (SMB Disconnect Causes macOS Disk I/O Call open () to Hang for 10 Minutes). I don't think the system will prevent you from reading or writing to a file that's been opened with O_EVENTONLY (assuming you pass in the necessary option). The main risk is exactly what you'd expect, namely that it won't prevent unmount, which could risk data loss. I tried that. The I/O does happen even with the O_EVENTONLY flag, but it still doesn't solve the timeout problem. I think that's the only option if you're specifically using the pattern of opening the file handle and performing I/O to it over time. In addition to reading whole file, I have a use case to read stream of data and not the entire file at once.

Thanks for the response, @DTS Engineer, Quinn. Additional context: We are working on a cross-platform application that is primarily written in C++ (missed to mention this in the first line of the post). There isn’t a supported way to block the main thread of a GUI application for long periods of time. On macOS it will SPOD, which is a terrible user experience. On other platforms the app will likely end up being killed by the watchdog. I understand that, in macOS, holding the main thread prevents it from picking up user events, thus, causing the SPOD experience (which is bad). In iOS, the process itself is terminated after 5 sec (please correct if not true). That's why the choice was to hold the main thread on a timed-wait interface instead of indefinite wait, which leads to SPOD, app termination etc. Basically, we don't intend to block the main thread for long periods of time. The duration of the timer is expected to be in milliseconds. Main thread is never expected to timeout. So, it should be fine to hold the main thread on a timed-wait? For some microseconds (in the worst case, handful of milliseconds), main thread won't be available for UI events. Please let us know of the consequences of this choice. I mean, is it against the AppStore policy or something else we don't know? PS: We intend to use this design of very brief timed-wait of main thread on other platforms (Android, Windows etc.) as well and there are no problems so far.