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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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

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.

If your app is 10 years old, then maybe you need to update your App Store logic. From what I understand, having a receipt is not 100% guaranteed anymore. So if that is your "history of purchases", you may not have it until the user clicks on the Restore button.

It's the same thing. A table view reuses all cell views. It simply takes some time to draw these user interface elements. You have to leverage the tools you have and the material conditions of the user interface. Chances are, the window is going to be too small to show all those views. So you only show what fits on the screen. Table views and collection views are optimized to do this. Then, when the user wants to see more, they can scroll. Any newly revealed portion of the view is going to have less content than the full thing, so this newly revealed content can be drawn in real time. If you're really living on the edge, there are even ways to cache overflows that that scrolling is smoother.