build disappears

[quote='800260021, danilabagroff, /thread/800260, /profile/danilabagroff'] I'm developing a macOS console application [/quote] “Console application” isn’t a term we use on Apple platforms. An application is, by definition, something the user double clicks in the Finder, shows up in the Dock, has a menu bar, and so on. I’m presuming that you’re building a command-line tool, something that the user runs from Terminal, or is run by the system as, say, a launchd daemon. Please let me know if that’s not the case. [quote='800260021, danilabagroff, /thread/800260, /profile/danilabagroff'] What is the recommended approach for debugging applications that need to load dynamic libraries? [/quote] There are a number of factors in play. I’ll come back to that later. But first I want to dig into your log message: [quote='800260021, danilabagroff, /thread/800260, /profile/danilabagroff'] Error Details When running the application through LLDB, I get this sandbox denial in the system log… logd_helper(587) [/quote] L

This is is going to be tricky. An app’s icon is part of its bundle, and thus modify the icon will break the seal on the code signature. You don’t want to leave the user with an app with a broken code signature because sooner or later Gatekeeper look at the app, notice the broken signature, and kvetch. Now, what you could do is something like: Build, sign, and notarise all the variants of your app. From those variants, construct an installer that only contain one primary variant of your app and the diffs for all the other variants. Have that installer install the primary and then apply the relevants diffs. The end result is an app that’s correctly signed and notarised, and thus unlikely to hit notary problems. However, doing this is quite a bit of work. The key problems is that critical parts of the code signature are stored within the app’s main executable Mach-O image. If you store the diffs as a list of files, you’ll need N copies of the main executable, which presumably is quite large. There are w

Hi, i attempted to use my macOS login password during the code signing process, but it was not accepted. My macOS user account is “greenvibe”, whereas the certificate prompt refers to “Or Itach.” Could this difference be the root cause of the issue? Should I create a macOS account under the name “Or Itach” using the same email address? As an additional note, after speaking with the Apple Support team I learned that the Apple Developer account under greenvibe33@gmail is associated with “Or Itach.” I reset the password for this Apple account and attempted the build again using the new credentials, but the problem persists. Could you please advise on the correct next steps to resolve this?

Yeah same here, just saw this broke our API code also. The content-disposition header disappeared from the response. Not cool to remove headers from a REST API. Removals like that should be done as a breaking change for a new version of the API.

This is still failing on the RC builds on Xcode Cloud. (both Tahoe and Xcode)

Hi Engineer, I also wanted to add that I can confirm that activityType .otherNavigation was always set via: @State var updates = CLLocationUpdate.liveUpdates(.otherNavigation) Recap: The device jumps 50 or more meters from the boat to a false location, often on shore giving a false warning. And later jumps back. The jump is also seen on apple apps such as findmy or maps. I have determined a way to detect these jumps by calculating the speed between two consecutive updates... if it's greater than 10m/s then it must be false, and we wait for a return. The device has a clear unobstructed view of the sky and no nearby buildings, and is slowly floating around. The app remains in foreground. Any further ideas would be appreciated. Kind regards, Brendan Thank you for your help again.

Unfortunately this seems not to work anymore. I remember it worked until beta 3 or so but now the returned NSImage object is just null Is the app icon set as the App Icon in the App Icons and Launch Screen section of the target building your app?

Thank you for the post regarding the issue you are experiencing with the URL structure in the Foundation framework. Based on your description, it is possible that the string you are using as an argument is evaluated at build time, particularly if it involves compile-time constants or conditions that are not resolved correctly. Could you please provide the code you are using? Is it something like this and returns nil? let testURL = URL(string: https://www.example.com) print(testURL) The more information you can provide, the better I can assist you. Please share the code you are using to construct the URL. Thank you. Albert Pascual
  Worldwide Developer Relations.

It does seem to be a permissions issue. If I revert back to putting the service in /Library/LaunchAgents and call SMAppService.agent(plistName: com.xpc.example.agent.plist) as demonstrated I can establish the XPC session and the code works as intended. That makes my claims of brokenness thoroughly, regretably invalid. It works, it's just not a complete example. Once I change the Copy File phase to throw the build product into /Library/LaunchDaemons and call SMAppService.daemon(plistName: com.xpc.example.agent.plist)instead (including passing the.private` flag when establishing the session), all the trouble begins. I manually did a chmod 600 and chown root on the service binary and the plist but launchd doesn't like that any better. I'm completely ruling out any .plist errors since I have not changed a single thing in that file and the same exact file works as a LaunchAgent. If I try to register the (root owned and non-group/world readable) plist manually then this happens: % sudo launchctl load /Appl