dsym file

This is a well-known problem. It actually doesn't (directly) involve your app at all. The operating system will do this with any document when you've configured the document to be opened with an app that doesn't explicitly declare support for it. Since you have declared support for this file type, the most likely explanation is that you haven't declared that support correctly. Document types are specifically for the NSDocument architecture. I don't know anything about your app so I don't know if that usage is appropriate or not. But it sounds like you just need to add some imported type identifiers for those types.

Do you have a feedback report yet? If not, would you mind to file one with a sysdiagnose, and share your report ID here? The way to capture a sysdiagnose is detailed in the instructions. Given that killing apsd makes the last notification come through, which approves the subscription for your Mac is there, and that the same code and configuration work well on iOS, and also the systems before macOS Sonoma, but just not on macOS 26.3, the issue is most likely a bug. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Thanks again for reporting the issue. It seems that the issue is impacting the community, but I haven't seen any feedback report ID posted here. Do folks have any feedback report yet? If not, would you mind to file one and share your report ID here? I understand that filing an actionable feedback report takes time, but that will help. I am trying to capture the issue, and yet, my current configuration, Xcode 26.2 (17C52) + iPhone 17 Pro with iOS 26.3 (23D127) + Apple Watch series 10 with watchOS 26.3 (23S620), does work for me. Best, —— Ziqiao Chen  Worldwide Developer Relations.

[quote='876733022, disinghal, /thread/811887?answerId=876733022#876733022, /profile/disinghal'] URL Session is calling a public endpoint. [/quote] Right, but you’ve set up your on-demand rules to say that everything generates demand. It’d be interesting to see what happens if you configure your on-demand rules to only generate demand what you load a URL that’s behind the VPN. I suspect it’ll work consistently, but if you find that’s not the case then that’d be an interesting datapoint. [quote='876733022, disinghal, /thread/811887?answerId=876733022#876733022, /profile/disinghal'] It happens intermittently. [/quote] Fair enough. But that doesn’t really contradict the position I explained above. You’ve set yourself up for failure and that you only fail in some cases. That’s a win, right? (-: Seriously though, I don’t think I’m going to be able to help you further here. You are clearly exploring the limits of what’s possible. If you want to make the case that this should work, I recommend that you do that direct

[quote='876709022, siddhant-mac, /thread/815755?answerId=876709022#876709022, /profile/siddhant-mac'] is it possible on the macOS login window? [/quote] That depends on what you mean by “it”: If you’re asking whether it’s possible to reuse infrastructure used by Platform SSO then the answer is “No.” If you’re asking whether it’s possible to create an authorisation plug-in that presents a completely passwordless experience, the answer is more nuanced. You can certainly make a lot of progress, but I don’t think there’s a complete solution. Sticking points involve FileVault, as I’ve mentioned above, and unlocking the keychain. This is especially problematic when it comes to the data protection keychain. Honestly, I don’t see a good path forward for this. The authorisation plug-in mechanism has significant issues, and I’m doubtful they’ll be addressed because of limitations in that architecture. Specifically, FileVault support is pretty critical and it’s hard to see how that can happen within the current design.

@fpiovezan Thank you for joining the conversation. You have requested for me to: validate the state of Accessibility options run an experiment and file a new FB with logs attached After gathering our bearings, it's clear to me that I will not be able to provide anything new that was not already provided in FB20359822 . Can you please consult that FB ticket as it has all the extensive info and logs of using Xcode 26.2 with iOS 26.2, and what's also important, a project that reproduces the issue. As for the accessibility options, we are certain that we do not really enable anything on by hand, never. We are going to attach a video recording of our accessibility options to the same FB20359822.

After the initial setup worked for regular builds, three edge cases needed fixing. Early exit on clean (BuildPkgTestCMD.sh) The pre-action runs even when cleaning, but there’s nothing to build and nothing to clean manually — PkgTestCMD lives inside the parent’s BUILD_DIR, so Xcode cleans it automatically. We just exit early. OBJROOT isolation (BuildPkgTestCMD.sh) We were already setting SYMROOT to keep build products inside the parent’s BUILD_DIR. Turned out OBJROOT (intermediates) also needed to be isolated, otherwise building PkgTestCMD standalone would conflict and produce “entitlements modified during build” errors. TARGET_BUILD_DIR (CopyPkgTestCMD.sh + outputPaths) During archive, Xcode always creates a temporary .app directory and copies the bundle there itself — it knows exactly what files it’s putting in. Copying our binary to BUILT_PRODUCTS_DIR meant injecting a file into that directory after Xcode had already done its packaging, so Xcode had no awareness of it. TARGET_BUILD_DIR is