Thank you for the response. About this: Having said that, this isn’t something I recommend. As I explained in your other thread, your overall approach contains significant drawbacks today, and it wouldn’t surprise me if that situation got worse in the future [2]. You are ‘fighting the framework’ [3] here, and that’s not a good idea in general. We plan to have 1-2 light-weight Frameworks in total. And the idea is, the Framework is loaded explicitly, and never unloaded, as we leave it to the OS. Do the drawbacks of dynamically loading the Framework at runtime i.e., slower launch times, apply if we have 1 or 2 light-weight Frameworks?

Taking a step back, your recent threads exhibit a strong desire to make Apple platforms look like the other platforms you support. I understand why you want to do that, but such efforts have to be balance. Eventually you need to recognise that there are differences between platforms, and your attempts to bend one platform to look like another is more trouble than its worth. We're dealing with a number of dimensions of diversity, with platforms/OSes being one. At this point, we're exploring and trying to make things as consistent as possible (so there might be more questions from this point of view), for easy maintainability. But I understand your point about consistency not at the cost of 'bending the platform/framework' and these things should be balanced. This helps us decide where to pursue consistency. Thank you for these responses, it helps :).

Attempted to change the extension and load the Framework module, with custom extension name - .abc, at runtime and load-time using the following steps: To generate the framework with the .abc extension, Framework target -> Build Settings -> Packaging -> Wrapper Extension property is set to abc in Xcode. Then for, Explicit loading In the path to dlopen, replace .framework extension with custom name - .abc. Implicit linking In Framework target, named F2 (in this example), Build Settings -> Linking-General, change set LD_DYLIB_INSTALL_NAME = @rpath/F2.abc/F2 In the parent target (App target) ensure that F2 is removed from Build Phases -> Link Binary With Libraries. This setting generates -framework F2 linker flag and needs to be removed. As long as this flag is present, build system always looks for .framework extension. In the parent target, in Build Settings -> Linking - General -> other linker flags, add $(BUILT_PRODUCTS_DIR)/F2.abc/F2 This setup works, though I couldn't confirm its validity in Apple documentation. But here are other references from Apple documentation which specifically talks about how the system identifies .framework extension: Quoting from CFBundleExecutable documentation: For frameworks, the value of this key is required to be the same as the framework name, minus the .framework extension. Quoting from Framework anatomy documentation: The system identifies a framework by the .framework extension on its directory name Can we change the extension of the Framework target (as shown above) to a custom name?

@DTS Engineer I see folks avoid load-time imports because of initialisation order issues, and that’s especially true of folks coming from other platforms I'm working on a cross-platform project and there is a dynamic library. In all other OSes, the dynamic library is loaded at runtime and to ensure consistency, wanted to use the same approach for Apple OSes. Further, if the Posix C APIs such as dlopen and dlsym are used, Apple OSes can directly use the same code as Linux, resulting in good simplification. The Framework will be a dependency for the App target (but not linked), signed, embedded in the .app package and all the extension targets (such as Notification Service Extension, Widget extension etc.) will also load it at runtime. But one concern is, to use dlopen and dlsym, the path to the internal MachO binary is required, whereas .so file is used for Linux. Not able to find this documented or attempted, so the question is: Can we use the Posix C APIs such as dlload and dlsym to load MachO binary (inside Framework) in C++ (instead of swift), for all the Apple OSes (macOS, iOS, tvOS etc.) at runtime?

Question to @DTS Engineer : let handle = dlopen(path, RTLD_NOW) let sym = dlsym(handle, "EntryPoint") dlopen[1] and dlsym[2] are Linux-specific C APIs (manpage documentation attached). How are they invoked in Swift directly? Please share some documentation for my understanding... I couldn't find any swift documentation about these symbols. [1]: dlopen - https://man7.org/linux/man-pages/man3/dlopen.3.html [2]: dlsym - https://man7.org/linux/man-pages/man3/dlsym.3.html

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.

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.

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?

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?

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.

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?

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.

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

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? :(

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 }) }