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.

How do applications patch themselves and still not run afoul of Gatekeeper, then? Are they just complete reinstalls? I can't speak for all applications. For me personally, life is complicated enough as it is. You can definitely patch your application bundle, but one of the files you replace should be the signature. And that signature will have to be valid for the application bundle as it is on (the user's) disk. Apple is saying we must throw that away, because the patches do include binary executables (shared libraries), though they are code signed. I'm not making any statements about Apple. My position is that it's better to maintain a valid, signed, notarized bundle on disk. I'm confident that this will result in an easier, more trouble free experience for both the user and the developer. I've definitely seen developers use different methods. I just can't recommend those other approaches. Patching the app bundle is not any kind of violation or anything. It's just tricky, prone to failure, and creates the potential for a significant problem later on, when you are least prepared to deal with it. From what I've learned with my own app, I can tell you that Apple has, so far, been very conservative with respect to signature validation. Lots of developers find it challenging to get past Gatekeeper. But once they get installed, they can pretty much do whatever they want. It might not always be that way. Moving everything that changes outside of Contents/Resources will mean either it's user specific, or we'll need to use /Library/Application Support/, which will require admin privs. Also, it's quite a lot of redesign for us to move everything out. That's not what I said. I said that the Resources directory should be for non-executable data - images, text files, translations, data files, whatever. But it's not the place for executable binaries or libraries. Ideally, nothing should be changing. But if you do want to make changes, you can change anything. It's just that the signature should match. There is a version of "Library/Application Support" available in the user's home directory. If you need a place for dynamic source code, plug-ins, libraries, etc., that would be the place for it. I'm not familiar with your code. And I'm not familiar with apps that scatter components around. There might be better locations than "Application Support". There is also a "Frameworks" directory, for example. Apple notarized our app and didn't complain then. Seems like I should have gotten errors or warnings for that. Notarization is used for more than just apps. One mistake I see a lot in this forum is assuming that a successful result from the command-line notarization tools means that notarization was successful. It's not successful until it runs in a pristine environment like a VM.

I assume the mere act of copying the license (a file called devel.lic which is a small text file) is causing this. Yes. Any change to the application bundle after signing could trigger this. I think there are ways to validate a signature while accepting a certain level of irregularity. But you don't have any control over how the OS on an end user's system is going to perform the validation. And those validation strategies will likely change as the OS evolves. The best course of action is to always assume the bundle never changes. There are many alternative places to store licensing information. I recommend keeping it in the user's home directory so you don't have to ask the user for admin privileges to create it. Why does it say it “does not seem to be an app”? Most likely the bundle structure diverges too far from what is expected. Remember that the purpose of all of this is to detect and block malware, which often uses novel ways to structure bundles and executables. The idea is to exploit edge cases that Apple never anticipated in order to confuse the system and gain more privileges. The more unusual your app is structured, the more likely you are to be impacted. This can happen during development or at an unexpected time later on. This self-modification of the files in the Contents/Resources directory is a huge feature. We allow downloading of patches, which add features and fix bugs in the product. Is this going to be a problem, going forward? Yes. In theory, it's possible to modify parts of the application bundle and then supply an updated signature that matches the new bundle. But I'm not sure if anyone has ever managed to do that successfully. It's a high-risk, high-effort solution when storage and bandwidth are cheap. Furthermore, you shouldn't be putting patches or executable code in the Resources directory. That is a special location for non-executable resource data. Using it for any kind of executable code is an excellent way to give yourself signing and/or notarization problems.