“DTiPhoneSimulatorErrorDomain Code 2”

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 (-:

[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 h

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

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 + @ + appl

[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.

So, the behaviour you’re seeing is expected. This capability is restricted to specific distribution models. To confirm that, follow the instructions in Finding a Capability’s Distribution Restrictions. As to what you should do about that, it kinda depends on how your product is deployed. You wrote: [quote='825833021, apisdk, /thread/825833, /profile/apisdk'] We are implementing an exam mode feature for an educational app used in schools [/quote] In-House (Enterprise) distribution is intended to be used for apps deployed within your enterprise. Presumably these schools are separate organisations, which means you must use some other distribution mechanism to distribute your app to them. What is that mechanism? The App Store? If so, the standard path forward here is to use your Organization team for both development and distribution. I see a lot of folks use In-House (Enterprise) for internal testing, and that’s not something I recommend [1]. Rather: Use Apple Development code signing for day-to-day deb

Yeah, this is a pain. SecCode acts a bit like a subclass of SecStaticCodeRef, so in most cases you can pass the first when the system expects the second. This is fine in C-based languages but Swift’s strong type checking is much less happy. In most cases the solution is to call SecCodeCopyStaticCode to convert the first to the second. Note I’ve always treated this as Security framework lore but, on looking at it again today, I discovered that it’s actually documented pretty well. However, this falls apart for SecCodeCopySigningInformation where in some cases you must pass in the original SecCode object. And yeah, my workaround for that is an unsafeBitCast(…). Alternatively, if this particular part of your product has easy access to C-based code, you can write a wrapper in C. Finally, I’d appreciate you filing a bug about this. Forcing folks to use unsafeBitCast(…) is… well… suboptimal, and so it’d be nice if we could add an overlay to get around that. If you reply here with your bug number, I’ll add

Unmodified code from here https://developer.apple.com/documentation/visionos/playing-spatial-audio-in-visionos I am not mirroring my screen. No sound connected to Xcode and I get the error in the log. No sound if my VisionPro is not connected to Xcode. I have a Gen 1 Vision Pro and using Xcode 26.4.1

Judging from your other threads, perhaps you're overusing actors and completion handlers. I've only used one actor and that was on my first Swift 6 app. I've learned a lot since then. Completion handlers are a different problem. They are largely a legacy of Apple's now-abandoned GCD architecture. The Swift concurrency approach is to use sequential, but asynchronous code instead. That new Swift approach is great. But so many Apple APIs are still based on blocks/closures. Easily the vast majority of all the sending problems I've encountered have been with blocks/closures. I would love to be able to write the kind of asynchronous Swift code I see in the WWDC demos. But it seems like it's never possible with Apple APIs. So my suggestion is to re-think the actor and the completion handler. Obviously, if you have an API that requires a completion handler, you often can't get around that. Sometimes APIs do have an asynchronous version. But if they don't, then you have to handle that code m

Hmmmm, that’s a bit extreme. There are plenty of classes that are sendable in our various platform SDKs. Sorry. Perhaps I should have qualified that statement to make it clear I was talking about a general type of behaviour rather than a mathematical absolute. What I meant to say is that sometimes Apple APIs are simply incompatible with standard software development techniques and architectures. The example I was thinking about at the time was Objective-C exceptions. Another example is multithreaded code. Most Apple APIs, with very few exceptions (the general kind, no the try/catch kind), should only be called on the main thread. And even the few documented thread-safe APIs aren't always safe. Swift finally seems to have solved that via Approachable Concurrency. But now that I think about it, it seems there is yet another fundamental incompatibility. This likely explains the problem I had trying to use sending. Swift concurrency is incompatible with object-oriented programming. Simple demos work fine

So I tried changing the bmNetworkCapabilities to 0xD0 as suggested, but that means that bit 7 is set (Function supports extended NCM 1.1 capabilities) which my device doesn't - it is an NCM 1.0 device. Sorry about that, I was jumping around on a few different issues and messed up the example above. All you need to do is set D0 of the bitfield, so you're declaring support for SetEthernetPacketFilter. So that would be (assuming you're not setting an other bits): 06 24 1A 00 01 01 To clarify what I expect/hope setting that will do: macOS will see the bit and send SetEthernetPacketFilter (basically, to confirm functionality). Your accessory will fail the command (because you don't actually support it). macOS will see the failure and then proceed normally (because there's already code in place to handle devices that behave like this). I can't guarantee that will work, but the engineering team thinks that it will. Could you confirm whether macOS is compatible with NCM 1.0 devices? Yes, it is. Also, to be c

@iami2 Do you get the same results with just the relevant code in a small test project? If so, please share a link to your test project. That'll help us better understand what's going on. If you're not familiar with preparing a test project, take a look at Creating a test project. This way will be easy to see why the target is not having access to your BAAppGroupID Thanks Albert
  Worldwide Developer Relations.

Hi, thanks for the suggestion. We did consider a synthetic step inserted before the real interval step, but it does not quite fit the use case. WorkoutKit surfaces every step in the watch preview, mid-workout indicator, and HealthKit history. A synthetic 15 second step appears as a real step in all three, so the runner sees four steps in their interval (recovery, prep, work, recovery) instead of the two they actually performed. The recorded summary later does not reflect the session structure. The step transition haptic means this step starts now. A pre-roll haptic should mean the next step starts soon. Using the transition haptic for both makes the two cues hard to tell apart.