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

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?

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.

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.

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.

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’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.

Nothing to do with notarization.

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.

Is there any way to have the script request fill disk access from the user at runtime the way regular Mac apps do on first attempt? There are virtually no Mac apps that do that on first attempt. That would be an automatic rejection from the Mac App Store. Speaking of which, why are you worrying about Mac App Store security requirement for your internal tool?

It would be better to install them into /Library/Frameworks. That is a standard location and you wouldn't have to do anything to any rpaths. You can still sign and notarize. You would just have to sign the individual frameworks and the apps. Then notarize the installer pkg that installs them all. It would be nice if you included an uninstaller too.

If you have questions about or problems with Qt, then you will have to ask Qt support for assistance. I can tell you that very few people use Qt on a Mac, but those that do have an inordinately large number of problems. When I see someone posting about how they are struggling for weeks to perform some simple task that takes 2 minutes, it turns out they are always using Qt. Well, that's not true. Sometimes they use Electron. If you want to write a game for Linux, then use whatever it is that will work best for your Linux users. If you want to write a game for the Mac, then use whatever is going to work best for your Mac users. Keep in mind how many potential Linux users you might have vs how many potential Mac users you might have. Also consider how easy it would be to port a Mac game to iOS, which gives you 1 billion potential users. Choose wisely.

Just because you were doing something a certain way in the past doesn't mean it was ever correct. As the error message says, you are using a reference to a non-const temporary object, which is not allowed. You could change it from a static_cast to a constructor and C++11 would be happy. But that would break it for older versions. Ideally, just do the output operator normally in the first place. std::cout << "matrix (of size N=" << n << ")" << std::endl; and that works with any version.

There is something wrong with your computer. It is possible to get some characters to echo before the password prompt appears. But it is really humanly impossible to actually type your password in that length of time. It should only take a fraction of a second. If yours is slow enough to type "asdasdasdasdasdsadadasdsa" then something is seriously wrong. I did manage to get "sdfa" to show up, but that is only by quickly slamming my hand on the keyboard. There is no way I could type anything and have it show up.

The UI of the Main app is Electron That complicates things. I strongly suggest building a non-Electron proof-of-concept for any solution just so you know how it should work and where any complications might come from. only sandboxed apps outside of app group are restricted from accessing it :)  Important plot point. Sandbox security is different depending on your perspective. It provides security to the user against your app, not against other apps. At minimum level we need to be able to verify the sender identity (i.e. if the sender is app signed by us). Ideal situation would be to have fully private communication channel secured by app signature on the OS level.  I don't know of any built-in API that is going to give you that guarantee. This would be easy enough to solve by just getting rid of the multiple executables. So which is more important? The security or the electron?