dsym file

Thanks for the post. It seems like you have not received any replies. I think I have a suggestions for you to get people to see the issue you encountering by providing a little project sample. I am not aware of any localization issues at this time. So once that string is translated, changing the default value in code and rebuilding does not update the catalog? Or is there a way to determine what strings have default values in code that do not match the catalog values to see if any were missed as wording was tweaked over time? It’s been a long time since I use that, when I was using it I did periodically export my localization files using Xcode's Editor > Export for Localization.... This created an XLIFF file that I can diff against previous versions to spot discrepancies between default values in code and your localization files. Now, I think many developers are experts in localization and they can provide you great suggestions but I think that if you provide a little focused sam

That's a surprise to me. Would you mind to try with the following steps and see if the error is still there? Confirm the app transfer process is successfully completed. Confirm your provisioning profile is updated. You can do so by uncheck the Automatically manage signing box in Xcode and then check it back, which has Xcode refresh the provisioning profile. If you manually manage your codesign, download the updated profile from Apple's membership portal. Find the provisioning profile for your app from ~/Library/Developer/Xcode/UserData/Provisioning Profiles/ (or ~/Library/MobileDevice/Provisioning Profiles/ if you are using earlier version Xcode). If you have multiple files in the folder, find the one that has App ID Name tied to your app ID. Open the provisioning profile with your favorite text editor, and try to find the identifier of the key-value store identifier. If everything goes well, the identifier should be there. In your Xcode project, update the value of the com.apple.developer.ubiquity-k

Thanks so much for providing this, this is really good troubleshooting and you went over the steps. I like to verify the file when gets synced to Apple servers. I see some characters that should be in plain text instead of this: curl -v https://app-site-association.cdn-apple.com/a/v1/xn--pckua2a7gp15o89zb.com The content: { /: /*%E3%81%AE%E4%BB%95%E4%BA%8B, ?: { cid: ?* } }, { /: /*%E3%81%AE%E4%BB%95%E4%BA%8B-*, ?: { cid: ?* } }, { /: /%E9%9A%9C%E3%81%8C%E3%81%84%E8%80%85%E6%8E%A1%E7%94%A8/*, ?: { cid: ?* } } That could be causing an issue. Another way is to test on the device using the App Notes with a link. For the 求人ボックス.com I do not have the AASA file. But could be an issue with the URL? Albert Pascual
  Worldwide Developer Relations.

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