For me, using macOS 10.15.6 beta on a MacBook Air, the answer by @teddy06550 was close, but the actual example was simpler. Weird. Teddy's second command failed: Air2:~ jk$ sudo tmutil deletelocalsnapshots 2020-06-15-002518.local Password: 2020-06-15-002518.local is not a valid disk So instead I did what it implied I needed to do: Air2:~ jk$ sudo tmutil deletelocalsnapshots / Deleted 2 Time Machine local snapshots for volume group containing disk '/' com.apple.TimeMachine.2020-06-15-002518.local com.apple.TimeMachine.2020-06-22-183122.local and, voila… Air2:~ jk$ tmutil listlocalsnapshots / Snapshots for volume group containing disk /: Air2:~ jk$ No more local backups. Side note: Before doing this I had 89 GB available, 73.33 GB purgeable and the installer said I had only 16 GB available and needed 34 GB more. After doing this, I have 159 GB available, 73.33 GB purgeable and the installer says I have 86 GB available and it is ready to go. Well, indeed 159-73=86. So it looks like the space used by Time Machine and the space used by "purgeable" are different issues. By the way, think I know how I got so much in Time Machine local backups. During the last few months, I have created a half dozen or so screencast videos using Screenflow, which is an ( excellent) document-based app. Some of them may have been left dangling because I did not want to save them and force quit. That may or may not have made the problem worse. Anyhow, thanks very much to Teddy for the tmutil tip. I think this is a bug – that Time Machine local backups can use such a huge amount of space with absolutely zero visibility. Am I wrong or should I file a bug? Or maybe is this fixed a Big Sur?

alarouche, you must (1) install the Xcode 12 beta and then (2) select it. For example, if you have installed Xcode-beta into /Applications, sudo xcode-select -s /Applications/Xcode-beta.app After performing these two steps, then the command shown in the WWDC video xcrun safari-web-extension-converter /path/to/my/extension/folder will work.

Thank you, Timothy. Done. Please refer to FB7829688.

I tried some more ideas, but still not working. First of all, I added a dummy property to the "worker" object which does the work whose progress I need to display. The dummy property is published and observed by the List view, and updated every time any of the doneness values are updated. So now my body() method runs, and I also put the value of this dummy property and the value of foo.doneness in the title of each 'ProgressView'. Result: Now my body() method runs whenever any progress is updated, and the value of the dummy property in each progress view's title updates as expected. But, although the foo.doneness values are definitely being updated (I print the new values to the console in the "worker"), the very same calls, foo.doneness, inside that body() method, as seen in the progress view's title, are stuck at 0.0. In other words, this body() is stuck at the initial value snapshot, definitely not observing any changes. I also tried adding a willSet to Foo.willChange, manually sending objectWillChange as shown below, but this does not help either: @Published var doneness: Double = 0 {     willSet {         objectWillChange.send()     } }

Well, realizing that I am apparently on my own here, I devised a workaround. Instead of publishing progress values via the non-managed property doneness which I added to Foo, I removed that property and instead publish progress values via an Array property of the "worker" described in my previous post. I suspect the problem is that, as has historically often been the case, NSManagedObject has some special behaviors which cause some customizations by subclasses to fail. In this case, it may be that NSManagedObject has a specialized publishing mechanism which excludes its usage by non-managed properties.

The fix for me was to visit Apple's Developer Downloads page - https://developer.apple.com/download/, download and then install, actually re-install, the beta "Profile". After that reinstall, I did a Check for Update and, voila, I no longer get Unable to check for updates – No available updates found. Please try again later, but instead got the invitation to install Beta 2. Interestingly, today, it is again giving me Unable to check for updates – No available updates found. Please try again later. I see from that Downloads site that Beta 3 is not available yet. But because it is unable to check, I suspect that I will need to do the same trick to get Beta 3. We shall soon find out! By the way, I did report this to Apple, FB7869180. Indications are that this is known, widespread issue that is being worked on.

Thank you, GabeJones. It worked for me too. After failing with this error as described in the original post 5-10 times today, updating to Xcode 12 Beta 2 solved the problem.

Thank you for thinking about this, @Etresoft. I did not set the Bundle Identifier in this project. It must have been generated by Xcode based on the names I entered into the File > New Project sheets. To find out, I just looked in the Info.plist of the exported notarized .app which exhibits the incorrect behavior. Key CFBundleIdentifier has value com.myCompany.MyApp, as expected. It is not com.myCompany.MyOtherApp. Going further, I searched the project for the string MyOtherApp. As expected, zero occurrences were found. Thinking about this further, maybe I created some kind of developer signing identity, certificate or profile when creating MyOtherApp which is somehow leaking into this new app because I neglected to create the same for it. My experience is limited to signing and, recently of course, notarizing Developer ID apps using the command-line utilities, overwriting any codesigning by Xcode. I have never submitted an app to the Mac App Store. So you seeI have never been motivated to try and understand developer signing identities, certificate, profiles, etc., and that is likely where my problem is. Or a bug in Xcode? I forgot to say that I am using Xcode 12 Beta 5.

There is more @Etresoft. You also stated that this might be due to some mysterious hidden crap on my Mac. I was at first incredulous that Mac developers normally test their apps on a virtual machine to avoid trouble, since I have never done so in all my years of developing nonsandboxed apps. So it was not until today that I dragged the troublesome product to a different Mac and tested. To my amazement, it worked! There is more. I use the Finder alternative, Path Finder, a third party app. I just noticed that when I execute a menu command in Path Finder which should open a window to my Home folder, Path Finder instead opens a window to the same MyOtherApp container whose path NSHomeFolder() returns to my new app. In other words, Path Finder has the problem as my new app. Interestingly, though, Finder's menu command Go > Home works correctly. One more test: I tried running the troublesome app in my "test" user account on this Mac, and it works fine in the "test" user account. Well, all of this raises more questions than answers. But now I where the problem lies. Next stop: A restart?!?!?!

Update: Well, after a day or so I realized that other apps on my computer were behaving incorrectly also, so I peeked into that /Users/me/Library/Containers/com.myCompany.MyOtherApp/Data and, sure enough, found that a dozen or so other apps had been putting their data in there too. Presumably any app which had used NSHomeDirectory(). Restarting the computer solved this problem with my new app, and all of the problems with all of the other apps. I think that macOS is getting too complicated for Apple to handle it :(

I found the problem. I forgot that I had Audio Hijack (software by Rogue Amoeba) installed, and I had not used it in a month or so. So I launched Audio Hijack, after about 10 minutes of beachballing, a dialog advised me that I had version 3.8.0 and needed an "Urgent" update to 3.8.3. After doing so, and further following the prompts to install Rogue Amoeba's new Audio Capture Engine (ACE) system extension (or whatever it is) that comes along with Audio Hijack, the problem is solved. Apparently the old ACE was the cause. Thanks for the quick fix, Rogue Amoeba!

Not really a solution, but here is what happened. Before I begin, I'd like to say that, after my original post, I submitted FB9103124 to Apple on May 11, but there has been no response. Sadly, here we are. Support requests have begun to come in from my users also. There are actually two issues. Full Disk Access is summarily disabled for all non-Apple apps which previously had it enabled. Helper Tool no longer inherits Full Disk Access from parent app. Issue (1) is of course, just very annoying to users who must visit our web pages or email us to find what the @%*#! happened, and we need to apologize on behalf of Apple. Issue (2) kind of went away by itself for me. It may have been that I had two useable versions of my app on my computer. After deleting one of them, and restarting a couple times, the remaining the FooAgent had Full Disk Access again, and eventually its inexplicable checkbox in System Preferences Security & Privacy Full Disk Access disappeared. I may have a few users with the more serious issue (2), so I'm just telling them to look for other versions, restart, etc. Yes, it is a sad day here for the Mac.

Until Full Disk Access was introduced, my app had packaged in it a daemon process, launched intermittently by launchd, with the user's privileges. When Full Disk Access was introduced, after many hours of experimenting blindly (no documentation), I concluded that there was no way for this process to have Full Disk Access. To solve the problem, I discarded it and rewrite its functions into a constantly-running Service Management Login Item.

Well, on the support page which I created for users experiencing this issue, after explaining how to re-enable Full Disk Access, I said that if it still does not work for you, try throwing the kitchen sink at the Apple, as follows: • Watch for our Agent in Activity Monitor by filtering on its process name. • Command our parent app to switch off our Agent. • If one or more of our Agent processes still appears in Activity Monitor, Quit or Force Quit. • If our Agent process keeps reappearing, restart. • Delete any other copies of our app. • Verify that you've got zero of our Agent processes running. • Quit our app if it is running. • In System Preferences … Full Disk Access, switch the checkbox for our app OFF and then back ON. • Launch our app, command it to start our Agent, and see if it has Full Disk Access now. So far, one user who reported that simply re-enabling Full Disk Access did not fix this issue has said that subsequently throwing the kitchen sink at the Apple fixed it.

At first, I thought that this issue was fixed in macOS 11.5 Beta, because my background agent was getting Full Disk Access without being listed in System Preferences' Full Disk Access list. But, then, and I don't know what I did other than build another new version of my app the other day with Xcode, my helper lost Full Disk Access. Actually, it is even worse than before, because now throwing the kitchen sink at the Apple does not fix it on my Mac. Also, I have had two users report that throwing the kitchen sink at the Apple does not fix it for them, although, for dozens of users, either just re-enabling Full Disk Access for the parent app, throwing the kitchen sink at the Apple does seem to fix the problem. Mercifully, so far, my computer is the only one which has reportedly had the issue recur after it was "fixed". But I can imagine all hell breaking loose worse this time if Apple releases macOS 11.5 without fixing this, or at least telling developers what they need to change in their apps to make them work again.