Why do you need to notarize them? Those libraries aren't being launched. They are being integrated into other apps, which presumably, would be notarized.

Nothing to do with notarization.

I’m dropping this link here as a breadcrumb for Future Quinn™. I don't know if that is such a good idea. People might infer that you are recommending that link as a source of useful information. It is a step-by-step instruction manual on how to shoot yourself in the foot.

A number of the apple apps ask on first attempt, and then auto-add the permission I have never seen a single Apple app ask for Full Disk Access at all. They most definitely never "auto-add" any permissions. You seem to be thinking about the access for certain special locations like Downloads or Desktop. Any app that attempts to access those locations will trigger a confirmation dialog. As a convenience, Apple automatically adds apps to those security lists, but leaves them unchecked. This is so the user doesn't have to go searching for them. I don't care about App Store anything - this is a pure shell script to do compliance audits in my company to validate that users are actually performing regular time machine backups as required by our ISO standards. We only use this script internally. Then why do you care about this? Just give your app app Full Disk Access via MDM. Which it turns out, means you would need to grant access to /usr/bin/env rather than /bin/bash. Duh. The macOS version of bash is ancient. It is better to use zsh. For scripts, just use "sh".

I had done the best by following the code signing documentation, testing it locally and using transporter to verify the package Can you clarify what you mean by "testing it locally"? I assume you are just running the app on your development machine. You should be testing in a pristine, "factory fresh" environment such as a virtual machine or, even better, a dedicated test device. These test environment must always be using the latest shipping version of macOS as that is what App Review is going to run. And what is this "transporter" that you are talking about? Just kidding! 😀 You are using some cross-platform app builder instead of Xcode, right? Well, you have to ask yourself. How much time and effort are you really saving? To be honest, you don't need code-level support for this. Just build your app in Xcode and pretty much everything is done for you. Yes, I know! You are too far along to rewrite everything now. No money is worth more than money than you have already spent. I suggest you contact whatever support resources exist for your 3rd party app-building tool. It will probably be another free forum environment like this one. But those people, unlike anyone here, will 1) know what tool you are using and 2) be familiar enough with it to offer you advice.

Are there any "gotchas" if you set up a second Apple ID just for your paid developer account? Always I assume you can set up your personal ID as a "developer" in App Store Connect for testing. No. Never do that. App Store Connect has the ability to create kinda-fake Apple IDs just for testing. They use special Apple developer services designed just for testing. How do you do two-factor for the "business" ID? (Do you need a separate device for that?) Do you use the same phone number for both accounts (I'm only planning on having one phone, haha)? This Apple web page - https://developer.apple.com/support/authentication/ has instructions on how to configure your phone for two-factor authentication with multiple accounts. It is very easy. You can do it on your Mac with a separate account but using your phone is so much easier. PS: Those testing Apple IDs also support two-factor authentication. But for those, I just use SMS. I wouldn't recommend trying to integrate them with real two-factor authentication, or even if that is possible. Are there actually any meaningful advantages to having a separate Apple ID for this purpose? I don't know if I could conceive of any "meaningful advantages". There are a number of gotchas and hassles associated with having a separate developer Apple ID. It is just that I can't even imaging trying to use the same Apple ID. Maybe if you are just doing it as a hobby and always plan to do that forever then a single Apple ID might be acceptable. If you have any apps in the App Store, they will be associated with your real name. That can be a bit suspicious. I have an app that has some security features and I've been seriously contemplating considering any Mac app signed by a personal Apple ID to automatically be potential malware. I have a lot of data from the other side of things so I know that signed, malicious Mac apps are always signed with personal (but probably fake) Apple IDs. I consider such accounts practically worthless from a security perspective. This does NOT apply to App Store apps, however. There are more hoops to jump through over there. One of the biggest hassles is just dealing with multiple Apple IDs. One trick I use is keeping Safari Technology Preview handy and using that exclusively for my business activities. This way, I can login to the forums (and App Store Connect) with my business Apple ID. All of my other Apple interactions (iCloud, etc.) use my personal Apple ID in the normal Safari version. I even use a really old Apple ID for Apple Support Communities (long story). Apple's corporate login procedures are not designed for multiple Apple IDs. But ironically, Apple has made if more difficult to sign in at all recently and now it is a little bit easier to just click on the "Use other Apple ID" button and then I can just pick the appropriate Apple ID and let it autofill the password. Officially, I am in complete agreement with Eskimo's suggestion to create a corporate entity, especially if you ever intend to charge money or do more than hobby coding. Just don't that that step lightly. It isn't as expensive as you might think, but ideally, put a couple thousand dollars into it to do it right. You will need to pick a business name and make sure it isn't one that someone else has ever used. You WILL get sued if you don't do your legwork and preparation. At a minimum, check domain names and do trademark searches. I strongly recommend consulting with a lawyer. Your corporation would be a global corporation and subject to laws throughout the world. Apple makes compliance with global laws very easy. Apple handles 90% of the details for you. (But not 100%). Read that developer agreement very carefully and have your lawyer do likewise.

Curious to know if others are experiencing the same thing? The post hasn't been updated in a month. This is not Stackoverflow. It's pretty much you and me here. You should probably start your own thread and post more details about your app. I know you said "dirtro of Unity Game"(?) but that doesn't have any meaning. If you want help from Unity, ask Unity. What does your app bundle look like. How did you build it? Please note that you most definitely did not notarize it. If you had, then it would work. You ran some some commands no doubt. But then it fails, meaning your notarization did not work. The log should contain more details about exactly what happened. Granted, the log is really, really difficult to use. But it is what it is. I can tell you right now that notarization problems are always the same. Some crazy open-source project, built in new and unsupported ways, tested only on a developer rig, with little thought as to how dynamic libraries work. A recipe for failure.

The app I'm building is an electron app. You don't say. I'm signing the app content using the command line tools. And then I'm packaging it as .pkg. Fair enough Transporter is apple's recommended app to upload app packages to MacOS App Store. It is supposed to find issues with package early on before submitting it to macOS App Store. All checks were passed. Apple recommends using Xcode. They provide Transporter for people who want to make life more difficult for themselves, but I wouldn't call that a recommendation. I don't see how Xcode can be used(the app is written in javascript using electron, not in swift or objective C) Maybe do some additional research on your Electron platform. I have tried different permutation combination of signing with Apple ID, using provision profile, changing .plist file, etc. You mean, random trial and error? That is not a recipe for success. What has Electron support told you about this issue?

You should probably post this in a Swift forum. It doesn't have anything to do with Foundation.

The App Sandbox has no boxes checks or files selected, on the signing&capabilites for the target. Those checkboxes and options under App Sandbox are exceptions to the sandbox's restrictions. Since none of those are checked, that means you are running under the highest level of restriction. Your app will not be able to access ~/Documents at all as long as "User Selected File" is still set to "none". If you want to turn off the sandbox, look in the upper, left corner of the App Sandbox area. You will see an "x" button that you can click to turn off the sandbox entirely. PS: If you want to post code in the future, make sure to use the "Code block" button in the forum toolbar. Otherwise, the forum software will scramble your code. Even so, you should carefully review that code. It looks fragile.

You should probably file a bug report. It looks like they installed the wrong certificate for that service.

It sounds like you are in the wrong forum, possibly the wrong web site. When I read your post, this is what I see: blah, blah, 3rd party, blah, buzzword, blah errSecInternalComponent Command CodeSign failed with a nonzero exit code We're using: something something else something I've never heard of and sounds really bad but same account to build with blah, blah, blah People here would be happy to dig into those two items that make sense. Do you have a crash log or something that someone could look at? Maybe a command invocation and full stdout/stderr? Otherwise, nobody has any idea about those 3rd party tools and how they interact with Xcode and each other. In truth, it sounds like some kind of docker-fuelled, deep-stack, tensor-flow AI typescript pipeline. This is not our world.

Obviously clang does support the architecture. It just doesn't support that flag on arm.

What do you mean by "library"? You could have a static archive library that would directly link into your executable like any other object code. You could have a framework, which is a fancy wrapper around a dynamic library, that you would specify under General > Frameworks and Libraries. This framework would automatically be bundled with your app. If you have an Xcode workspace with both app and framework targets, then this is how it is all supposed to work. You could also have a dynamic library. I think you could also specify this under General > Frameworks and Libraries. I've never used this option as it is problematic for many reasons. Another option is to install your dynamic library and/or framework separately into ~/Library/Frameworks or /Library/Frameworks (or some other location) and specify all the correct settings so that your app can find it. Again, this is problematic for many reasons.

You have installed some 3rd party software called "sentinel" that is interfering with the operating system at a very low level. I don't know if this is malware or, even worse, anti-malware. But that is definitely the cause.