“eskimo”

Thanks for filing FB22708922. [quote='886910022, PavanGulla, /thread/823741?answerId=886910022#886910022, /profile/PavanGulla'] Pls help to fix the issue. [/quote] I took a quick look and your bug has landed with the right folks. However, DTS isn’t involved in fixing, or even escalating, bugs like this. If you want to escalate this then I recommend that you reach out via your business contacts at Apple. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='887212022, fbartolom, /thread/825703?answerId=887212022#887212022, /profile/fbartolom'] Unfortunately using your code … produces … Sending 'completionHandler' risks causing data races [/quote] Hmmm, it didn’t when I tested it. Lemme try that again: Using Xcode 26.4, I created a new project from the iOS > App template template. As part of that, I selected Storyboard from the Interface popup. I changed the Swift Language Version build setting to Swift 6. I added GeoreferenceQueue.swift and copied my GeoreferenceQueue to it. I added my application(_:handleEventsForBackgroundURLSession:completionHandler:) method to the AppDelegate class. It built without error. But keep in mind that my example was meant to be an expedient option. I agree with Etresoft’s comments [1] that you should step back and consider whether you want to change your overall approach. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] Well, the co

[quote='887192022, josephhivo, /thread/825332?answerId=887192022#887192022, /profile/josephhivo'] so long as the folder is not inside one of the default folders [/quote] D’oh! So, yeah, that’s not surprising. When I read through the read me for the sample, I had a gut feeling that using the Documents folder is a mistake, and it seems that my gut was right. Those folders are protected by MAC and you can run into all sorts of weird issues when using them for stuff like this. I have some background to this in On File System Permissions. Thanks for the sticking with this and for closing the loop here. I’ve filed a bug against the sample’s read me suggesting that it use some other directory (r. 176624484). Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='887034022, kunal_a, /thread/817264?answerId=887034022#887034022, /profile/kunal_a'] On FB22576068: This is resolved [/quote] Cool. [quote='887034022, kunal_a, /thread/817264?answerId=887034022#887034022, /profile/kunal_a'] However, I've added a new sysdiagnose to FB19734992. [/quote] Hmmm. Due to the confusing cluster of bugs about these issues, FB19734992 has kinda fallen by the wayside. Normally I’d work to get it back on track, but in this case I think it’s best if you start from scratch. That is: File a new bug. With an up-to-date description of the issue. And a sysdiagnose log taking shortly after seeing it. With the VPN (Network Extension) for macOS enabled. On a system that has the fix for FB22576068. Feel free to mention FB19734992, but stress that this bug still reproduces with the latest system. Once your done, please reply back here with the bug number. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='886931022, bvsdev, /thread/825268?answerId=886931022#886931022, /profile/bvsdev'] Isn’t that essentially the same as using nil for the delegateQueue here: [/quote] Correct. I should’ve mentioned that option )-: Having said that, there are reason for supplying your own operation queue: You want to serialise with other operations posted to the operation queue. You want to serialise with other work items posted to a Dispatch queue. You do that by creating a Dispatch serial queue and setting it on the operation queue via the underlyingQueue property. [quote='886931022, bvsdev, /thread/825268?answerId=886931022#886931022, /profile/bvsdev'] I believe I need to stick to a background queue instead of main. [/quote] That’s a common misconception. Your session delegate is there to perform a command-and-control function. So, for example, if you need to do some CPU intensive operation on the downloaded file, you wouldn’t do that in your delegate. Rather, you’re created some background subsystem to do that work an

So, lemme see if I understand this correctly: You have one user who’s consistently experienced this crash on macOS 26. You’ve not received reports of it from other users. You can’t reproduce it yourself. Is that right? Has that users seen it on all versions of macOS 26? Or just macOS 26.4? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='887163022, rbmanian75, /thread/825531?answerId=887163022#887163022, /profile/rbmanian75'] i use VZEFIBootLoader [/quote] Ah, OK, thanks for clarifying that. I was hoping you might be able to set EFI variables in the VZEFIVariableStore, and convince EFI to boot from a different file system that way, but apparently Past Quinn™ has already determined that there’s no supported way to do that. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

What Kevin said but also… [quote='887219022, pascalgnaedinger, /thread/803339?answerId=887219022#887219022, /profile/pascalgnaedinger'] But as long as the MultipeerConnectivity framework is … not officially deprecated. [/quote] The fact that Multipeer Connectivity is not officially deprecated is an ongoing source of confusion, one that I’ve been trying to rectify for years (r. 83185901). There are two ways to resolve that confusion: Fix the various bugs affecting Multipeer Connectivity. Formally deprecate the framework. I’d bet dollars to doughnuts [1] that the ultimate resolution is gonna be that second one. So, if you’re investing time with this framework, you should carefully consider whether that’s time well spent. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] Actually, doughnuts to dollars, because doughnuts have got a lot more expensive since that idiom was coined back in the 1800s (-:

If I were in your shoes I’d try to capture a log snapshot — ideally a sysdiagnose log, which contains that snapshot — immediately after reproducing the problem, and then look in the system log for background as to why you got this error. Your Friend the System Log has lots of info about the system log. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='887247022, Etresoft, /thread/825634?answerId=887247022#887247022, /profile/Etresoft'] Most Apple APIs, with very few exceptions … should only be called on the main thread. [/quote] I don’t agree with that summary. Ignoring Swift concurrency, I generally group Apple’s Cocoa APIs into four categories: Main thread — These are limited to the main thread, with occasional exceptions. The canonical example of this is AppKit. Thread safe — These have internal locking and can be used from any thread. A good example is NSOperationQueue. Thread or queue confined — These must be used from a specific thread (or queue) that’s not necessarily the main thread (or queue). NSRunLoop is a good example of this. Serialisation required — These have no internal locking but can be used from arbitrary threads as long as you serialise that access. A good example is NSMutableDictionary. Your summary doesn’t include the last two categories, and IME that’s the biggest group of traditional Cocoa APIs. Unfortunately it’s hard to di

So there aren’t hard’n’fast rules here. I can explain some tools that you have available, but you have to make your own judgement calls as to best to use those tools in your product. The most critical item here is the sourceAppAuditToken property. This holds the bytes of an audit_token_t, and from that you can use the code signing machinery to get information about the process and its main executable. I’ve talked about this a bunch of times here on the forums. This post has a snippet you can copy, but it’s probably worth you searching for other similar threads for more advice. IMPORTANT The first part of the snippet, getting the audit token and passing it to the code signing API, is canonical. The second part, getting the bundle ID, is not. Bundle IDs aren’t secure on macOS. Once you’re in ‘code siging space’ you can use code signing requirements to check the code in question. For example, the anchor apple requirement will tell you whether the code is from Apple. TN3127 Inside Code Signing: Requirements talks

I suspect you’re confused by the various 10-character identifiers used by code signing. I recommend that you have a read of Code Signing Identifiers Explained, and specifically the entries on Team ID, User ID, Team Member ID, and App ID prefix. [quote='825789021, iceboy, /thread/825789, /profile/iceboy'] the retrieved Team ID is an unknown one and does not match the Team ID of my developer certificate [/quote] There are two possibilities here: Your app uses a unique App ID prefix, which by definition doesn’t match your Team ID. You’re using your Team ID as the App ID prefix, but you’re misreading the Team ID in your code signing certificate. It’s hard to tell which of this is correct without more context. What value do you get back in bundleSeedID? Does it match C____2____? If so, that’s your Team ID, which suggests you’ve hit the second case I’ve described above. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Are you asking about this from the perspective of someone using VM apps built by other developers? Or as someone who’s building a VM app themselves? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='887276022, andersonad, /thread/813869?answerId=887276022#887276022, /profile/andersonad'] No answer whatsoever. [/quote] Indeed. But that in itself is signal. If this were a common issue, it’s likely that someone else would’ve chimed in here. That fact that no one has indicates that there’s something specific to your environment that’s triggering it. In such cases there are two paths forward: A proper investigation A search for workarounds For the first, you’ve already filed bugs about this (FB21642029 and FB21017894) and that’s the correct way to request a proper investigation. For the second, I suggest you try varying your environment, one item at a time, to see if you can work out what’s triggering it. I have a standard set of things that I like try: Try again from a different network. If you’re at work, try doing it at home, or vice versa. Or in your local coffee shop. I regularly see weird problems caused by middleboxen, such as corporate firewalls. Create a new user account on your Mac. This giv

You can expect that most uploads will be notarised quickly. Occasionally, some uploads are held for in-depth analysis and may take longer to complete. As you notarise your apps, the system will learn how to recognise them, and you should see fewer delays. For lots of additional info about notarisation, see Notarisation Resources. Specifically, it links to a Q&A with the notary service team that’s quite instructive. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com