dsym file

@MayankGR thank you for your question! Thank you @JosephSimpson , onWorldRecenter does indeed sound like the event the OP is looking for. This doesn't sound like expected behavior, although more context about your exact use case would help us get to the bottom of this. In case this is a bug, could you please file a bug report using Feedback Assistant? Include as much context as you can, a simple project that reproduces the issue would be perfect. And then could you share the ticket number with us in the thread? Thank you!

Thank you so much for this! Yes this is a known bug that the CarPlay team is currently fixing. Please do submit a bug and this way you'll be informed when is fixed. Thanks again for doing this! Once you open the bug report, please post the FB number here for my reference. This is very important :-) If you have any questions about filing a bug report, take a look at Bug Reporting: How and Why? Albert Pascual
  Worldwide Developer Relations.

Thank you, Albert. I have already filed this issue as FB21797091 at the beginning of this thread. I have now added additional diagnostic information to that existing report, including: Detailed swcutil_show.txt comparison between IDN and ASCII domains Entitlement configurations tested over 3 years Testing timeline across iOS 16, 17, and 18 Please reference FB21797091 for the complete bug report. Thank you for your assistance in escalating this issue.

I'm confused. Earlier you wrote the resource fork should only exist on compressed files, and cp DOES copy those but in your last reply Use the Finder to do the copy, not cp and cp decompressed the file, which ended up stripping the xattrs This doesn't make sense to me... I tried creating a file with a resource fork as you suggested, but again I wasn't able to reproduce the Result too large issue. The file, an empty .txt file on my Mac (macOS 26.2) which I added a 14.1 MB resource fork to, now displays as 14’136’946 bytes (14.1 MB on disk) in the Finder. Copying it to the FAT volume (inserted in my router and connected via SMB to my Mac) with the Finder, the cp command, or the test app I showed at the beginning which uses copyfile: they all worked, and the Finder displays the destination file as 14.1 MB. The only error I got was when trying to add the resource fork to an empty file created on the SMB volume: cat: stdout: Operation not permitted So

If there are unsaved changes, then the app should ask to save; and that's not happening. It doesn't seem like I'm doing anything particularly wrong, or omitting something that I ought to be doing; and it only affects a small number of files, and only occasionally. I'll keep an eye on in and see if I can investigate next time it happens. Thanks

@Engineer Thank you for the Info. I have filed bug FB21714445 for this and attached a sample app, necessary steps and sysdiagnose logs

[quote='874968022, Shay39, /thread/810932?answerId=874968022#874968022, /profile/Shay39'] I believe the behavior we're seeing is explained in the documentation … [/quote] That’s my interpretation as well, but I’m still not 100% certain that it matches the behaviour that ArthurValiev is reporting up thread. I have a reminder to spend some more time digging into this, but I haven’t yet had a chance. [quote='874968022, Shay39, /thread/810932?answerId=874968022#874968022, /profile/Shay39'] as it's currently the only practical method I'm aware of for preserving UDIDs. [/quote] It’s certainly a useful option, yes. Another option is to start with a template VM, then clone it twice [1] for each ‘runner’ Mac, start each one, and then stop it cleanly. Each one should pick up a new provisioning UDID during its startup sequence and you can then assign that provisioning UDID to your account. This is quite fiddly to manage, and it won’t work for organisations that have a large number of runners, but it’s an option worth ex

I figured this out, at least for me. The whole internet says you need a swift file in your project and then you'll see the Swift settings! .... That's a little too obvious. I have swift in my project and I STILL don't see the settings. The real problem for me is that the project contained an ancient build setting that appears perfectly safe: This is actually: GCC_VERSION = com.apple.compilers.llvm.clang.1_0 If that's in there, I don't see Swift Compiler sections. If I remove that (or explicitly change it to the default which is the correct value, and builds in an identical way), they instantly show up.