Re: Installer pkg built with Xcode 12.2 won't open in macOS 10.10 and 10.11

Mark Allan

Sorry to dredge up an old thread, but I'm still having issues with this.

I've worked out that I can do the Archive build on my main dev machine (running Xcode 12.x on macOS 11.1) and then copy the resulting .pkg file over to my iMac (still on 10.15) and run the `productsign` tool over there. Doing that allows the pkg installer to run correctly on macOS 10.10 all the way up to 11.1

I'd rather not have to rely on two separate machines in my build process though.

Does anyone else have any other suggestions?

Best regards,

On 9 Dec 2020, at 3:30 pm, Mark Allan via <> wrote:

Yeah, I've seen --deep causing problems in the past. I'm using `find` to traverse the directory structure and calling codesign on each file in turn.

I've worked out why the notarisation bit no longer works though - in another part of my script, it strips off extended attributes just before tar'ing up the directory. This is something that was necessary in the past because xattrs used to cause problems with on OS X 10.6.8. Removing the line that strips them off allows the notarisation to succeed.

Sure enough, running `ls -la@` on the directory gives the following extended attributes on some files...curiously not on all files, even though all files are signed! 136 220 172 9001

This must be new behaviour with Xcode 12.2 rather than macOS 11 specific, as it does the same thing on 10.15.

Sadly, it doesn't get me any closer to being able to create an Installer .pkg file which opens in 10.10 and 10.11 though.....


On 8 Dec 2020, at 5:39 pm, Jack Brindle via <> wrote:

I agree with Quinn on this one. If you bring in any libraries, especially any that are previously codesigned, —deep WILL break their signing. With the addition of system extensions and imported libraries, it becomes very important to not modify or replace any of the previously-signed bundles/libraries, or your app will simply not work under Big Sur. Figuring out why Gatekeeper didn’t allow your app to launch can waste considerable time and sanity. Don’t ask how I know this…
I now make sure that we do not use —deep in our code signing, but instead walk the tree of all bundles/libraries and make sure they are signed, or if they are known to be previously signed, don’t re-sign them.

One other thing I have learned recently - for the first time, provisioning profiles are important on the Mac. All the things the iOS devs have gone through in learning how to handle them we will be going through over time. Gatekeeper has changed our world, and is much more stringent on Big Sur. Properly codesigning is the only way to tackle it.


On Dec 8, 2020, at 9:05 AM, Jon Gotow <> wrote:

On Dec 8, 2020, at 7:51 AM, Mark Allan <> wrote:

I'm beginning to think there's something wrong with the 'codesign' tool on macOS 11. One of my other build scripts for the same app iterates through a directory of additional binaries and libraries to codesign them prior to being archived. (find .... exec /usr/bin/codesign ... )
Yes, that was my point in my (overly long) reply earlier. The _only_ thing different about the two builds was in codesign. The apps were exactly the same otherwise. The failing copy of my app was signed with macOS 11.1's codesign on Apple Silicon, while the successful one was signed on an Intel machine running 11.1. So codesign has changed.

The codesign tool reports no error whilst signing, but the resulting archive fails notarisation because of a number of unsigned embedded files. Sometimes they all get signed correctly, sometimes one or more files are missed and don't end up getting signed.
In Quinn's unofficial post on the do's and don'ts of code signing, he says not to use the --deep argument, but instead create a script that signs all necessary executables from the inside out (see Are you signing individual embedded files of your .pkg as necessary, or relying on --deep to do it for you?

- Jon

Join to automatically receive all group messages.