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.

is it known issue for Apple team? No. Nobody uses iOS 12 anymore, so nobody knows of any issues when it runs apps built with Xcode 16. In Xcode 16, I can't even set a deployment to anything earlier than iOS 15. to resolve this issue, what can we developers do? You can drop support for anything before iOS 15, or Use an older version of Xcode.

It is but not totally out of the ordinary. It is totally out of the ordinary. I would like to be more "mac arsed" in my app development. I don't know what that means. It might be helpful to remember that the entirety of the macOS platform is an outlier. It constitutes 8% of Apple's sales, and probably a smaller percentage of profit. Apps run on iOS. If you're flush with cash and have time to burn, maybe you can play around and port your app to the Mac. But ain't nobody going to be using any command-line arguments. I'm also aware that there is a potential conflict with things like using -AppleLanguages to change the language an app is launched in so there is some pre-processing going on by the OS that is parsed before an app is launched fully but again That's a debugging flag. The Cocoa/AppKit frameworks do some parsing of command line arguments. However, they do that as part of NSApplicationMain(), which takes over completely. There also exists an NSApplicationLoad() that command-line apps would typically call so that they can use most Cocoa/AppKit system functionality, or maybe construct their own run loop. --args is available to be used, whatever macOS is doing should be able to handle that and just pass through arguments array into the app. --args is just an argument to the "open" tool. And it works fine, as do command line arguments if you run an app directly. I don't know what problem you're having, but it isn't any kind of system-wide problem and isn't related to any Xcode version. I don't want to discourage you. Clearly there is something very wrong with your setup. It would probably be worthwhile to find out what's causing the problem. Command line arguments are irrelevant. But there is a risk that whatever is going wrong could affect some important functionality. Virtual machines are useful for testing code. But I wouldn't recommend installing Xcode in one. Xcode is for a real machine. But also, once you install Xcode on a real machine, it isn't a real machine anymore. It's now a "developer device" whose behaviour may not be the same as an end-user's device. Virtual Machines can be useful as a quick-and-easy end-user, non-developer device. Ideally, you would also test on a real machine that has never had Xcode installed. You had mentioned that "my device is corporate owned so has MDM enrolment, AV, and other paraphernalia". I strongly encourage you to focus your attention there. Don't forget the network either. Your corporate network is probably also non-standard.

It would help if you could clarify some things. First of all, passing arguments to an app is very unusual. I support it in one of my apps, but I'm pretty sure that virtually no one has ever used that feature. There was also a recent thread here where an Apple engineer suggested that command line operation may be incompatible with linkage of UI frameworks. Add to that the fact that you are doing something with UIElement. Plus, you are running all this through the "open" tool. Does it behave the same if you directly launch the executable with your arguments?

I never said anything about anyone making any accusations. You posted your website and within a few seconds I could see there was more than one other website with an identical name.

I followed your instructions to the letter and it worked perfectly every time.

We are just other Apple developers. We don't know who you are or who owns the smarden.io website. Both are anonymized. There are other organizations that use the "smarden" name. At least one of them has a web site that is six years older than yours. How is Apple to know who really owns the rights to the "smarden" name? Apple isn't going to do that research. You will have to do the research yourself and submit documentation that confirms your global ownership of the name.