dsym file

This got even weirder. One is that sometimes the use of cos() would cause a compiler error, which was fixed by using Darwin.cos(). This may be fixed in Swift 6.3. The other thing is that in my much more complex code, the crash seemed to be caused by both the cos() call evaluating to 0, but only when the line being drawn with that result had a StrokeStyle applied to it. In anycase, I have filed Feedbacks explaining this, and I'm told the WindowServer team has had it brought to their attention.

@susu123, thank you for filing FB21537703. Looking at the status of that bug I see the engineering team has asked if you are able to reproduce this problem in the most recent update. To prevent this bug from being closed, please test in the most recent update and add those details to your bug report. Please continue testing your software in new system software updates and beta releases as they become available. And please update the status of your bug whenever you do a new test. Please see https://developer.apple.com/download/ for the most recent beta releases. For the rest of you on this thread, please consider filing feedback reports as well. Though indeed they will be duplicate reports to FB21537703, duplicate reports matter and help engineering understand how many people's apps are affected by a problem. Bug Reporting: How and Why? has tips on creating your bug report.

Thank you for your post. I must clarify that I am not entirely certain of your intended purpose. Are you referring to a SSL certificate? However, the question mentions the /.well-known directory, which suggests that you may be attempting to host an AASA file. To provide a more accurate response. Since you mentioned being able to access the URL within the .well-known directory via Apple's validation tool, it indicates that your web server setup is likely correct from an external perspective. I would appreciate it if you could elaborate on your specific requirements. Albert Pascual
  Worldwide Developer Relations.

[quote='874234022, pawanquantum, /thread/813746?answerId=874234022#874234022, /profile/pawanquantum'] We’ve already tested this on macOS [/quote] OK. If you’d like to see this change — that is, for macOS to have the same “active VPN configurations” affordance that iOS has — I recommend that you file an enhancement request for that. Please post your bug number, just for the record. [quote='874234022, pawanquantum, /thread/813746?answerId=874234022#874234022, /profile/pawanquantum'] is there a supported API, entitlement, or configuration path [/quote] No. The Core WLAN policy is gated by a linked-on-or-later check, which provides compatibility for existing products while enforcing the privacy rules for new products. And while it’s easy to lie about the SDK you’re built with — if you’re curious, see the vtool man page — we don’t support that because: The SDK you’re built with controls a wide range of interesting functionality, and it’s not hard to imagine scenarios where lying about that could cause you

Thank you for your reply. Our previous Team ID was H7837BUR8M. We tried changing the value of com.apple.developer.ubiquity-kvstore-identifier in the .entitlements file from $(TeamIdentifierPrefix)$(CFBundleIdentifier) to H7837BUR8M$(CFBundleIdentifier), but Xcode still reports the same error.

Thank you for your response, Albert. I have collected the sysdiagnose and analyzed the swcutil_show.txt. Here are my findings: IDN Domain (求人ボックス.com) Status: Service: applinks App ID: 59S472WZMN.com.kyujinbox.app Domain: 求人ボックス.com User Approval: unspecified Site/Fmwk Approval: unspecified Flags: (No Last Checked, No Next Check, No Patterns) -------------------------------------------------------------------------------- Service: webcredentials App ID: 59S472WZMN.com.kyujinbox.app App Version: 979.0 App PI: { v = 0, t = 0x8, u = 0xc48, db = 0033C5BB-DA64-445A-990F-46FB487C364F, {length = 8, bytes = 0x480c000000000000} } Domain: 求人ボックス.com User Approval: unspecified Site/Fmwk Approval: unspecified Flags: ASCII Domain (kyujinbox.onelink.me) Status: Service: applinks App ID: 59S472WZMN.com.kyujinbox.app Domain: kyujinbox.onelink.me Patterns: {/:/H8dE/*} User Approval: unspecified Site/Fmwk Approval: approved Last Checked: 2025-09-04 07:20:14 +0000 Next Check: 2025-09-09 07:04:29 +0000 Key Observations: The IDN

813827283 (=0x308204D3) matches a certificate header, not an SPC, which should start with either 0x00000001 or 0x00000002. I believe you are incorrectly passing your FairPlay certificate as the spcData field to the key server. The SPC is a license request generated by the client device. You can find some sample SPCs in the SDK under Development/Key_Server_Module/Test_Inputs inside the sample json files.

Have you filed a bug on this and, if so, what's the bug number? __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Hi @RB3207, Apple Pay does automatically re-verify your merchant domain after registration based on the expiration date of your SSL certificate. To mitigate any issues with your Apple Pay integration, you should configure your environment to use subdomains for each registered merchant ID instead of rotating merchant domain verification files manually. To learn more about merchant domain verification, please see below: TN3173: Troubleshooting issues with your Apple Pay merchant identifier configuration: Your domain does not automatically re-verify https://developer.apple.com/documentation/technotes/tn3173-troubleshooting-issues-with-your-apple-pay-merchant-id-configuration#Your-domain-does-not-automatically-re-verify Cheers, Paris X Pinkney |  WWDR | DTS Engineer

I'm developing a DriverKit USB driver for iPadOS. So, my first and strongest recommendation is that you shift your development environment from iPadOS to macOS, even if you never intend to ship on macOS. I have a more extended post on this here, but the basic summary is that, in my experience, the higher friction, lower visibility, and lack of critical investigator tools [1] on iPadOS mean that you'll end up wasting far more time trying to figure out “what’s happening on iPadOS than you saved by not getting a minimal macOS implementation working. [1] In particular, I consider IORegistryExplorer to be an absolutely critical tool for driver developers. See this forum post for download instructions and general guidance on using it. That leads to here: Does iPadOS allow third-party DriverKit extensions to access vendor-class (0xFF) USB devices? That is, in iPadOS, is there a way for a third-party DriverKit extension to access IOUSBHostInterface objects for vendor-class (0xFF) USB devices? Yes, that should also wo

Hi @keckausome, please file a feedback report for Xcode Cloud (including your team ID and logs for this failure) and then post the feedback number here. You can file Xcode Cloud specific feedback using these steps.