Notarizing macOS app – XcodeUpdates

Today was rather a random day.

First of all, I have been working all day on a commercial product.
Nevertheless, I was able to listen to the latest Stacktrace Podcast (@stacktracepod) which was not technical at all (except that advertisement, but nevertheless). 

I was not listening through it because I am not a big fan of food at all. But it lead me to think that I should watch some WWDC session.

So I have started to listen/watch a WWDC session about Swift and SwiftUI (more on this process in later blog posts):

  1. Modern Swift API Design – WWDC 2019 – Videos – Apple Developer
  2. SwiftUI Essentials – WWDC 2019 – Videos – Apple Developer

And after watching SwiftUI Essentials, I saw a session called “All About Notarization – WWDC 2019 – Videos – Apple Developer“. I was like, “huh, that’s completely random since for a week I have been planning on notarizing @UpdatesXcode and I was gathering some materials to get started on how to do it:


My plan was to move out the xcodes wrapper into a separate XPC service, and by doing that I would somehow be able to notarize the main app. This was based on some implicit hints that I saw here and there throughout reading some error messages in Xcode.

Nevertheless, after watching that WWDC session and reading Tech Note TN2206 I have shifted my focus from the existing plan.

I saw a this screen on that WWDC session, and the wording made me interested to think about it for a little.

Screenshot from WWDC session related to Hardening Runtime in macOS apps

On this screenshot, we see a recommended solution “Move to an out of process plug-in model“. And it makes total sense! It fits my previous plan!

But I must tell you that I have switched to this exact moment in the video for over 10 times, I am not sure how that worked out, but this exact screen – I was returning to it over and over, until I saw that “Fallback Solution” on the bottom.


I was definitely not aware of the fact that Hardened Runtime is something that is related purely to signing!
My thinking was that it was changing the build process, i.e. the way code is being compiled, and not the sign phase of it. 

I was planning to use swift build command to enable the Hardened Runtime for both xcodes and aria2, but I could not find the flag that I needed (-o runtime) for swift build command.

Apparently that flag belongs to codesign command line tool! So in minutes I was able to get the proper xcodes version out of its build script.

But what to do with aria2? Should I check-out the source code and install all of the dependencies, rebuild it from the source code and do the proper signing?

I think not! Instead, I have renamed the input file in the same build configuration file (Makefile) of xcodes to aria2c and in seconds I had a signed copy of aria2 with enabled Hardened Runtime on hands!

And after that I just replaced existing copies of these tools in XcodeUpdates, and voila!

Completely random.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s