I have a large old macOS app project (15 targets, 15 years old) in a workspace. It was building fine until yesterday afternoon, when I attempted to do a Git Stash in Xcode. This caused Xcode 16.1 Beta which I was using to crash, and after that this Xcode crashed on launch. Trying Xcode 15.4, 16.0 Beta 6 and 16.1 Beta, in macOS 15 Beta, the only Xcode I can get to launch now is 16.0 Beta (further details of that are available upon request, but not my problem at this time). My current problem is that the first Build task, Package Resolution, now fails with this error message: Failed to resolve dependencies Dependencies could not be resolved because root depends on 'swift-argument-parser' 1.3.0..<2.0.0 and root depends on 'swift-argument-parser' 0.4.3..<1.0.0. Indeed, the project has a Package Dependency on swift-argument-parser 1.3.0 < 2.0.0. But I have no idea where Xcode is getting the other version string "0.4.3" from. And I don't know what "root" is being referred to, and whether or not it is the same "root" in both clauses of that error message. I have searched the relevant .pbxproj file, and indeed the whole project folder using BBEdit's Multi-File Search, and it could not find the text string "0.4.3" in this context anywhere. Where might that "0.4.3" be coming from? Thank you.

My AppleScript .app bundle contains a helper executable. Table 3 of TN2206 says that executables may be in either Contents/MacOS or Contents/Helpers, but Quinn's first reply in this post says that Contents/MacOS is better. So I put the helper in Contents/MacOS, alongside applet. I sign the AppleScript .app bundle for Developer ID and Hardened Runtime by running the codesign command with arguments recommended by Quinn in this post. Result: Notary Service rejects the .app bundle due to 3 issues with the helper: is not signed with a valid Developer ID certificate does not include a secure timestamp does not have the hardened runtime enabled (Possibly it still has a years-old signature without Developer ID and Hardened Runtime). So it seems that the the helper is not being (re-)signed. If, instead of signing the .app bundle, I run Quinn's codesign comand twice, once on the applet and once on the second executable, then Notary Service is happy with the bundle. I was hoping that, after all these years, codesign is now smart enough to find and sign all of the executables inside a bundle. Both executables are x86_64 non-fat (I guess I should fatten those) and I have installed Xcode 15.1 Beta. Should I file a bug, or am I doing something wrong?

Ever since the update to macOS 11.4 Beta 3 two days ago, I have been going through hell trying to maintain Full Disk Access for my apps' background agents. I think something has changed with Full Disk Access, and I am very worried that the upcoming release of macOS 11.4 is going to break it for my users. BACKGROUND Because of open issues FB5929825 and FB7772296, my notarized macOS apps require Full Disk Access in order to access Safari bookmarks using a Apple private API. That works OK for the parent apps, but maintaining Full Disk Access for my apps' background agents has always been problematic. Before Full Disk Access became a thing in macOS 10.15, my apps' background agent was a command-line tool, shipped within my apps' bundle, and launched intermittently by launchd tasks. Testing in early betas of 10.15, I could not find any way for a command-line tool to get Full Disk Access. (This may have been fixed in later versions.) Copying the design I saw in another app (Arq Backup) which had a working background agent, I spent several months replacing my command line tool with a Service Management Login Item which runs constantly. For brevity, I shall refer to my Service Management Login Item as "FooAgent". Since then, users have been granting Full Disk Access to my apps after initially installing. The enclosed FooAgent apparently "inherited" Full Disk Access from the parent app, and all was well. I have never seen any documentation that this is by Apple's design, but it worked. But, two days ago, upon restarting after the update to macOS 11.4 Beta 3, in addition to the fact that System Preferences' Full Disk Access checkboxes had been switched OFF for all non-Apple apps on my M1 MacBook Air (FB9103124), FooAgent emitted a warning that it did not have Full Disk Access, and this repeated even after I switched on the two checkboxes labelled "FooAgent" which had appeared in the Full Disk Access list and relaunched FooAgent. Through some combination of this action, removing a previous build of FooAgent, and restarting twice, I was able to restore Full Disk Access yesterday. But today, after rebuilding my app, which includes a rebuild of FooAgent, upon launching, FooAgent again reports no Full Disk Access, and today there are zero checkboxes for FooAgent in the Full Disk Access list. I beg someone from Apple to please answer for me: What is the correct, supported means by which a Service Management Login Item, contained within a parent app, can acquire and maintain Full Disk Access? Is it now necessary to re-grant, for testing, Full Disk Access after every build or update in the field? (Please, please say "No".) Is a Service Management Login Item which is contained within a parent bundle supposed to have its own entry and checkbox in System Preferences' Full Disk Access list? BONUS QUESTION. Please, God, is there any chance that FB7772296 will be fixed in the next version of macOS, so I that can stop using Apple private API and stop requiring this Full Disk Access?

Since Apple withdrew the API for accessing Safari bookmarks ten years ago and is still working on a replacement API (FB5929825 and FB7772296), my macOS apps (Notarized Developer ID) have accessed Safari bookmarks via an XPC service which links to /System/Library/PrivateFrameworks/Safari.framework. Doing this requires that the XPC service' Build Settings have the following Other Linker Flags: -weak_framework Safari -Wl,-dyld_env -Wl,DYLD_VERSIONED_FRAMEWORK_PATH=/System/Library/StagedFrameworks/Safari (The above is complicated by the fact that the target Safari framework can sometimes be in a staged framework depending on Apple's development cycle.) Anyhow, upon trying to build with Xcode 13 for the first time this morning, I found that the Ld command fails when linking my XPC service, emitting this error: Undefined symbols for architecture arm64:   "_OBJC_CLASS_$_WebBookmarkList", referenced from:       objc-class-ref in SheepSafariHelper.o ld: symbol(s) not found for architecture arm64 The class WebBookmarkList is indeed defined in the Safari private framework and is apparently the first such class that it attempts to link to. I know that Safari framework is still there, because my app still builds and links with no errors in Xcode 12.5, and runs OK in macOS 12. (I am running both Xcodes in macOS 12.) Does anyone know what changed in Xcode 13, and is there a workaround?

Because we are still anxiously awaiting the documentation on the workings of the whitelist in System Preferences &gt; Security and Privacy &gt; Full Disk Access (previously Application Data in earlier betas), I report the following experimental results with macOS 10.14 Beta 7 (18A365a): [Edit 2018-08-22: Beta 8 seems to be the same.]If I click the + button under the whitelist and enter my .app, it gets access as expected, but only if it is located in /Applications, and not attached to by lldb (not running in Xcode).Even if the full path to a command-line Helper tool which my app contains (/Applications/MyApp.app/Contents/Helpers/MyHelper) is explicitly entered into the Full Disk Access list (*), and it appears in the whitelist separately from my .app, this command-line tool will be denied access when it runs. (Access worked in macOS 10.14 Beta 3. Beta 4 broke it.)After I similarly enter /Applications/Arq.app/Contents/Library/Arq Agent.app into the whitelist, overnight backups in the background by the backup app which I use, Arq, start working again.If I have one copy of a .app already entered into the whitelist, and + add another copy, the whitelist silently remains the same, showing only one entry for the duplicated app. (Unfortunately, the whitelist does not show an item's path in any way – no tooltip.)Therefore, I conclude that, in order for a executable to be granted Full Disk Access, it must be…the main executable of a whitelisted .app, although it is OK for this whitelisted app to be a helper/child of another app, located in the parent app's Contents/Library.not attached to by a debugger.located within /Applications.Although whitelisting a certain .app will enable its main executable and any child processes, it will not enable a helper/child app when the helper/child is launched by others in the background. The helper/child must itself be explicitly present in the whitelist.* * *If anyone can confirm, deny, or elaborate on these conclusions, I would really appreciate it. There is maybe only four weeks to go, and it appears that I have a lot of work to do. Was the breaking of command line tools in Beta 4 intentional?(*) To enter a helper component such as this into the whitelist, because the navigation sheet presented by the + button will not navigate into .app packages, the user must hit the + button, then ⌘⇧G, then enter the absolute path to the helper.P.S. to other developers: The new restrictions are apparently implemented with System Integrity Protection (SIP). You can still debug your app if you disable SIP 😟

Among other issues, the macOS 11.3 Beta (20E5172i) has killed the Sound Output from my M1-based MacBook Air. Please someone look at the sysdiagnose attached to Apple Feedback Assistant FB8995037. Since updating this morning, my Mac has made no sound. Any app which is supposed to make sound makes no sound. A YouTube video in Safari took 30 minutes to load, and is now playing at maybe 1/15 of a frame per second with no audio. Clicking in System Preferences > Sound results will typically beachball for 10-30 minutes, and sometimes then present a dialog: “Preferences Error – Sound Preference Pane could not be loaded.” I have a Yeti "Blue" USB microphone which has a headphone output. The Yeti was connected, and, prior to the update, the Yeti's headphone output was set as my default Sound Output device. Things I have tried: • Restarted multiple times. • Disconnected that Yeti microphone that has the headphone output. • Disconnected all external hardware – no cables of any kind. • Removed all third-party preference panes. (I had four: Sizzling Keys, SANE scanner, ChronoAgent, Flip4Mac.) • Moved ~/Library/Preferences/com.apple.soundpref.plist • Moved ~/Library/Preferences./com.apple.systemsound.plist

I wrote a little macOS troubleshooting utility which I need to send to a few users. I don't want it sandboxed because I it needs NSHomeDirectory() to return the user's real home directory, /Users/me. In the app target's Signing and Capabilities tab, I removed App Sandbox. When I test the app running in Xcode, NSHomeDirectory() returns /Users/me as required. After the app worked to my satisfaction, I clicked Archive, then Upload for notarizing, then Export. The spctl tool assesses the exported, notarized app product as Notarized Developer ID, and upon running, in Activity Monitor, the Sandbox column reads No. However, this product does not function correctly because NSHomeDirectory() is returning the following path: /Users/me/Library/Containers/com.myCompany.MyOtherApp/Data wherein MyOtherApp is the name of the last sandboxed macOS app I started developing a couple months ago. ARGHHH!! Where in the world did it get that? I definitely started this as a New Project. In the Build Settings, I have Code Signing Style = Manual Code Signing Identity = Developer ID Application But I have also tried: Code Signing Style = Automatic Code Signing Identity = Apple Development Either way, upon executing Archive-Upload-Export workflow and testing the product, it has this same problem. Note: I've never used Xcode's built-in workflow for Developer ID before, due to issues when Apple first released it. I wrote and since 2012 have been using my own script instead. But yesterday I thought I would try Xcode's built-in workflow because I read that Apple has fixed the issues over the years. Have they? What have I done wrong?

Sometimes when an new, unexpected error, hang or deadlock occurs during testing, one might want to stop the app in the debugger and poke around. To do this, in a AppKit app, one would ask for the singleton [NSApplication sharedApplication] by that symbol or the NSApp convenience, and then from there drill down into the app delegate, windows, documents, or whatever was interesting. How do I do that in a SwiftUI app which is based on App? Apparently, there is a single MyApp:App struct. How can I get the debugger on it and get its properties?

In my SwiftUI project, I have a List, with each row representing a Core Data managed object, of entity Foo. Each row's View contains a ProgressView(), which I would like to have updated magically by binding to this property @Published var doneness: Double which I have added to class Foo. The Foo class itself conforms to ObservableObject, thanks to inheritance from NSManagedObject. So, all the pieces are in place for SwiftUI magic to happen, except that I cannot figure out a syntax for wrapping the loop variable foo with @ObservedObject. This is, I believe, why my progress view is not updating – my body() getter does not get called as expected when a doneness value is updated. The loop variable foo is declared in the ForEach, line 12. How can I make these observable objects? I also tried to put the @ObservedObject wrapper on the array of foos, line 5, but the compiler did not like that either – Value of type 'FetchedResults&lt;&gt;' has no member 'wrappedValue'. @FetchRequest(entity: Foo.entity(), &#9;&#9;&#9;&#9;&#9;&#9;&#9;sortDescriptors: [], &#9;&#9;&#9;&#9;&#9;&#9;&#9;predicate: nil) var foos: FetchedResults&lt;Foo&gt; var body: some View { &#9;&#9;NavigationView { &#9;&#9;&#9;&#9;VStack { &#9;&#9;&#9;&#9;... &#9;&#9;&#9;&#9;} &#9;&#9;&#9;&#9;List { &#9;&#9;&#9;&#9;&#9;&#9;ForEach(foos) {foo in &#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;HStack { &#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;... &#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;if let doneness = foo.doneness { &#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;ProgressView(value:doneness) &#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;} &#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;} &#9;&#9;&#9;&#9;&#9;&#9;} &#9;&#9;&#9;&#9;} &#9;&#9;} }

In some applications, a Safari Web Extension must receive a Native Message and process it in the background, without activating Safari. For example, assuming that Safari Web Extensions will soon support the browser.bookmarks API - https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/bookmarks, when a bookmarks syncing application needs to push a new bookmark from a source of truth into Safari's bookmarks, it will send a Native Message to the extension, and this may happen when Safari is not the active macOS application, for example if the user is writing email in Mail. I am modifying Apple's Sea Creator - https://developer.apple.com/documentation/safariservices/safari_web_extensions/developing_a_safari_web_extension sample code to establish a proof of concept for such an application. So far, pretty good. I am able to send over 150 MB of data – far more than will be needed – from the app, to the extension's background.js script, and vice versa. However, it seems when Safari receives the message from the app, it activates – that is, it becomes the frontmost macOS application. This will not be appreciated by the user who is writing email. This activation seems to be triggered by something within Safari, because it occurs even if I comment out all of the JavaScript and HTML code in the extension. It occurs whether I send 150 bytes or 150 MB of data, although in the latter case it occurs about 5 seconds after the message is sent, indicating that Safari is apparently buffering the message or something before activating – even if the background script has no message handler because the call to addListener() is commented out. Should I file a bug with my minimal project, or have I overlooked some way to prevent this activation of Safari?

After years of using private API and not being in the Mac App Store, I was really excited Monday when I heard that Safari was adopting Web Extensions. Unfortately when I installed the betas and ran the converter on my Firefox/Chrome/Opera/Brave/Vivaldi/Edge extension, I was told that the browser.bookmarks - https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/bookmarks API was not "yet" supported. I have patiently filed many bugs on this over the years: 10473679, 22932240, 32608461, 49706819, and now FB7772296. Users want bookmarks management beyond what is offered in Safari, and some users want to sync their bookmarks with other browsers. Currently, there are others’ apps, and do-it-yourself users who try and do this by overwriting the Bookmarks.plist file, with disastrous results to their iCloud account. I hope that the omission of browser.bookmarks - https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/bookmarks from Safari Web Extensions was due to disruptions caused by COVID-19, and that Apple will soon state their intention to support the browser.bookmarks - https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/bookmarks API which is supported by Firefox, Google Chrome, Opera, Brave, Vivaldi and Microsoft Edge. Thank you for reading.