If you think the behaviour of the system is wrong, file a bug report. Just don't assume there is any security in the pasteboard.

It's better to respond with a reply. I just randomly checked some of my old replies to look for comments and found this. I'm not sure what you're asking. It may be just a bug with clipboard history in Spotlight. Isn't that still in beta? When you added those strings (deprecated by the way) to the declared types list, that might cause spotlight history to omit this information. But there's definitely no kind of data security going on or anything. You put something on the pasteboard, it's there for all apps to see.

Wasn't that barely two days ago? The dot com glory days of instant enrolments is over. You should be prepared to wait weeks to months for most business-related issues. Dun & Bradstreet is actually one of the best companies in this respect. I got my DUNS number in 2015 and it took a week. I recently changed my address with them and that took about a week. Their estimate for completing the change was about a week. And they even send me a confirmation saying (in big red text) "Your updated DUNS number will be eligible for Apple Registration after 24-48 hours". So really top-notch. Kudos to Dun & Bradstreet. Since you are doing a new number, you may have to wait longer. And there is no guarantee that new numbers will be processed in that same 24-48 hour timeframe. And there is no guarantee about when Apple will recognize the number. I think the rumours ten year ago were two weeks. I suggest waiting a month after confirmation from Dun & Bradstreet.

It should like you should be building a table view instead. A table view optimizes this by reusing a single NSTextField. After all, a user can only interact with a single text field at a time.

There are no "standards" at NSPasteboard.org. That's just somebody's web site. The pasteboard is not a safe place for confidential data. Any data put into the pasteboard should be assumed to be permanently recorded in plain text in some very obscure locations, possibly shared with local devices, and depending on 3rd party apps, shared in the cloud.

Aren't new features the same as enhancements? Usually the delicate part is bug fixes. Those would get applied to older, currently shipping code. You could do them either in a branch or in main, but the idea is that, one way or another, bug fixes will relatively quickly update the main branch. Then the delicate part is making sure that any pending branches are compatible with those bug fixes. In theory, since they're still pending, that's easy to do. At that point, you know about the bug and can fix any new code, while merging the fixes in the new main. But it's all based on what you're comfortable with and what you can manage. Working as a lone developer, I wouldn't do a new branch for anything unless it was going to require weeks of effort and/or substantial changes/extensive testing. But back in the day, with 600 developers on a project, everything went into its own branch and the SCM team managed that. Testing was no big deal because we had a very large testing group and months-long test procedures.

I think the problem there is that ".weekOfMonth". When you combine that with ".day", there is some internal uncertainty about when a week or month can be considered to have elapsed. You're just hitting an edge case. The documentation suggests using Date.RelativeFormatStyle instead. When I try that with your code, all days return just "2 months".

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.