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.

Can you share some documentation regarding this path? Here is Apple documentation. - https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPFrameworks/Tasks/InstallingFrameworks.html One concern with this approach is that other installers can overwrite some common library I suppose that is possible, but highly unlikely. There are really no such things as "common" frameworks. (eg libcurl.dylib, assuming we can also place dylibs here).  That path is only for frameworks. If you have stand-alone dylibs, a more appropriate place would be /usr/local/lib. However, in /usr/local, you stand an excellent chance of some other installer overwriting a common library, or of the user deleting it. libcurl, however, is part of the operating system. You don't need to install that. If you did want to install your own build of libcurl (which wouldn't necessarily be a bad idea), the best approach would be to create your own framework and statically link that to your custom build of libcurl.

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.

There are no exact breakdowns available via the Apple Developer Console that provides developers with a full breakdown of who pays what. It isn't in the developer console. It is in the Apple Developer Program License Agreement. - https://developer.apple.com/services-account/agreement/XV2A27GUJ6/content/pdf I have read if you are a developer selling apps in the UK, there is no VAT to pay as Apple handles it. Whereas I am read Google Play don't handle any VAT. You will have to ask Google how their system works. Is anyone able to clarify this point for me? No. This is an anonymous support forum. No one knows where you are located or what your particular tax structure might be. The rules could be different for you than they are for someone else. This is what makes global sales taxes such a challenging issue. Please review the Apple Developer Program License Agreement that I linked to above. If you are not able to figure out what your tax obligations are, then you will need to hire a tax attorney to help.

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?

thank's to it's multi-platform nature that would take forever You will need to expand on that aspect. Many of these cross platform packages, and the people who use them, do absolutely crazy things that no one has ever seen before. Otherwise, I'm not sure what kind of built-in security you are looking for. App groups don't provide any security, they provide a hole punched through the built-in sandbox security. That being said, the punched hole is restricted to apps in the app group. Because the app is still sandboxed, I think the sandbox will not allow public access to your message port. See the documentation here. - https://developer.apple.com/library/archive/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW24

Why isn't Helper.app implemented as a normal XPC? And for that matter, why is it a separate helper?

In theory, you could fully notarize the app and staple it, then add it to the dmg, notarize that and staple it. But you don't need to do that. I think either the DTS engineer was wrong or misunderstood what you were doing. Everything I have seen in this forum from Apple engineers says to only notarize and staple the outermost container, which would be your DMG.

There are some low-level subtleties involved when opening documents via the sandbox. I don't know the exact details to tell you why this is happening, but I can give you some suggestions on how to solve and/or work around it. First of all, if you are doing this, never ever specify nil as the application. There is no way for you to know what the user has done on their computer. Always specify the exact, Apple-supplied system app that you want to use when opening the document. Next, don't do this at all. You can't really guarantee the existence of any specific Apple app. As Apple would say, the existence of Apple apps should not be considered "API". And on a general user-experience level, this is bad. It dumps the user out of your app. You don't ever want to do that. What you want to do instead is have your own document viewer. All you need is a window with a rich text editing view. You can read the RTF, convert it to attributed string, and stuff it into the view. Takes 5 minutes. If you want to get extra fancy, there are lots of opportunities for that too. I have lots of RTF files in my app and this is how I display them. For the license agreement, I even have logic to make sure they scroll all the way to the bottom before they can agree. In some cases, I adjust the background colours so it doesn't look like a text view. I always turn editing off. For short snippets of text, I use the width of the window and get the ideal height. Then I set an auto layout fixed height. This makes sure that the window automatically sizes to adjust for the content. This is helpful for localization. Don't forget to check in dark mode. You might have to do a little extra work there.