“SwiftData inheritance relationship”

On recent versions of macOS a program needs the Location privilege (from System Settings > Privacy & Security) to access SSID information. It should be feasible for a launchd agent to get that — unlike, say, a launchd daemon — but it’s not without its challenges. My usual advice here is: Install the from a container app using SMAppService. This ensures that the system understands the relationship between the app and the agent. Request the Location privilege in the container app. In the agent, confirm that you have the Location privilege before attempting to do anything with Core WLAN. There’s a new-fangled way to do this but I tend to rely on the old ways. I’ve run through this process for other privileges and it works a treat. However, the Location privilege is kinda weird — it’s not managed by the standard TCC infrastructure — so I’m not 100% sure this will work in that case. But give it a whirl and lemme know how you get along. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Sup

Perhaps, it's obvious. But what's obvious to you is not really obvious to the rest of the world. I would explain in detail the relationship between we or our or our own account and all other parties including Osiel Lima, developer, the previous account.

When using SwiftData + CloudKit integration, which uses NSPersistentCloudKitContainer under the hood, the synchronization typically doesn't happen immediately. To better understand the synchronization, consider going through the following technotes: TN3164: Debugging the synchronization of NSPersistentCloudKitContainer TN3163: Understanding the synchronization of NSPersistentCloudKitContainer TN3162: Understanding CloudKit throttles In your case, the first three bullets are pretty much as-designed. The last one, no edits sync between either Mac, if lasting for ever, which means the synchronization is broken, will be an issue. In that case, you can figure out what happens by capturing and analyzing a sysdiagnose, as described in TN3163. Best, —— Ziqiao Chen  Worldwide Developer Relations.

First off, I want to start with a clarification here: We are in a logical deadlock. The kernel dispatches a probe command before UserCreateTargetForID returns, and both of our methods for handling this command result in a permanent hang of the registration process: Calling UserCreateTargetForID means please create the storage stack for this target. Returning from it means I've finished creating the storage stack for this target. I'm not sure how far up the stack you'll actually get, but it's conceivable that we'd get all the way through partition map interpretation and (possibly) volume format detection BEFORE UserCreateTargetForID returns. You're basically guaranteed to get I/O request before UserCreateTargetForID returns. [1] I think the upper levels of the SAM stack prevent this by returning from state before calling registerForService on their IOStorage family nubs, but there's no technical reason why they'd HAVE to work this way. That leads to here: We mark the target as Ready during the UserInitializeTa

So splitting targets into different projects is a way to go, but do not make cross-project references and add target dependency. The idea is to build the subproject fully separately. Claude helped with implementation, so I asked it to write the rest of the post. The Solution Two scripts, triggered at different build stages: 1. Scheme Pre-Action — BuildPkgTestCMD.sh Builds the CLI project via a separate xcodebuild invocation before the main build starts. 2. Run Script Build Phase — CopyPkgTestCMD.sh Copies the built binary into the app bundle after the Resources phase. Both scripts check EFFECTIVE_PLATFORM_NAME and skip on non-Catalyst builds (e.g. iOS). Gotchas We Hit Build settings leaking into the nested xcodebuild call. Scheme pre-actions inherit all build settings from the parent target as environment variables. This means the nested xcodebuild silently picks up Catalyst platform, signing, and arch settings. Fix: wrap the call with env -i, passing through only selected variables: env -i PATH=$PA

Apple’s relationship to ECN is nuanced, largely due to compatibility concerns. If you want to be traumatised, check out the xnu/blob/main/bsd/netinet/tcp_cache.c file in Darwin and the various callsites for that subsystem. So, my answer here depends on where you’re coming from. As a developer, you have APIs that allow you to opt out and opt in to ECN. For Network framework that is the ecnDisabled(_:) modifier [1]. For BSD Sockets there is the TCP_ENABLE_ECN socket option. The system will honour your request to specifically disable ECN, but there’s no guarantee that it will honour a request to enable it. It’s allowed to take other factors into account. That’s why ecnDisabled(_:) is named as it is. Note The name of the socket option doesn’t convey that subtlety. Notably, if you rummage around in Darwin you’ll find a related non-public socket option that better captures this nuance. Both APIs do have a way to determine whether ECN was actually used. For Network framework that’s the ecn property in the T

For comparison, this command on my machine: nvram -p | grep boot-args Returns: boot-args debug=0x104c0c vm_compression_limit=4000000000 The debug entry is not required; that just happens to be how my machine is configured. Once the changes display correctly, the machine should behave according to these, and I run the test Python script aforementioned. Do you do anything different (besides the checks, of course, and the test script/language used)? Have you not been rebooting after you set the value? It looks like I wasn't entirely clear on this, but the boot-args values are quite literally the arguments passed into the kernel when it boots up. Many of them, including this one, are used to set critical constants that are then used to define the system’s wider behavior, often in ways that simply cannot be dynamically modified. At a purely technical level, I'm not sure ANY of them actually apply dynamically; in general, the system relationship to pre-boot state (like firmware variables) is that they're p

I've just run into this issue and I can confirm that the memory leak does not occur on iPhone (iOS 18.7.1 and iOS 26) even when using UITabs occurs on iPad (iOS 18.7.1) only when using UITabs. It does not occur when setting the tab bar controller children the old way (setViewControllers(:animated:)). A work around is to use a custom TabBarController inheriting from UITabBarController and override viewDidDisappear(:) as follows: override func viewDidDisappear(_ animated: Bool) { super.viewDidDisappear(animated) // HACK: clear the tabs property to prevent memory leaks when using UITabs if #available(iOS 18, *) { setTabs([], animated: false) } } It effectively triggers the children view controllers deinit. App build with Xcode 26.2 on macOS 26.2.