“SwiftData inheritance relationship”

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.

Thanks for mentioning me. The feedback report (FB15507372) @xmollv filed is still under the investigation of the SwiftData team, and we don't have anything ready to share yet. Sorry for no help :-(. Best, —— Ziqiao Chen  Worldwide Developer Relations.

I provided the source code above for replicating the issue - the GUID for the associated relation has (ahem) no relation to the original record GUIDs. Is someone looking into this - this seems like a bug as what would be the point of not being able to deference the top level record from the relationship.

Hi @milesg000, Please see my reply to the post you mentioned for the expected behavior: Multiple Apple Pay relationships with differing apple-developer-merchantid-domain-association files https://developer.apple.com/forums/thread/695538?answerId=874306022#874306022 Cheers, Paris X Pinkney |  WWDR | DTS Engineer

Thank you for verifying the AASA on Apple's CDN, Albert. Let me clarify the points you raised: 1. URL-Encoded Paths in AASA The URL-encoded characters in the paths are intentional and correct. These represent Japanese text in URL paths: URL-Encoded Decoded (Japanese) Meaning %E3%81%AE%E4%BB%95%E4%BA%8B の仕事 jobs %E9%9A%9C%E3%81%8C%E3%81%84%E8%80%85%E6%8E%A1%E7%94%A8 障がい者採用 disability employment Per RFC 3986, non-ASCII characters in URL paths must be percent-encoded. This is the standard approach for internationalized URLs and should not cause issues with AASA parsing. 2. Relationship Between 求人ボックス.com and xn--pckua2a7gp15o89zb.com These are the same domain: 求人ボックス.com — Unicode/display form (IDN) xn--pckua2a7gp15o89zb.com — Punycode/wire form The AASA is correctly hosted at the Punycode domain (https://xn--pckua2a7gp15o89zb.com/.well-known/apple-app-site-association), and as you confirmed, it is successfully synced to Apple's CDN. 3. The Core Issue Based on swcutil_show.txt, the problem appears to be

I encountered another bug with SwiftData and inheritance and reported it (FB21837287). This one is not related to CloudKit. Briefly, SwiftData crashes during auto-save when the schema contains: A base @Model class with at least one subclass (inheritance) A separate @Model class with a reference to the base class The crash occurs specifically when: There is a class inheritance hierarchy (Beta: Alpha) A separate class (Standalone) has a reference typed as the base class (Alpha?) Changing the reference from var ref: Alpha? to var ref: Beta? (subclass) eliminates the crash.