dsym file

Any updates on this? We are facing the very same issue in our app and couldn't find a workaround for this. This issue is preventing us from migrating to Xcode 26. We have also filed the FB21327884 feedback in December.

Our engineering teams need to investigate this issue, as resolution may involve changes to Apple's software. Please file a bug report, include a copy of the file(s) you're having trouble with, and post the Feedback number here once you do. I'll check the status next time I do a sweep of forums posts where I've suggested bug reports and post any information about changes I am able to share to this thread. Bug Reporting: How and Why? has tips on creating your bug report.

Thanks for the post and it seems like when you moved to the new computer the git was not configured? The fact that you switched Macs and upgraded Xcode/macOS versions is a strong indicator, for me, that the issue stems from the environment differences or a configuration mismatch. Open your Terminal application and navigate to your project directory. What do you get when you request the git status? git status Does git status accurately reflect the staged changes you see in Xcode? Are there any untracked files that Xcode might be confused about? Are there any error messages? There are a few things you can do in the terminal to make sure git was installed and configured correctly: git commit -m Test commit message from terminal
 
git diff --cached
 
In Xcode, go to the Navigator pane (left-hand side). Select the Source Control tab (the icon with branches or waves). Does it show any errors or warnings related to your repository? Check the configuration on git with using the correct username and email add

It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits. Bug Number: FB21838832 Thanks for that. You only just filed this bug, so I’ve no news to share yet. It looks like the CodeWeavers’ folks did a bunch of research into this. Do you know if they filed a bug about it? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

We just filed two related Feedback Assistant reports: FB21858319 (After macOS reboots, multicast traffic might not be received by app even with Local Network permitted): that's the one you should be interested in, this is the issue you could reproduce FB21858436 (Several versions of an app show as several instances in Settings > Privacy > Local Network. They all toggle as one, and affect only one version of the app.): we also described it in this thread Thanks for you help. We're still curious as to why you cannot reproduce the issue consistently, while on my setup any reboot breaks Local Network. Issue might be very sensitive to initial conditions. Let's hope the right team can figure out the proper patterns, we really hope to find either a fix soon (or at least a practical, user-friendly workaround, to help our users). Thanks! Victor & Team

Closing the app and running TM fixes the error. So you're saying there is no error? Because that's how Time Machine works. It doesn't back up open files. There is some uncertainty as to what constitutes an open file on macOS. Obviously an open SQLite file or a package being actively modified will qualify. But an NSDocument file, even though it opens a file only briefly, could replace the original at some later date. I'm happy to let the Apple folks debate those finer points. If the problem goes away when your app quits, then there is no problem. You still haven't answered my question about your NSDocument Viewer/Editor role. Perhaps that is an improvement you can make.

Hi @DTS Engineer Apologies for the delay in my response. It took some time to test multiple cases and gather meaningful logs to provide a clear picture of the situation. As you suggested, I have filed a formal bug report via Feedback Assistant: Feedback ID: FB21856584 ([Notarization] Excessive notarization processing time for large app bundle (100GB+)) I have attached a ZIP file containing logs for 9 separate cases. All 9 submissions consistently show the same pattern: a reasonable upload time (~30 minutes) followed by 4 to 6 hours of server-side processing. This delay is a critical bottleneck in our distribution logic. I would greatly appreciate it if the relevant engineering team could investigate the cause of this lengthy processing time. Specifically, we would like to know if there are factors in our app’s structure causing these delays, or if there are improvements we can make on our side to optimize the process. Furthermore, we would be grateful if Apple could investigate whether there

Hello, I think it's expected that Transaction.updates is not called (because when a user cancels its subscription, there is actually no new transaction to be pushed to the devices) but I expect Product.SubscriptionInfo.Status.updates to be called (also when a user changes plan from monthly to yearly for example, so we can be informed about the renewal product). This Status.update async sequence is called when I test with Xcode testing (with a configuration file). But this behaviour seems to be different in the Sandbox environment (or it's very very slow to update?). Before publishing the app, I want to be sure my flow is working but having two different behaviours between the Sandbox and the Xcode testing is not helping. Thank you, Axel

[quote='874603022, DTS Engineer, /thread/814076?answerId=874603022#874603022'] Copying a file with a small resource fork (~56 Kb) failed [/quote] Which file did you copy? I assume the one you reported in the code block afterwards /System/Library/CoreServices/Finder.app/Contents/Resources/Invitation.aiff but when executing the xattr command on that file I don't get any output, i.e. it seems that it has no extended attributes.

I’ve been looking at this again today. I can definitely reproduce it but, yeah, it’s weird. I’m gonna have you file a bug about this, but before we go there I want to share and compare some experiences. Your instructions indicating that you were running the app from the desktop. That’s a bit weird, and I originally thought that it might be a factor. AFAICT it is not. I was able to reproduce the problem when running the app from my Applications folder and my home directory. I originally thought that this might be timing related. That is, it was triggered by me running the app immediately after a restart. However, my tests today suggest that it’s not, or at least not related in that way. Specifically, I started waiting for about 10 seconds between when the Finder shows up and when I launch the test app, and I can still reproduce the problem. I’m still suspicious that it might be related to the time between when I launch the app and when I start the multicast receiver, but I haven’t spend the time to te

I'm just using openDocument, without overriding it. Yes, the files are on the internal boot volume (APFS). The error was flagged in the UI. TM reported that the backup hadn't completed, and in System Settings it reported the name of the file. It has done this to various files: the only connection is they are all PDFs that are or have been open in my app. Closing the app and running TM fixes the error. As usual, I can't find any relevant logs in Console.