It's going to be a big challenge to port an existing project to SwiftUI. What you describe makes a lot of sense. Most people never encounter this error anymore because they are starting small, with a new project. That being said, you specifically said that you were "porting a project over to iPhone". I don't think trying to do that kind of massive port from a foreign architecture is going to be any more pleasant in UIKit. I recommend starting small, with a new project. Build the bones of your UI to match the old project. But don't attempt to port the entire thing at once. Follow the path of least resistance and write the code the way SwiftUI or UIKit expects.

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.

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

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.

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?

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.

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.

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

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.

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.

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

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 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.

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

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.