Maybe you should include some code showing how you are doing this. As far as I'm aware, the default is to preserve whitespace. And maybe explain what platforms you're targeting. Apple provides a couple of higher-level XML wrappers, depending on your platform.

launchd agents can publish named XPC endpoints. I know enough about that to stay away from it. the system is able to relaunch a launchd agent that crashes. That might be useful. However, there is one important distinction. Can a Launch Agent be used in the Mac App Store? Login Items are explicitly allowed in the "retired" Mac App Store documentation. The current App Review guidelines only mention user consent. Is there a modern replacement for the old "Submitting o the Mac App Store" documentation?

I don't think "SharedSupport" is the appropriate place. The legacy documentation says that this location is for "additional non-critical resources that do not impact the ability of the application to run". Unfortunately, I think the legacy migration documentation is wrong because it explicitly says to use the "Resources" folder for executable code. Don't do that. Here is the current documentation. None of that is really what you're asking about, but I think it leads up to it. Typically, launch agents are single-file executables. I'm not familiar with the taskinfo tool or its output. But what it says makes sense. A Launch Agent would run with a user space UI role. That's how Launch Agents work. That's not the same as a Launch Daemon that runs as root and does not require a login session. When I look at how most other apps handle these things, what you're describing sounds more like a Login Item. A login item would live in "Contents/Library/LoginItems". Of all the apps I have installed that contain items in "Contents/Library", virtually all that contain bundled apps have them as Login Items. So I recommend you treat this thing as a Login Item. (Note that I mean a newer Service Management Login Item, not the really old school Login Items meant for end users). It's only recently that Apple added the ability to bundle Launch Agents and Daemons inside an app bundle. In a modern app, I'm not really sure what the difference between a Login Item and a Launch Agent would be. They seem to perform very similar roles. I guess a Launch Agent would be able to use some of the plist config file tricks that a Login Item would probably have to code manually. I can tell you that I have a couple of apps in development that will contain some background functionality and I plan to use Login Items rather than Launch Agents.

What are those compiler issues? There is very little difference between Xcode 15 and Xcode 16. It shouldn't cause that kind of problem. Plus, Apple now requires Xcode 16 and building against the current SDKs for submission to the App Store. So unless you are distributing this project through some other means, then you have no choice. Otherwise, you can always install a VM, or roll back to an earlier OS version.

Is there a way to package the Java code to work on iOS and mani macOS without having to complicate the project to the point where it would be easier to rewrite the Java code in Swift and have to work harder to update the app on each platform separately? No, there is not. Perhaps this would be an opportunity to try an AI solution to translate from Java to Swift.

I would handle the "permission denied" error by postponing the sync until the unzip has completed, which is the question I'm trying to find an answer to. Unzipping is a good test case, but there are other operations that could trigger the same problem. The end user could act as root and create an unreadable directory, leaving it there forever. Unless this is an operation that you initiated, with a reliable completion mechanism, then there is no way to tell when it completes. Maybe the user runs out of disk space, or the file is corrupted, and it never completes.

In my app the user can select a source folder to be synced with a destination folder. The sync can also happen in response to a change in the source folder detected with FSEventStreamCreate. First of all, these are two radically different use cases. Once the user is doing something, then you can use file coordination to have (hopefully) some control while an operation is occurring. With file system events, you are simply getting a notification about something that happened at some point in the past. The only real similarity here is that the file system is out of your control. Whatever you're doing, you have to account for unexpected changes to permissions, additions, deletions, etc. Unzipping is always a good test because it exercises all of that. The short answer is that there is no answer. File sync is a hard problem, in a mathematical sense. There's nothing wrong with a little delay. That is how FSEvents work, after all. But a delay doesn't solve anything, it just makes the higher-level logic a bit more manageable. When dealing with file system operations, and especially file system events, there is no real concept of "failure". Your sync simply can't ever fail unless the entire hard drive controller goes up in smoke. Lower-level failures from the file system will be a regular occurrence, as in every few seconds. You simply have to handle them. Another trick you can do is to take a snapshot of the directory you are working with. By that I mean just creating a representation of the directory tree in memory the way it is in the file system. (Just the file system, not the data) File coordination might help here. Then you work from that to do your sync. But this too is just a convenience. You have to expect that when you're working through the tree, the on-disk representation can radically change, or go away altogether.

I've been noting a sporadic crash in my apps, with completely different code, but the exact same "hash_table" crash. None of my code is listed anywhere in the backtrace.

That's part of the accelerate framework. You have probably defined some macro that taking effect before the header is included.

I was using CATiledLayer a few years ago. I don't recall any flashing bug, but it was a while ago. Those two external references you mentioned are both over a decade old. Maybe look at this project instead: https://github.com/Siclo-Mobile/SCTiledImage It seems at one point 5 years ago I opened a DTS asking Apple for help with CATiledLayer on macOS, referencing the above project. However, I closed the request a couple of days later saying I had figured it out, whatever "it" was. I can tell you that I'm not using CATiledLayer anymore. At some point, I moved on to using Core Image. Then I even abandoned that for the most part. Now do most work directly in Metal. I'm sure that my work with CATiledLayer and the Core Image equivalent helped me to better understand the problem space. Development of a complex app is not necessarily linear. You may ultimately require capabilities that CATiledLayer simply can't provide. But then you might not. Maybe if you explain what your app is trying to do, at a higher level, I could be more helpful.

I'm not sure how I am supposed to solve an issue which I am unable to recreate. You could start by explaining this in more detail. I have absolutely no clue what you're talking about. A countdown feature? For what? An analogue clock? A digital countdown timer? A display timer? A background timer? An NSTimer? device id and all others go through ??? What do you mean by device id? What is the significance here? What are "all others"? What kinds of trials and tribulations are they all going through? And last but certainly not least, code samples?

I haven't tested anything Swift on Ventura, but Xcode seems happy enough to build Swift 6 with a Ventura minimum deployment.

It seems pretty straightforward. When you re-wrote the app to the bare-bones version, you didn't re-create whatever error you had done in the original.

If you're new to Xcode, it would be better to start with a basic project template instead of Metal-cpp. Metal-cpp is an advanced topic. You don't need that to use Metal. Just write your code in Swift instead.

Just use unicode characters for 🐒🦜🐁 emojis right in the source code.