Developing a program code always brings joy. You get the instant outcome, you may check it out and see how neat the user experience is.
However, there are some formalities that act as a buzzkill here. Some of them are about publishing an app. Windows and macOS protect their users from malicious software, therefore publishing anything and everything isn’t possible. It’s imperative that the OS knows that the software comes from the trusted developer (signing), and its code doesn’t contain threats to the user (notarizing). Windows has only signing requirements, while Apple has been checking notarization since the macOS 10.14 Mojave was released.
This article came about after having to face some troubles while publishing an ElectronJS-app for macOS, and I would like to share my experience. We will begin with some starting information. If you’ve already developed and published ElectronJS-apps, feel free to skip through this part and we will see you when the more interesting one comes out – in a week or two 🙂
A short introduction to ElectronJS
ElectronJS is a tool to easily create a cross-platform app to launch it on all popular operational systems. The library uses the Chrome V8 engine and emulates a different browser window, where you can apply your HTML code, written with ReactJS. Electron uses its own backend to interact with an operational system, for example, to show system windows. Communication between what the user sees on the screen and the Electron backend happens with events.
Building an application is also fairly simple. Electron daughter libraries are in charge here, such as electron-builder, electron-packager. As an outcome, we have a ready binary file – .exe for Windows, .app for macOS, or executive binary file for Linux
You wrote and built an app. Ready to publish and send to the customer?
Unfortunately, not. For the users to launch an app, a developer certificate is necessary. This is a so-called digital signature of the app. It protects the program by mentioning who the author is. Apps with digital signatures are verified and are less-provocative to the system, antivirus programs, and firewalls. Software like that rarely ends up in quarantine.
If the app isn’t signed, macOS will politely ask to move the file to the bin.
Windows will notify the user that the developer is unknown and you’re at risk.
Do not scare your user with these messages, better go and get that developer certificate! Add it to the keychain of the OS you are making a signature for. Later, use the certificate to sign the app. XCode Developer Tools on macOS provides codesign to do that. Electron-builder and electron-packager libraries supply you with their wraps to sign an app. You just have to let them know that you’re willing to sign an app with that particular name after the building is completed. More than that, macOS has one more way to do so: a separate wrap library electron-osx-sign.
Got the certificate, signed the app. Anything else?
Yep. Notarizing is the next step. It means that you have to check the code on the Apple servers to verify that there is no malware in it. Otherwise, the user will see this upon the first launch:
To send an app for notarization, Apple ID is necessary. That’s your login email to developer.apple.com and an Apple ID password from appleid.apple.com.
XCode altool provides utility for notarization. Unfortunately, it’s not in the XCode Developer Tools pack, so we have to install the full XCode. That moment when you don’t use XCode, like, ever, but you need it so you kiss goodbye to around 30 Gb of memory 🙂
We send the application using the command:
xcrun altool –notarize-app –primary-bundle-id “<id>” -u “<appleid>” -p “<app-specific password>”
Anything works as primary-bundle-id. It doesn’t affect notarization at all. For instance, mention com.electron..
Notarization takes about 5-10 minutes. Apple will give you a unique RequestUUID. Use it to check on your notarization status. For that, use the command:
xcrun altool –notarization-info <RequestUUID> -u “<appleid>” -p “<app-specific password>”
The whole history can be checked with:
xcrun altool –notarization-history -u “<appleid>” -p “<app-specific password>”
Electron developers have expanded electron-builder and electron-packager libraries by adding a notarization process into the general workflow. There is also a separate wrap library electron-notarize which does exactly the same things. Basically, you need for things ready: built and signed .app application, appleId, appleIdPassword, appBundleId.
If a notarization tool doesn’t stumble upon anything bad in the app, your status will turn to Package Approved with a status code 0. Otherwise, Apple will give you the Package Invalid status and a status code 2. Fear not, friends, as every “bad” notarization has a log attached. All problems are mentioned there, as well as the directories of the files that stopped you from publishing right away.
If notarization is successful, congratulations! You’re ready to release your app.
When you have that last piece of the jigsaw, everything will, I hope, be clear (Albus Dumbledore)
When starting developing a desktop app on ElectronJS, think about the certificate to sign the app in advance. Don’t forget about the notarization, either. If you skip these parts, the potential amount of software users will drastically reduce because of conflicts with an operational system.
The 2nd part of this text will be released soon, and it will touch on the problems one might face when notarizing an app on macOS. See you then!