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.

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.

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.

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

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.

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.

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.

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.

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.

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.

Signal handling is a Unix functionality that pre-dates Linux. Technically, it's more accurate to say that Linux signal handling came from macOS (via BSD), not the other way around. But this mechanism is not related to language runtime exceptions. Apple has its own perspective about exception handling that is likely different than what you are expecting. I can't speak for Apple regarding what their specific philosophy might be. I would suggest that you not worry too much, or at all, about signal handling. If you did need support for some specific signals, then you can add that support as appropriate. I'm not sure what you are saying about the relationship between C++ exceptions and signal handling. I recommend that you handle all C++ exceptions before they could be exposed to any higher levels or Apple APIs such as Objective-C, Swift, or especially SwiftUI. If there are any Swift APIs that depend on Swift exceptions, then you will need to handle those. But I wouldn't recommend building too much of your own exception-based architecture beyond what is required for Apple APIs. Your expectations about how exceptions should behave and interact with the system might not be the same as what Apple intends.

we can load the OpenSSL libraries fine. They work fine in macOS < 15. They do not work in macOS 15. lldb hangs in macOS 15. It does not hang in < 15. You are talking about loading the dynamic library at runtime. That is always going to be more challenging than embedding a framework into a static app. The only advice I can give is to stick with one, canonical approach. That means forget about Homebrew and focus on the official version that you've built yourself. Much of what you've posted is only relevant to the Homebrew build. I realize your project is very complicated already. You don't need additional complications.

when i build a archive it's fail "Roxane.1 no such file or directory" Something in your project is not configured correctly. I recommend creating a new project, using the same name, but in a different location, from the template. Don't make any changes. Just build and test an archive build. Then you can just copy your existing code over to the new project.

That's a debug build. It will only be built with your native architecture. Do an archive build and it will contain all architectures.

Can you explain more about this? It seems we might have to go that route, otherwise, it's the redesign of a 40 year old application. I was talking about the same process that Quinn described. I've never done it. Perhaps you should use a DTS ticket for more details.