Swift 6

Sorry I didn’t reply sooner. I was notified of your earlier posts )-: [quote='850943022, SilverFruity, /thread/794589?answerId=850943022#850943022, /profile/SilverFruity'] calling raise to throw SIGABRT does not block the thread under GCD. [/quote] By “under GCD” I presume you mean “when using a Dispatch signal event source to handle the signal”. If so, then, yes, that’s expected. Dispatch signal event sources are very much like kqueues, in that they are delivered asynchronously. Thus if you raise a signal by calling raise (or kill with your own pid) then the thread calling raise may well return before the signal is delivered to the queue. If you’re building your own crash reporter — which, as I noted above, is something I specifically discourage — and you choose to implement in-process crash reporting via signals — again, not something I recommend — then you have to use a signal handler rather than a Dispatch signal event source. [quote='851087022, SilverFruity, /thread/794589?answerId=851087022#851087022, /

I also try to be a good app, and provide asynchronous support. I think that's your problem. It's too difficult to keep up with that. Your asynchronous code is already deprecated and disavowed. First of all, make sure you try using the ClipboardViewer tool. I think it's in Xcode's AdditionalTools as a separate download. I know you're dealing with Drag and Drop, which is not quite the same, but it may be enlightening as most people implement Copy and Paste with the same data. I've never tried dragging from Safari, but I certainly never seen any TIFF conversions. I even support data types that the system doesn't, so there's no way it ever could convert it. Again, I think you're trying too hard. Instead of itemProvider.loadInPlaceFileRepresentation, try just loadItem. That should give you the actual URL. You might run into concurrency problems. I seem to have encountered that myself with these APIs. Unfortunately, there's no easy solution. You definitely don't want to try those old dispatch queues, at least not i

[quote='856588022, jumbopilot, /thread/798431?answerId=856588022#856588022, /profile/jumbopilot'] But the connection using the same NWConnection instance (self.connection) does not succeed. [/quote] I’m actually a bit confused here, because your code uses two different syntaxes to refer to the connection. With reference to your most recent snippet, line 1 is this: self.connection.cancel() which uses self.connection and line 6 is this: connection = NWConnection(…) which just uses connection. I believe that these are referencing the same thing, that is, the connection property of the enclosing class. However, it’s hard to be 100% certain without seeing more context. Stilly, I can explain some basics… NWConnection is a class, so self.connection is a reference to that class. So, when talking about “the same connection” you have to distinguish between an object reference and the object itself. Any given NWConnection object has a one way state flow. It starts in the .setup state and ends in either .failed(

hi Claude, thank you for the reply. are you using Swift UI? I am not so I'm wondering if this is the difference. It looks like you are doing this in the UI Preview...

[quote='856395022, erdeszbalazs, /thread/798938?answerId=856395022#856395022, /profile/erdeszbalazs'] How can one XPCSession transfer let's say two distinct types of Codable messages? [/quote] Again, I don’t have a lot of concrete experience with the low-level Swift API, but my natural inclination here is to use an enum as your Codable message, with a case for each message type and an associated value with the payload for that message type. So, something like this: enum WaffleRequest: Codable { case cook(Cook) case varnish(Varnish) struct Cook: Codable { var minutes: Int } struct Varnish: Codable { var finish: Finish } enum Finish: Codable { case matt case gloss } } Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I had exactly the same issue with iOS 26 Beta 5 but it seems to be resolved in Beta 6.

Hello @giovanniR2U , thank you for your question! Swift uses automatic reference counting (ARC), which means memory is automatically cleaned up for any object that is no longer referenced. Often, this is as simple as removing a root entity from the scene (thereby removing each of its descendants) or dismissing the ImmersiveScene entirely. Going through each entity in the scene and calling removeFromParent() for every entity and setting texture references to nil should not be necessary. The important thing is to verify there are no more references in memory, so make sure you don't have any variables lying around that might still be pointing to the objects you want to unload. When you load your textures sequentially, are you keeping a reference to these textures in the system that loads them? This would prevent ARC from unloading those textures. You mention your app goes from 30 MB to 3.3 GB after loading just the textures, and then only goes to 2.6 GB after dismissing the experience. This to me sugges