.pkg Installers, Rosetta and SHA256 hashes

DSP, Plugin and Host development discussion.
Post Reply New Topic
RELATED
PRODUCTS

Post

1) I am using a M1 Mac with Big Sur to build universal binaries (Intel+ARM).

2) Then I copy the .component and the .vst to my Intel Mac with Mac 10.14. Here I build the .pkg installer with Packages and run the Notarisation. I am using the old Mac to keep downward compatibility with older MacOS versions, as the Certificates on BigSur are SHA256 only.
Big Sur does not correctly sign pkg files using SHA1 which is required by El Capitan (10.11) and earlier (planed obscolescense?). Sierra (10.12) and later seem to correctly pickup the SHA256 signature.
Reference: https://developer.apple.com/forums/thread/664842

3) One customer reported that he was not able to run my .pkg installer, as it would 'just run under Rosetta' and he had uninstalled Rosetta on his system.

--------------------------------------------

Question1:
How do you handle the SHA1 issue with your installers?

Question2:
I am confused about the 'Rosetta issue' that the customer reported. Is the customer telling missinformation? If not what does happen with our old installers when Apple should drop Rosetta, especially those for soundsets. Does Rosetta affect .pkg installers at all?

Question3:
How do the .pkg installers work from the technical side. I thougth it would just be some kind of script that decompresses and copys files

Post

Markus,

I believe the newer version of Packages builds as Universal Intel/Arm64:
http://s.sudre.free.fr/Software/Package ... notes.html

I am intentionally not notarizing pre-Mojave "legacy" versions of my plugins because I believe the notarization breaks something with packages on earlier versions of macOS besides the SHA1 - at least a few users weren't able to open the package installers on Sierra...

But if you are aiming to produce one installer package fore each plugin, It doesn't feel like it's possible to support notarization+Arm64+older versions of macOS :wink:. I think the best thing to do is just to have two versions of your plugins; one for 10.9-10.15 and one for 11+. In my case, I also have versions for Mojave and Catalina, as I feel like there are some differences there in the macOS system frameworks I am using.

I'm also still just product-signing/notarizing things on Catalina: I don't trust Apple not to break certain things like that in newer versions of macOs. I've heard about notarization issues on BigSur before and therefore avoid using it for this process unless it's for something that will be deployed only on BigSur/Monterey...

Post

Markus Krause wrote: Fri Jun 03, 2022 7:40 am 3) One customer reported that he was not able to run my .pkg installer, as it would 'just run under Rosetta' and he had uninstalled Rosetta on his system.
We also overlooked this at first. We had our plugins running natively, but the installer itself was still running via Rosetta.

I'm not very versed in the technical details (I'm not a developer), but Lady Gaia gave us a very helpful hint how to make the installer run natively.
Maybe this is useful for you as well: viewtopic.php?p=8085952#p8085952

Post

I'll write here as well as someone may miss the other replies in the other thread.
adammonroe wrote: Sat Jun 18, 2022 10:03 pmI think the best thing to do is just to have two versions of your plugins; one for 10.9-10.15 and one for 11+.
This is not necessary. Since Big Sur 11.3, we are building Universal 2 Binary plugins and PKGs with correct SHA1 and SHA256 signatures that can be opened from OS X 10.9 to macOS 12.x. No issues with notarizations or signatures.

If you are using Packages you need to specify

Code: Select all

hostArchtectures="x86_64,arm64"
in the advanced options, and then you might need to resign the PKG directly with productsign. Not sure if Packages has been updated to fix the re-signing thing, but that was the case one year ago.
Also, with Packages you need to double check if the notarization actually went through correctly. I remember sometimes we got a "Package Approved" but then checking with

Code: Select all

spctl -a -vvv -t install 
we would get something like "rejected".

I strongly suggest using pkgbuild instead of Packages, so you won't need to resign (if that's still the case) and will avoid other possible issues.
AudioThing (VST, AU, AAX, CLAP Plugins)
Instagram | Twitter | Discord Server

Post

I don't use the signing of Packages, but sign it manually with command line. It is/was broken.

hostArchitectures="x86_64,arm64" is probably referring to pkgbuild syntax.
In Packages it works using 'arm64 x86_64' with a space.

---------------------------------------------

My build setup works this way:

1) Build and codesign with XCode on BigSur as M1/Intel universal binary on my M1 machine.

2) Copy the .component and .vst to my Intel Machine with MacOS 10.14. There I run some tests if the plugins work properly.

3) Run packages in MacOS 10.14 with hostArchitectures="x86_64 arm64".

4) productsign, notarize and staple on MacOS 10.14

Post

Markus Krause wrote: Mon Jun 20, 2022 9:32 am2) Copy the .component and .vst to my Intel Machine with MacOS 10.14. There I run some tests if the plugins work properly.

3) Run packages in MacOS 10.14 with hostArchitectures="x86_64 arm64".

4) productsign, notarize and staple on MacOS 10.14
All I'm saying is that these steps are completely unnecessary if you want to automate your builds. All you need is a Silicon Mac with Big Sur 11.3+ and Xcode 12.5, and you can support from OS X 10.9 to macOS 12.
If you like to do things manually, juggling plugins around two computers, sure...
AudioThing (VST, AU, AAX, CLAP Plugins)
Instagram | Twitter | Discord Server

Post

audiothing wrote: Mon Jun 20, 2022 10:36 am All I'm saying is that these steps are completely unnecessary if you want to automate your builds. All you need is a Silicon Mac with Big Sur 11.3+ and Xcode 12.5, and you can support from OS X 10.9 to macOS 12.
If you like to do things manually, juggling plugins around two computers, sure...
Does that build for i386 too (32-bit)? On my M1 running macOS 12.4 with latest command-line tools 13.4.0.0.1.1651278267 (latest I think) I can build just fine like this:

Code: Select all

-arch x86_64 -arch arm64 -mmacosx-version-min=10.9
Yet if I try to add "-arch i386" then it runs into some errors in AppKit headers. There's a few, but here's an example:

Code: Select all

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSViewController.h:248:39: error: unknown type name 'NSExtensionContext'; did you mean 'NSAnimationContext'?
@property (nullable, readonly,retain) NSExtensionContext *extensionContext API_AVAILABLE(macos(10.10));
Bumping the minimum version to 10.10 doesn't seem to help, so it seems like i386 is just broken?

Personally I don't really care about 32-bit .. so whatever .. but any idea if this is xcode 13 issue, or did it break earlier and I just never noticed?

Post

mystran wrote: Mon Jun 20, 2022 11:06 amDoes that build for i386 too (32-bit)?
We have dropped support for 32bit in 2018, so I have no idea, to be honest.
AudioThing (VST, AU, AAX, CLAP Plugins)
Instagram | Twitter | Discord Server

Post

audiothing wrote: Mon Jun 20, 2022 11:11 am
mystran wrote: Mon Jun 20, 2022 11:06 amDoes that build for i386 too (32-bit)?
We have dropped support for 32bit in 2018, so I have no idea, to be honest.
After some Google:
The macOS 10.14 SDK no longer contains support for compiling 32-bit applications. If developers need to compile for i386, Xcode 9.4 or earlier is required. (39858111)
So looks like it's a much older issue and I just never noticed... oh well...

Post

We did not get a single complain when we dropped 32bit support on Mac last year. I don't think it makes sense to waste development time with this.

Post

Signing/notarizing on the latest Monterey/Apple M1 here, via CLI, does not seem to break any compatibility, down to macOS 10.11 at least.
Image

Post

No reason to support 32-bit on macOS anymore, nor carry any legacy Carbon code. It seems that Apple userbase updates hardware frequently, unlike Windows userbase that still may need 32-bit support (even if less than 1% of users).
Image

Post Reply

Return to “DSP and Plugin Development”