According to this post: https://stackoverflow.com/questions/76238555/why-are-txt-records-set-to-nil-when-using-nwbrowser-for-network-framework the problem is in the NWBrowser. There are two different descriptor types, .bonjour and .bonjourWithTXTRecord. Hopefully that will fix it. If not, you'll have to work your way through the debugging path.

[quote='post, Baylward, /thread/793561, /profile/Baylward'] This seems contrary to what the documentation says here [/quote] That documentation specifically refers to a security-scoped URL. That is a URL that you've retrieved from a security-scoped bookmark. If you've retrieved the URL from some other means, then these methods may not necessary (but see below). [quote='post, Baylward, /thread/793561, /profile/Baylward'] why not save and retrieve the URL immediately in order to avoid having to make any additional calls to url.startAccessingSecurityScopedResource?[/quote] Saving and retrieving a URL is a time-consuming hassle, especially compared to calling these two methods. You only want to do that if you really need to. You can call start/stopAccessingSecurityScopedResource on any URL. You just have to pay attention to the result from startAccessingSecurityScopedResource. You only need to call stop if start returned true. When you get a URL via the standard UI pickers, then it already has an implicit "start". That's why it works. There's no problem with calling "start" again, as long as you don't call "stop" if "start" returns false. This is handy for cases where you do the URL handling elsewhere. You can just always call start/stop, and if you do it correctly, it will always work. In some cases, especially on macOS, saving and loading bookmarks can be more tricky, so that's another reason to avoid it if you don't need to do that.

What is "logPath"? It sounds like you may have sandboxed the app. It probably no longer has access to whatever logPath is. Since this is your own app, the easiest solution would be to disable the sandbox. If you want to be clever, you could give yourself a temporary exception entitlement for that path.

[quote='849091022, DTS Engineer, /thread/792821?answerId=849091022#849091022'] [quote='848905022, pbierre, /thread/792821?answerId=848905022#848905022, /profile/pbierre'] 2. How was it decided to install them in the wrong place? [/quote] [/quote] Thanks!

[quote='847713022, Etresoft, /thread/791376?answerId=847713022#847713022, /profile/Etresoft'] This is another test:[/quote] This is nice. 😄

Try doing diff -r --brief /path/to/Xcode/SDK /path/to/Xcode-beta/SDK and then opendiff on each line. You might need to wrap it in some extra logic because versions numbers in the headers will have been updated, so pretty much every file has been updated. But otherwise, it clearly shows the differences.

It's more likely that Finder is calling a network-specific file operation for the SMB or AFP connection. You said you "could" work around the problem by manually doing a recursive delete. But does that mean that this actually works? Permissions can be complicated, especially on a Linux-based file server that the user could have configured in an unusual fashion.

It looks like you're using the deprecated "metadata" property. I'm not familiar with these AV APIs, but it looks like modern versions make the asynchronous nature of this operation explicit, as in this example.

This is another test: let redacted = "signal"

This is a signal test.

Alas, I don't know the answer to your question. But at least now you can post it without using such naughty language.

Hello, I have been working on an audio module that plays a specific sound at regular intervals -- similar to a workout timer that alerts the user to switching exercises every few minutes. I'm configuring my audio session like this: let session = AVAudioSession.sharedlnstance() try session.setCategory( .playback, mode: default, options: [.interruptSpokenAudioAndMixWithOthers, duckOthers] ) self.engine.attach(self.player) self.engine.connect(self.player, to: self.engine.outputNode, format: self.audioFormat) try session. setActive(true) I schedule playback using a DispatchQueue (that's what scheduleAudio does): self.scheduleAudio(at: interval.start) { do { try audio.engine.start() audio.node.play() for kue in interval.cues { audio.node.scheduleBuffer(kue.buffer, at: AVAudioTime(hostTime: kue.hostTime)) } } catch { print (Audio activation failed: \(error)") } } This works perfectly in the foreground. But once the app goes into the background, the scheduled callback runs, yet the audio engine does not start, resulting in 'AVAudioSession.ErrorCode.cannotStartPlaying'. Interestingly, if the app is already playing audio before going to the background, the scheduled sounds continue to play as expected. I have added the required background audio mode to my Info plist file by including the key UlBackgroundModes with the value audio. Is there anything else I should configure? What is the best practice to play periodic audio cues when the app runs in the background? How do apps that do turn-by-turn navigation handle continuous audio playback in the background? Any advice or pointers would be greatly appreciated!

It didn't like the word "c u e"

try audio.engine.start() audio.node.play() for q in interval.cues { audio.node.scheduleBuffer(q.buffer, at: AVAudioTime(hostTime: q.hostTime)) }

self.scheduleAudio(at: interval.start) { do { } catch { print ("Audio activation failed: \(error)") } }