Hello, I have a Cocoa application from which I fork a new process (helper sort of) and it crashes on fork due to some cleanup code probably registered with pthreads_atfork() in Network framework. This is crash from the child process: Application Specific Information: *** multi-threaded process forked *** BUG IN CLIENT OF LIBPLATFORM: os_unfair_lock is corrupt Abort Cause 258 crashed on child side of fork pre-exec Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_platform.dylib 0x194551238 _os_unfair_lock_corruption_abort + 88 1 libsystem_platform.dylib 0x19454c788 _os_unfair_lock_lock_slow + 332 2 Network 0x19b1b4af0 nw_path_shared_necp_fd + 124 3 Network 0x19b1b4698 -[NWConcrete_nw_path_evaluator dealloc] + 72 4 Network 0x19af9d970 __nw_dictionary_dispose_block_invoke + 32 5 libxpc.dylib 0x194260210 _xpc_dictionary_apply_apply + 68 6 libxpc.dylib 0x19425c9a0 _xpc_dictionary_apply_node_f + 156 7 libxpc.dylib 0x1942600e8 xpc_dictionary_apply + 136 8 Network 0x19acd5210 -[OS_nw_dictionary dealloc] + 112 9 Network 0x19b1beb08 nw_path_release_globals + 120 10 Network 0x19b3d4fa0 nw_settings_child_has_forked() + 312 11 libsystem_pthread.dylib 0x100c8f7c8 _pthread_atfork_child_handlers + 76 12 libsystem_c.dylib 0x1943d9944 fork + 112 (...) I'm trying to create a child process with boost::process::child which does basically just a fork() followed by execv() and I do it before the - [NSApplication run] is called. Is it know bug or behavior which I've run into? Also what is a correct way to spawn child processes in Cocoa applications? As far as my understanding goes the basically all the available APIs (e.g. posix, NSTask) should be more or less the same thing calling the same syscalls. So forking the process early before main run loop starts and not starting another NSApplication in forked child should be ok ...or not?

Trying to get some minimum development working again, I've been waiting to be able to macOS in VMs on M1. Currently both VirtualBuddy, and UTM, can install macOS, I can go to Recovery Boot to disable SIP and enable 3rd party extensions. My M1 runs: ProductVersion: 13.0 BuildVersion: 22A5331f I've tested VM macOS versions of Monterey and Ventura. Here is my old kext (known to be working) loaded on M1 (Ventura) bare-metal 250 0 0xfffffe0006b70000 0x862ac 0x862ac org.openzfsonosx.zfs (2.1.0) BE4DF1D3-FF77-3E58-BC9A-C0B8E175DD97 <21 7 5 4 3 1> The same pkg, using the same steps in the VM, will after clicking Allow, ask to reboot (suspiciously fast), then come up with: System Extension Error: An error occurred with your system extensions during startup and they need to be rebuilt before they can be used. Of course clicking Allow just does the same, reboot, fail, ask to approve again, reboot..fail... Directly on the hardware, the dialog "rebuilding cache" pops up for a few seconds, but with the VMs I do not see it. I'm unfamiliar with the new system, so I'm not sure which log files to look at, but here is the output from kmtuil log, both at Allow and after reboot: https://www.lundman.net/kmutil-log.txt If I was going to make an uneducated guess and pull out some lines by random, maybe: 2022-08-29 20:01:13.169897+0900 0x251 Error 0x0 100 0 kernelmanagerd: Kcgen roundtrip failed with: Boot policy error: Error creating linked manifest: code BOOTPOLICY_ERROR_ACM 2022-08-29 20:01:13.170200+0900 0x251 Error 0x0 100 0 kernelmanagerd: Kcgen roundtrip failed checkpoint saveAuxkc: status:error fatalError:Optional("Boot policy error: Error creating linked manifest: code BOOTPOLICY_ERROR_ACM") 2022-08-29 20:01:13.170201+0900 0x251 Error 0x0 100 0 kernelmanagerd: Kcgen roundtrip failed: missing last checkpoint or errors found 2022-08-29 20:01:13.170242+0900 0x251 Default 0x0 100 0 kernelmanagerd: Deleting Preboot content Any work arounds? Loading kexts on my only M1 is a hard way to develop.

I have developed a kernel extension (KEXT) for driving SCSI devices and I am able to successfully use it to send commands to the underlying device. The driver class overrides the newUserClient method which gets called whenever IOServiceOpen is called from the user space so that apps can make use of the driver. Is there any way to restrict access to this kernel extension such that only my app would be able to open a user client to access the driver and communicate with it using IOConnectCallMethod?

Hi, How would I go about keeping a program at full capacity even as I leave the application? I am on Mac M1 (Ventura 13.5) and working in Unreal Engine. Specifically, I want to be able to stream my scene as I am working in it/playing the scene but this requires me to leave to application as I am working with 3 applications at the same time when doing so. Whenever I leave UE it becomes a background application and frame rate drops from 60 FPS to 3. I tried to renice but although UE is prioritized it nevertheless becomes treated as a background application and FPS drops. I suspect this has something to do with energy saving but I need to find a way around it. Anyone have an idea of how to sort this?

Hello! We develop IOS application and it’s necessary for us to check if user changed the device time in Device settings or not. We use function "clock_gettime_nsec_np(CLOCK_MONOTONIC_RAW)" to check time and it works perfect. But I saw this function only here in Documentation(in discussion section): https://developer.apple.com/documentation/kernel/1646199-mach_continuous_time and this is for Mac OS so I want to know if I can use this function in IOS application that we are going to submit to App Store or we can face with some problems? For example this function can not work on some iPhones or on some IOS or we can have some problems during the review the application in App Store? Or maybe there are some alternatives function "clock_gettime_nsec_np(CLOCK_MONOTONIC_RAW)" for IOS? We tried to use ProcessInfo.processInfo.systemUptime but it counts only when device is awaken. So we can't use it to check if user changed the device time in Device settings or not.( Thank you for any help in advance!

I regularly see folks confused by this point so I decided to write it up in a single place. If you have questions or comments about this, start a new thread here on DevForums. Tag your thread with something appropriate for the API you’re trying to use. If nothing leaps out, Kernel is a good option [1]. IMPORTANT I don’t work for App Review and can’t make definitive statements on their behalf. All of the following is about whether an API is available for you to use, not whether App Review will approve your specific usage. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" [1] Because of the KPI aspect of this, discussed below. Availability of Low-Level APIs Every now and again I see questions like this: The developer documentation has no entry for getpid. How can that not be API? Or this: I want to call mach_absolute_time on iOS. Its documentation says that it’s only available on macOS. But it’s in the iOS SDK and it works just fine. Is it OK for me to use it in my iOS app? These questions arise because: Apple Developer Documentation focuses on Apple’s frameworks. Most low-level APIs, specifically those with a BSD heritage, are documented in man pages. These man pages aren’t available in Apple Developer Documentation (r. 16512537). For information about how to access them, see Reading UNIX Manual Pages. Some low-level APIs are documented in both man pages and Apple Developer Documentation. A classic example of this is Dispatch, which has comprehensive man pages (start at dispatch 3) and good documentation in Apple Developer Documentation. Some low-level APIs, like Compression, are documented in Apple Developer Documentation but have no man pages. Some low-level APIs aren’t documented in either Apple Developer Documentation or the man pages. A classic example of this is SQLite. In such cases the best documentation may be the doc comments in the APIs headers, or on a third-party website. For Mach APIs, you often find that the best documentation is in the Darwin open source! Some low-level APIs have equivalent KPIs (Kernel Programming Interfaces). For example, mach_absolute_time is both an API and a KPI. Many KPIs are documented in Apple Developer Documentation, in a special area known as the Kernel framework [1]. Kernel development is only supported on macOS, so those KPIs are flagged as being macOS-only. However, their equivalent APIs are typically available on Apple’s other platforms. These questions most often crop up in the context of obscure low-level APIs, but many obviously valid low-level APIs have the same issue and no one worries about those. For example, Apple Developer Documentation has no documentation for the printf API [2], but no one asks whether it’s OK to use printf! Given the above, it’s clear that you can’t infer anything about the availability of an API based on its state in Apple Developer Documentation. Rather, the acid test for availability is: Is it declared in a platform SDK header? Is it not marked as unavailable on that platform? [3] Does the platform SDK have a stub library [4] that makes its symbol available to the linker? If the answer to all four questions is “yes”, the API is available on that platform. [1] The kernel does not support frameworks but bundling these KPIs into Kernel.framework within the macOS SDK makes some degree of sense from a tooling perspective, and that logic flows through to the documentation. [2] There’s a documentation page for the KPI, but that’s not the same thing. [3] Sorry for the double negative but it’s the only way to capture an important subtlety. If the header contains a declaration with no availability markings, that API is available on all platforms. A classic example of this is printf. [4] If you’re not familiar with the term stub library, see An Apple Library Primer. Hints and Tips In general, prefer high-level APIs over low-level ones. For example, prefer Date, or even gettimeofday or clock_gettime, over mach_absolute_time. However, that’s only a general guideline. In some cases the low-level API really is the right one to use. Just because something is an API doesn’t mean that there aren’t any restrictions on it. mach_absolute_time is a perfect example of this. Using it for highly accurate performance analysis of your code is fine, but using it for fingerprinting is not. See Describing use of required reason API. If you can’t find adequate documentation for an API you’re using, always look in the headers for doc comments. In some cases that’s the only source of documentation. However, even if the API is reasonably well documented, the headers might contain critical tidbits that slipped through the cracks.