You should keep the main branch as close as possible to the current shipping code. That way, if there's some emergency issue, you can quickly fix it. You only want to merge new code into main when you're ready to issue a major update, or just after you've done so. And make sure to tag the any released code. Do new features and enhancements in a new branch. The larger the organization, the more likely they would be to have many new branched, one per feature, and merge them one at a time. But as the organization gets smaller, that becomes less necessary and too much work to manage. You'll have to find your own sweet spot.

The OP wants to use the FamilyControl entitlement. The request page requires a purchased membership to access. I'm not familiar with this feature, but it doesn't sound like something that a developer could just turn on for debug builds. Maybe you could in the simulator? From said request page, it looks like one would have to have the app ready first and then request the entitlement. And most importantly, it's just a request. Judging from other people's experiences, these requests can take from 2 days to 4 months to be accepted, and possibly rejected.

Then you'll need a user interface to select the socket file. The temporary exception never would have worked anyway. App Review would have shot that down. And what if the user has a custom Docker configuration? You should still keep App Review in mind. Ideally, your app should function normally and do something meaningful even if you haven't selected the docker file. If you require selecting the docker file to run, then you may have problems with App Review. I'm not saying it's impossible. But there's a good chance that, with each submission, you'll have to explain the whole background of Docker, how it works, how Unix domain sockets works, and why your app must have access to this file. App Review is going to look at this from the perspective of dozens of other apps that try this excuse in order to directly access people's personal information. So in your UI, include a little explanation of the above. You can assume that your users know a little about Docker/Unix. But point out that they must select the actual socket file. Technically, this would work if the user selected the root or the user home directory, but if you disallow choosing directories, then you've made it clear to both the user and App Review that this is a safe operation. No guarantees, of course. But the more work you do up-front, the less you'll have to explain if you get rejected now or at some random date in the future.

That's an inherent problem with attributed strings. Should they appear as the current appearance or as specified by the attributes? There are valid reasons for either approach. You are assigning a font attribute both to the text view and the attributed string. If you remove the attribute from the string, then it might work as you want. Sometimes attributed views can make sense of partial attributes where the text colour is defined by the system appearance, the font is specified as a dynamic type on the view, and the style is defined in the attributed string itself. Alas, no guarantees. In some cases, you have to hack it. Apple provides the UIFontMetrics class so that you can manually scale things along with dynamic type.

There, that's better... I'm unaware of any difference between admin and standard users with respect to these kinds of permissions. Your description of the behaviour when installed in a standard account is how I would expect these apps to function normally. I think the most likely explanation is that most users (and developers and testers) use admin accounts and they haven't made a habit of resetting these permissions to test onboarding and initial setup. Full Disk Access is sometimes a solution. But that isn't a meaningful improvement over the default process. The user still has to manually go into System Settings. And in some cases, when people try to run these tasks as root, it can make these problems even more difficult. The root cause is attempting to use separate backgrounds tools. Why not just put all of the logic into the UI? Or take that further and make your app more stand-alone, with the plug-in being less important? I'm afraid there aren't any ways to technically work around the problem. The user has control. So rather than fight the system, look for different ways to engage with the user. Since your app isn't distributed via the Mac App Store, you have lots of options.

Tasks are cooperative. Cancellation is just setting the isCancelled flag. It's your responsibility to handle the cancellation. You can check the flag and exit early, call checkCancellation() to throw an exception, add a cancellation handler, etc. But unless you do something specific to detect and respond to the cancellation, a cancelled task will just keep running as if nothing has changed.

[quote='849503022, Baylward, /thread/793561?answerId=849503022#849503022, /profile/Baylward'] the 'Summarise folder without permission' button does NOT work, so there doesn't seem to be any implicit "start" [/quote] I'm sorry, but I don't know what you mean by "does NOT work". Is it throwing an exception? Or failing in some other way? What is the specific context of this "failure"? You aren't checking the result of startAccessingSecurityScopedResource(). So then you are calling stopAccessingSecurityScopedResource() based only on the permission value, which is wrong. You should only call stopAccessingSecurityScopedResource() if startAccessingSecurityScopedResource() returns true. [quote='849503022, Baylward, /thread/793561?answerId=849503022#849503022, /profile/Baylward'] Strangely running the identical code on a simulator DOES work, which I also find confusing. [/quote] That part's easy enough. Whenever there is a discrepancy between the behaviour of the simulator vs. a real device, the simulator is always wrong. [quote='849503022, Baylward, /thread/793561?answerId=849503022#849503022, /profile/Baylward'] errors occurring when accessing hundreds of URLs, each bracketed by the accessing calls [/quote] I don't know how you're ever going to get hundreds of URLs on iOS. Normally, the user selects a single URL. If you are loading and saving bookmarks, you're probably only doing that for a few URLs at a time. It makes sense to put the accessing calls at a higher level of code. That way, when your lower-level code accesses the contents, perhaps with hundreds of URLs, you don't have to worry about any of this. Those are then just regular 'ole URLs. [quote='849503022, Baylward, /thread/793561?answerId=849503022#849503022, /profile/Baylward'] my main concern is that the code doesn't seem to be behaving as expected from the documentation, and I don't understand why! [/quote] As I said, the documentation is very explicit about when these accessing calls are required. You only need them when loading from a security-scoped bookmark. In your case, because you need them when loading from a security-scoped bookmark, they work, even though you aren't using them correctly. In this case, it just so happens that startAccessingSecurityScopedResource() returns true and then your call to stopAccessingSecurityScopedResource() also works. But then when you use them incorrectly in the case where you don't need them, they fail, because you haven't checked the result of startAccessingSecurityScopedResource() and you call stopAccessingSecurityScopedResource() when you shouldn't. My recommendation is to simply use the API correctly and then everything works. That way, your lower-level code never needs to know about any of this. Your code is also portable across other Apple platforms like macOS where these bookmarks behave differently. And your code is more robust because it will then work regardless of where the URL came from. You can use the same business logic for a URL read from a file or defaults, or selected by the user.

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.