This is absolutely false. No patching has been done in the example I uploaded and included above. I built a NEW app bundle with all patches and notarized it. The problem still happens. Is this the version that prints out ";;; Installing ssl patch, version 3."? It's easy enough to build OpenSSL, create a demo program, and verify that it works. If it's not your patching system, then it's something else unusual that you're doing.

Your code works fine here: /tmp $ clang test.c /tmp $ ./a.out Enter value for A: 3 Enter value for B: 6 3.000000 + 6.000000 = 9.000000 3.000000 - 6.000000 = -3.000000 3.000000 * 6.000000 = 18.000000 3.000000 / 6.000000 = 0.500000 3.000000 to the power of 6.000000 = 729.000000 The square root of 3.000000 is 1.732051 The square root of 3.000000 is 2.449490 But you notice that I'm not using Xcode. Because it's just a basic C program, I'm building on the command line. Xcode is designed for building iOS apps. It's really not suited for beginners at all. There is no way to tell how you've configured your Xcode project. You would need to pick some obscure options in Xcode in order to get it to compile this code. I recommend a programming course at a local college or university instead. Stick with the command line for now.

I was able to capture these machine exceptions (I've only tried with 2 signals, not all) in C++ using Signal handler mechanism. Is that okay? The point of it being super hard is that it usually isn't done properly. If any of these exceptions actually happen in the real work, this kind of carefully crafted exception handling logic will usually fail. Years ago, the approach you describe was popular. I remember large government projects where teams worked for weeks and all they accomplished was a huge mess of complex exception handling code. They held a code review for it but they hadn't actually implemented any of the actual logic for the mission. It was literally just exception handling. Don't do that. At least they were being paid for it. Are you? Regarding Swift and Objective-C exceptions, there are some subtle, but very important differences. Objective-C has both exception handling mechanisms and error handling mechanisms. They are not the same. Exceptions are supposed to crash the app. Errors should be handled and/or reported to the user. Swift's exception handling is based on Objective-C's error handling. You are expected to avoid even the possibility of things like out of bounds, division by zero, etc. But if function throws an exception, you are expected to handle it. In fact, Swift will require you to handle it. Swift 6 concurrency adds more exception handling requirements. But none of these Swift exceptions are the exceptions that you've been worrying about. You've done all this work, but you haven't actually addressed any of the exceptions that you will need to handle.

That is a read-only properly. Just remove the "set" and it should be fine.

Building a notarized Perl app on a Mac using the command line? You're kind of fighting the whole world at once there, eh? 😄 In addition to the hardened runtime, you'll need some entitlements to relax said hardened runtime. Put those in an XML file and use the "--entitlements" flag with "codesign". Make sure to completely test your installation with all kinds of funky edge cases. In addition to all the up-front notarization checks, there are certain checks that happen only at runtime, or only at runtime when you try to trigger something like dynamic loading or JIT execution. That is the part that trips up most people in your situation who get that far. I don't know which entitlements Perl will require - most likely all of them.

Xcode versions are usually closely tied to a particular macOS version. Sometimes there is a little leeway where the next major release of Xcode will run on an older version of the OS. But with Xcode, Apple will sometimes introduce an incompatibility in a minor version. For example, my production system is Ventura and I'm limited to Xcode 15.2 (I think. I'm not there right now.) In most cases, upgrading Xcode doesn't cause any problems. There are a couple of significant issues with Xcode 16, so it is always important to pay attention to what's next. But I don't see any reason why you would need Xcode 12.4. And if you did (maybe for < 10.13 support), I don't see any reason why you would need Sonoma.

The reason is the need to support older macOS Version and the newer ones. We have a bunch of build agents and want to keep the total amount of them as small as possible. And on the other hand use the current version of macOS on them when ever possible. I'm not sure what you mean by "build agent". You can use the current version of Xcode to build code that runs on anything from macOS 10.13 "High Sierra" or later. If you do need to support deployment to 10.12 or earlier, then you will need an earlier version of Xcode. But the cut-off here is Xcode 13.4, not 12.4. See this page for more details. But otherwise, you are correct. There is a "maximum macOS version requirement" for Xcode, which isn't documented anywhere. If for some reason you did need an older version of Xcode, then you'll have to run an older, matching version of macOS on either an old computer or a VM.

Try sysctlbyname with "machdep.cpu.brand_string"

You should probably request one of those "one-on-one App Review consultations", as described here: https://developer.apple.com/events/view/upcoming-events

In theory, anything's possible. There's a GitHub project trying to implement an "OutlineViewDiffableDataSource" but it hasn't been touched for years. I've also seen various attempts to reimplement outline views or to implement them on iOS prior to diffable data sources. So that can be done too. What are you hoping to get that's better than the current NSTableView/NSOutlineView? It's certainly difficult to use, but then so are diffable data sources. My outline views on iOS with undo/redo support were much more difficult to achieve than any equivalent on macOS.

First of all, don't use the comments in the forums. They effectively hide your reply. When searching for new or updated questions, your question still shows up with only one reply. Your comment isn't listed. If you already have it working on macOS with an outline view, I strongly recommend you just resolve those few remaining issues. Trying to use a diffable data source is the path of greatest resistance. Even on iOS, the only reason to use it is because there's no other option. It's much more difficult. It would require a significant rearchiteture effort. On iOS, what you see as an outline view is just a collection view where the cells are simply full-width. That hierarchical display that makes it look like an outline view is implemented with both NSDiffableDataSourceSnapshot and NSDiffableDataSourceSectionSnapshot classes. It's really tricky. For example, because it's a collection view, there are no rows. You can only insert before another identifier, after another identifier, or append to a parent. The entire concept of a hierarchical list was something that was clearly thrown in at the last minute, without much documentation.

There are several lower-level libraries like libcurl that are not present on iOS. I strongly recommend the built-in alternatives instead. There are many to choose from.

If I understand correctly, you can run the binary from Terminal. The Finder is different. It's going to expect a real app. That's a totally different environment.

Start here: https://developer.apple.com/documentation/technotes/tn3151-choosing-the-right-networking-api I have a really old code base where I think I must have supported 10.6 at one time. I have a class called "CURLRequeset" that was a wrapper for the funky Libcurl API. It was easy to convert this class to use NSURLSession if it was available. I should probably rip out the Curl logic. It hasn't been triggered in years.

Yes, I can run the binary by calling "cargo run" from the Terminal, and then the binary opens as well. Sounds like it's working then. So you are saying that when using Finder, it expects a real app. Yes. A "real app" is just a bundle directory that wraps the executable and includes dynamic libraries and frameworks, helpers, resources, and various metadata files like an Info.plist. Ok, so how do I convert my Rust binary into an Apple app? No clue about anything Rust-related. I can tell you that every "real app" includes a command-line executable. You can usually run that executable on the command-line like any other Unix command. Sometimes this can be handy to easily see certain log messages or to force the app to run in a particular localized language. The downside is that since you aren't running it from the Finder, there may be some unexpected behaviour. But sometimes you can even have apps that run normally in the Finder, but also have a special command-line only mode. Now the mechanism of displaying a graphical user interface via a command-line app is deep, undocumented black magic. It works for most "real apps" built using normal Xcode templates. It also works for legacy architectures like XQuartz and maybe Tcl/tk stuff. If Rust is able to hook into standard Apple APIs and Frameworks, then it should be able to do that too. A further question. Are all binaries that run on MacOS considered "apps"? No. There are all kinds of exotic things that can be executed. If so, that would imply that all binaries compiled with Xcode would be "apps". It is true that Xcode was designed for app building and for building various other app-supporting artifacts. But Xcode is also just an IDE like any other. I build websites in Xcode using XML and XSLT. That being said, Xcode includes too much baggage for simple, educational command-line tools. But since you are poking around with exotic command line things like Rust on a Mac, I should warn you. Modern, open-source projects can sometimes be based on extremely complicated build systems that make Xcode look simplistic by comparison. (Anything that anyone from Google or Meta has ever touched, for example). If you are trying to build any of that stuff on a Mac, you might find it easier to discard those build systems and port it all to Xcode. It sounds like a lot of work, but at the end of the month, you'll have something to show for it where you wouldn't trying to figure out something like Ninja etc.