Apple will update its series of "Identify your ..." support articles once the devices ship. Those will provide Apple's official names, model identifiers, tech support links, etc. Localized versions will follow in a few days.

Dynamic loading is a basic feature of our language. It's been there 40 years and it worked fine until macOS 15. The OpenSSL libraries are no different, I assume, than any other libraries. Just to clarify, I was referring to the old-school practice of setting something like DYLD_LIBRARY_PATH and loading something you find there that's hopefully compatible. You should be able to still do that, but it's going to put you more at risk of various low-level "gotchas" that may not have existed 40 years ago. And when it breaks, the pool of people who know anything about that gets smaller and smaller every year. I'm not Apple, so I can't speak to the level of support that Apple can offer in that situation. I can tell you that in the more canonical case, you are at less risk of random, low-level breakages. If Sequoia breaks something in the canonical case, then it's on Apple to fix it, not you. And if you are loading libraries in a standard fashion, there is a far greater pool of people on forums, in OpenSSL, etc. that will be able to help. This canonical case is still dynamic library loading. It's just that the framework is embedded inside the app. I understand that you aren't using Xcode. But you could use Xcode to build a simple demo app, with an embedded version of OpenSSL as a framework, and confirm that it works (and debugs) properly in that case. Then you can review the details of how Xcode builds that framework, links it to your app, constructs the app bundle, and adjust your build scripts to match. Otherwise, you're just spinning your wheels trying to come up with yet another way to link OpenSSL. That's a moving target. The project I'm working with isn't 40 years old. It's only 24 years old. But I can tell you that once I came up with a system to convert all of my dependencies into frameworks, and constructed the project correctly in Xcode, it made my life so much easier. I have all the power of Xcode, and I can effortlessly step into any library any time I want. It was a fair amount of work to get to this point. But I still see other developers using this project struggle with all the different build systems on many different platforms. That's an entire category of problems that Xcode has eliminated for me.

I'm not sure what language your app is written in, but ours is written in Common Lisp. Using Xcode isn't an option. Xcode is just an IDE. It can support any language for which you have a compiler or interpreter. I'm recommending this test because it's guaranteed to work. You can build a demo app from the template using OpenSSL and see if it works on Sequoia. If it does, then your theory about Apple having blocked it would be disproven. Most likely, the problem is related to your patching system. I understand that this is a 40 year-old project that was working fine a couple of months ago. That's what I was talking about regarding "risk". Other people might use the term "technical debt". You can pay that debt in instalments over time, or you can wait until the bank calls in the loan.

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.