Mac Certification

[CodyCBakerPhD]

Assigning to @rly since he has most experience on this

The previous attempts to certify the Mac deployment via the CI are still not quite working - at least on M1, the app (when moved from the .dmg downloaded from public release) still flags as being unsafe/damaged and will only work if the user goes to the privacy and security page and manually gives permissions for the app to run

@garrettmflynn I think you also saw this on your non-M1?

[garrettmflynn]

Yes, I also saw this.

[CodyCBakerPhD]

@rly Any updates on this?

[rly]

Current status (documenting for myself and us below):

Code-signing locally on my Mac now works with some updates to the certificate, and I have been debugging the notarization process, which fails locally and on CI. I set an app-specific password and agreed to more developer agreements, and now the latest hurdle is that I get the error:

Notarizing com.catalystneuro.nwbguide found at /Users/rly/Documents/NWB/temp/nwb-guide/dist/mac-arm64/NWB GUIDE.app
Error: Apple failed to notarize your application, check the logs for more info

Status Code: 2
Message: Package Invalid
Logs: https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma116/v4/d5/db/e4/d5dbe4ea-bfc6-eda0-c66c-924458dc7a6f/developer_log.json?accessKey=1694876158_3517697162824889674_fro6xSFp7zGzwF3yVRr%2BR4%2BbeJU3IZR%2B3vsfenPr1JTDBGmXW9blc%2FIbYIzzL7ZiQt8Ww%2FWLQ0FYg3ZYV5yxENd9mlXvGIbxsmGkXq%2F2cp2QqebXPEiv3XDLdOLsNqAzLegzZf6muIQEvyJ3sTyi7207c70%2BgSGC5oF%2FVxiGPU4%3D

with the repeated issue of The binary is not signed with a valid Developer ID certificate.

I believe the issue is that I am using a Mac Development ID and need to use a Developer ID. It's also not clear whether we need to do this because we're not distributing on the Mac App Store right now, but I think the answer is yes because the description of the Developer ID is "This certificate is used to code sign your app for distribution outside of the Mac App Store."

I need to debug further.

For full arm64 support, we need to either 1) create two separate dmg files, one for x64 and one for arm64 or 2) create a universal dmg file which basically holds both the x64 and arm64 versions and is double the size. I would do option 1 unless there's a compelling reason to do option 2.

We should be able to build for both architectures on either architecture. However, there are some bug reports about this, so we should test carefully.

[CodyCBakerPhD]

The main reason for (2) would be to have the CI handle it automatically, but yeah that's a pretty large download

Though another reason for (1) is also to ensure the right conda environment (with M1-specific dependencies) is included on the Flask side