Hacker News Reader

Comment by doomlaser | Hacker News Reader

I distribute a Mac app outside the app store. In my case, it's a freeware tool to hide the cursor with a hotkey or idle timer: http://doomlaser.com/cursorcerer-hide-your-cursor-at-will/

Architecturally, it's two "apps", a System Preference pane and a daemon that actually does the hiding.

There's a new dance in the last year or so where you must notarize your app before distribution. This is a bit more involved than just code signing, but it's workable. If you codesign and notarize your app, it's still possible for everyday users to download and launch without too much trouble.

View on HN

I have a silly question. Is it possible to sign and notarize an app for macOS without paying $99/year? I am writing an open source program and want to make it easy for people to install but I don’t think I can justify the cost for something probably no one will see. It’s pretty niche.

I’ve called Apple about it and I’ve searched the web, but I haven’t got a definitive enough answer to satisfy my uncertainty (although I strongly suspect it is the case). Admittedly it may just be a last tenuous thread of hope that keeps me searching.

> Is it possible to sign and notarize an app for macOS without paying $99/year?

Almost certainly not. Apple does technically have fee waivers for eligible organizations — note the term organizations, not individuals — but the red tape required effectively (and ironically) puts this out of the reach for most individual open source developers:

https://developer.apple.com/support/membership-fee-waiver/

Alright, that’s pretty much what I expected but glad to hear it definitively. Thank you!

> I have a silly question.

I have a sillier answer. You could put it on github and invite any volunteer with an Apple developer account to fork it and cope with Apple on your behalf. You could also pledge to do it yourself if you raise $99 plus the cost of your time in sponsorship.

> for something probably no one will see

Unless you need the NetworkExtension API to be a vpn; Apple only notarizes those in the App Store.

This is why you can't download WireGuard from the WireGuard website - only from the App Store after providing ID (email and phone are the minimum required to get an Apple ID, required even for free apps).

It's not as easy as simply notarizing via the dev program and then self-publishing; some APIs are totally off-limits outside of the App Store.

How does Mullvad do it, then? Their Mac app is downloaded directly from their website, and WireGuard is used for their VPN.

I think Mullvad doesn't use the NetworkExtension API but relies on tun/tap. WireGuard used to do this in the past. But if you want to run a VPN on iOS devices you need to implement via NE anyways, so I believe the development was streamlined and the macOS version was build using NE as well. Afaik you can still install WireGuard via Homebrew: https://www.wireguard.com/install/#macos-homebrew-and-macpor...

Older, deprecated API that requires root and will likely soon be removed from macOS.

> Apple only notarizes those in the App Store.

To be pedantic, this is not notarization. The term notarization only applies to software distributed outside the the App Store. The developers themselves sign the software with a Developer ID code signing certificate, and then Apple notarizes the signed software.

Whereas software distributed in the Mac App Store is all signed by Apple itself rather than by the developer.

Glad to find out they notarized this. It isn't a .app though, which I think several in the thread are hoping to distribute outside the app store without making it difficult/spooky for the end user.

If they notarized your prefpane/daemon combo, I suspect they would notarize quite a few .app applications that are properly signed and not malicious or frowned upon use cases.

I was under the impression they would notarize essentially anything that doesn't match known malware? It's an automated system, not a manual review.

https://developer.apple.com/documentation/xcode/notarizing_m...

Anything that doesn't follow all the steps here wouldn't be notarized, I'm assuming. If a whatever.o file compiled from whatever.cpp with gcc from the command line wouldn't have any viable way of just being uploaded to a website for notarization. You'd have to at least go through all these steps. As far as I can tell, you'd need to have xcode to do that.

.o files aren't notarised. Only the executable files that will be run by other people are.

I suppose I could have wrote that a single .o file can be made an executable by gcc if the .o has a main function.

Nearly any file can be set as an executable, and surely a bash script set to launch an un notarized app in your application folder wouldn't magically bypass the gatekeeper security prompt for that app.

Command line tools do not use notarisation at all.

https://scriptingosx.com/2019/09/notarize-a-command-line-too...

Quoting that page, "Command Line Tools can be signed, but not directly notarized".

You need to have Xcode installed, but you don’t need to actually use the Xcode GUI for notarisation, you can use command line tools via `xcrun {altool,stapler}` to achieve the same. My company is distributing a Java application with a compiled JNI component written in C++, and I created the macOS distribution process for the app. It’s fully command-line based for automated deployment.

Packaging and notarisation is a pain, but it is possible, even though the app we’re distributing is self-contained, so it includes a minimal JRE distribution, dynamic libraries, utility binaries, and a loader. All of these components must be code-signed and notarised (not individually, only the complete bundle is submitted, but all components are inspected).

Thanks for Cursorcerer!

Reply on news.ycombinator.com