I am using XCode and the command line tools and linking against the .tbd stub libraries in the SDK. But to do it I had to specify the path to the stub files Why? since the path to the stub files does not lie along the standard shared library search path automatically. What happens when you try to compile without specifying that path? What error message do you get? What does your compile command look like? What I'm worried about, and it's probably nothing to worry about Don't you think that if there was a problem, someone would have noticed it by now? I'm guessing when ld builds an executable and you use -lc to tell ld to link against the c standard library, the path to the library is not built into the executable. Instead, will the run time linker then use the shared cache for the libraries? The path to the library is is built into the executable. You can inspect that with "otool -L". The fact that the operating system uses the shared cache is an implementation detail. I can't test this theory easily since I only have one machine and it has XCode with the command line tools installed. Don't worry. About 50 million other people have thoroughly tested it by now. If you do have concerns about how your app would run in a "factory fresh" computer, you can install a virtual machine like Parallels and test it there. I strongly recommend that. Many developers install dynamic libraries from various "ports" or "brew" tools, from crazy cross-platform development tools, and are completely helpless when their apps don't work properly anywhere except their development machines.

So, my questions are: Why are you asking questions? You seem to be doing better error handling than any other developers out there.

I made the changes you suggested and that did not fix anything. Then maybe the problem is something else. Did you try building and notarizing it without the script first? Can you provide a link to any script for notarizing a basic "helloworld" terminal application not using Xcode? Here is something I posted on the developer forums a while back showing how to notarize Ghostscript. https://developer.apple.com/forums/thread/130379 However, when I tried that with your tool, it failed. I don't build many packages anymore and my instructions for building the package in that thread are wrong. So I re-did it using your own tool. // I don't have the Info.plist file, so I'm omitting that. clang -O3 -DHAVE_ZLIB -o niimathX86 niimath.c bw.c core.c tensor.c core32.c core64.c niftilib/nifti2_io.c znzlib/znzlib.c -I./niftilib -I./znzlib	-lm -lz -target x86_64-apple-macos10.12 -mmacosx-version-min=10.12 clang -O3 -DHAVE_ZLIB -o niimathARM niimath.c bw.c core.c tensor.c core32.c core64.c niftilib/nifti2_io.c znzlib/znzlib.c -I./niftilib -I./znzlib	-lm -lz -target arm64-apple-macos11 -mmacosx-version-min=11.0 // Create the universal binary. lipo -create -output niimath niimathX86 niimathARM // Create a staging area for the installer package. mkdir -p usr/local/bin // Copy the binary into the staging area. cp niimath usr/local/bin // Sign the binary. codesign --timestamp --options=runtime -s "Developer ID Application: XXX" -v usr/local/bin/niimath // Build the package. pkgbuild --identifier "com.example.niimath.pkg" --sign "Developer ID Installer: XXX" --timestamp --root ./tmp/usr/local --install-location /usr/local/ niimath.pkg // Submit the package to the notarization service. xcrun altool --notarize-app --primary-bundle-id "com.example.niimath.pkg" --username "user@example.com" --password "xyz" --file niimath.pkg // Wait 1-5 minutes. // Staple the package. xcrun stapler staple niimath.pkg // Optionally make a zip for the package. ditto -c -k --sequesterRsrc niimath.pkg niimath.zip // Upload the download file. scp niimath.zip user@example.com:path/to/download/link/niimath.zip // Download the file using Safari to verify the notarization worked. The tricky part was building the package. I had originally used "productbuild" too, but I couldn't get that to install on Big Sur. It is very picky about the package, structure, and install path. You have to use "pkgbuild" to get those setup properly. Maybe it is possible to use "productbuild" with different settings. I don't know. Another tricky part is the verification. You will find no limit to the number of clever command-line verification tests posted here in the forums. Strangely enough, all of those clever command-line verification tests are failing because they are posting here in the forums. There is only one way to verify that notarization is working, and that is to upload the binary and then download it with Safari and install. Preferably, do this inside a virtual machine where you can test in a factory-fresh environment without developer tools, hacked-up SIP, 3rd party Qt libs, homebrew, anaconda, and god knows what else. I omitted any kind of checking or verification. That's the thing about Notarization. Sometimes people reuse to listen and flail away at it for weeks or months. But once you figure out what you are doing wrong and fix it, it never, ever fails. So rather than trying to parse the output, just fix the problem and assume it always succeeds after 5 minutes. You might get one or two failures a year when the notarization servers are slow or down. Otherwise, it always works.

I would like to enable the App Sandbox - USB Entitlement for the tool. Why?

Only the first four lines are modified.  Well that seems to be where the problem is. Change: 3rd Party Mac Developer Installer: My Name (12ABCDEFGH) to Developer ID Installer: My Name I don't know if any of the rest of your script is correct or not. I don't use "--force --strict" when signing on the command line. It doesn't look like it should break anything. But those commented-out lines above have me worried. Those concrete working examples you ask for have been provided, by Apple and others, over and over again. But otherwise, the script looks OK. 20 seconds is a bit optimistic. A minute might be better. In general, the whole process was designed for developers building iPhone, and later, Mac apps. You could always wrap your project into a Mac app, or maybe even an iOS app. Then you can just click a button in Xcode.

Here is the official procedure: https://support.apple.com/guide/apple-configurator-2/apdd5f3c75ad/mac However, it looks like you may not have the basic requirements. If you are trying to run a Mac from VMWare on a PC, or trying to boot from USB, you probably aren't going to have any success. If you don't have another Genuine Macintosh to use, you will have to take the computer to an Apple Store or Authorized Apple Service provider and ask them to restore it.

A command line tool is not an "app" and cannot be notarized. You would have to use an app template and make a GUI version.

Can you provide some links to where this is documented and how we are supposed to accomplish this? Google? I am in the middle of getting some of our C dependencies to build with iOS arm64 simulator support and am failing when attempting to make an xcframework with all three slices.  There is one thing that hasn't been mentioned yet and that might be a big deal, especially with open-source C dependencies. Many of these tools are designed to be built on the platform where they run. Not all projects support cross-compilation. But even those projects that do support cross-compilation might not do it in a portable way. You have to make sure to check any generated header files. There may be platform and architecture-specific differences. xcframeworks are great for cross-platform versions, but you are expected to use lipo for for cross-architecture builds. But the headers for the different architectures may not be compatible. You will have to manually review all header differences and make adjustments to one or both projects until the headers are compatible.

The app does local receipt validation in a very standard way, requesting the receipt if it's absent. I wasn't aware that there was any "standard way" to do this. What do you mean "requesting the receipt"? The only thing you should be doing is exiting with a 173 result. The operating system will refresh the receipt and try to launch again. If it keeps failing the receipt validation, then you'll get the "damaged app".

We'd like to know what Apple's plans are to fix this problem, and when we can expect this fix to be released. Apple never tells anyone their plans, for good reason. You can "expect" this will never be fixed. If you are really lucky, it "might" be fixed in a couple of months. This would be an absolute, best-case scenario. But you really shouldn't expect that. If you want to support older operating systems, you will need to build, or at least sign, with an older system.

Hi, now that BigSur is available I would understand a bit more about Python3, because, unlike what is written here, I've read somewhere in the net that Python3 is installed by default on BigSur, so I'm pretty confused. No need to be confused. It is safe to assume that anything you read on the net is a lie until you can verify it yourself. Few days ago I installed python 3 from the official website, but since I don't need it, I started to delete all the files related to "python3", but I'm afraid I've deleted something of the system. The operating system is well-protected against these kinds of things. You can't do any damage without real, malicious intent. Do you confirm that, as default on BigSur, there's only python2 installed? Yes And so, in this case, can I delete all the files I find on MacOS related to python3 (As, for example, the ones in /usr/local/bin)? Yes However, you do seem to be missing the big picture. Any scripting languages shipped by Apple with the operating system should be considered for Apple's use alone. In all other respects, they should be treated as deprecated. They could be removed at any time and there is no guarantee that any operating using them will succeed. Many of the tools and techniques used in modern scripting (pip, anaconda, etc.) will not work on with the default scripting languages installed on a Mac. Full details are available here. - https://developer.apple.com/documentation/macos-release-notes/macos-catalina-10_15-release-notes

Apple's getting more aggressive with deprecations. Used to, they would wait several years after officially deprecating something before removing it. But it turned out that 3rd party developers never paid attention to that and that long lead time was a waste of time. The flatten and unflatten commands were only deprecated in Catalina. The moral of the story, "deprecated" means "fix this now". My suggestion is to change your app so that it displays the SLA on first launch. That's easy enough to do and then its done. Your embedded SLA problem goes away. Perhaps even the rationale for having a DMG in the first place goes away too. You only need a DMG if you need to install multiple system modifications as root. With the SLA embedded in your app, you can just zip up the app and distribute the zip file. There are companies that will extract your app from the DMG and repost it on their site, thereby stripping your SLA. In short, it was never a good idea to use a DMG if you didn't have to.

Well, you did give me two options there... Objective-C is a very dynamic language. It can exhibit strange behaviours. I strongly urge you not to ship any software that depends on any of those strange behaviours.

Are you getting some kind of error message? If so, what does it say? Both ncurses and panel are on 10.15. I just built a little demo from the internet and it worked fine. You can't supply a tbd file on the command line. Just use -lcurses. Edit: Are you asking about Big Sur or Catalina? Because 10.15 is Catalina. Big Sur is 11.0. I just tried on Big Sur and it worked fine there too. Big Sur is a bit more opaque about these things. The /usr/lib directory doesn't have much in it.

It looks like whatever package management system you are using is not aware of Apple Silicon. Those package management systems are very slow to notice and adapt to things like new OS versions and especially entirely new platforms.