Switch to UN* API

[flying-sheep]

The NS* API for notifications is deprecated, the new deal is this:

https://developer.apple.com/documentation/usernotifications

It also allows to add attachments, which might be interesting! A good example (and the most interesting class to play around with) is UNMutableNotificationContent.

I think a new API that supports badge, sound, and attachments would be nice. The old API could still be based on the deprecated macOS API (and be usable before mojave). IDK how to conditionally compile based on macOS version though.

[ryanmcgrath]

As a heads up on why this might be a PITA...

UserNotifications.framework requires that the application be code-signed. NSUserNotification does not have this requirement last I checked.

[h4llow3En]

Since macOS 11.0 the NSNotification Framework is now marked ad deprecated.
Fortunately https://docs.rs/tugger-apple-codesign/0.2.0/tugger_apple_codesign/ tries to provide a codesigning.
Maybe this is the missing step to finally switch to the UN API

[h4llow3En]

@Pandawan FYI If you still have the time 🙂

[Pandawan]

Haven’t looked too much into it, but IIRC this only handles code signing and not notarization, which is required to run apps on Big Sur... Would have to check if that doesn’t prevent us from using the framework

[Pandawan]

Alright, I started a usernotifications branch on my fork. I'm just trying things out at the moment but I seem to be hitting some roadblocks due to the little knowledge I have of the macos/objc build system.

I've been able to link the UserNotifications framework using #[link(name = "UserNotifications", kind = "framework")] (as well as adding .flag("-mmacosx-version-min=10.14") to the build.rs file. With this, I'm able to successfully include the UserNotifications.h file.

However, my major roadblock and I'm unsure how to handle it is with using it. When I try getting an instance of the UNUserNotificationCenter object with [UNUserNotificationCenter currentNotificationCenter], I get the error Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'bundleProxyForCurrentProcess is nil: mainBundle.bundleURL which may have to do with

• The overriding of the bundleIdentifier
• Maybe some kind of build step I'm forgetting that is required for macos binaries? Info.plist maybe?
• Perhaps this is the step that requires the codesigning (which I haven't tried yet).

Google searches return unanswered questions from a couple of years ago so that doesn't help. Also, it seems most people (and Apple docs) expect you to use Xcode to build your binaries, which limits the number of resources I can find on this.

If anyone knows about the macos build steps, I'd appreciate any insight into what this might be caused by.

[ryanmcgrath]

FWIW, UserNotifications.framework requires your app be codesigned + (I think, am mobile so can't look up) opted in to the hardened runtime.

I have UserNotifications.framework working in cacao, but there's no demo - but if the app is codesigned with valid entitlements and so on, it should work.

[Pandawan]

Nice, yeah something to try out. I see you implemented it in rust using the objc crate instead of using objective-c code directly like mac-notification-sys currently does, perhaps this is also something we could do? Any pros/cons you observed?

[ryanmcgrath]

Pros are that it just feels more in-line with it being a Rust project. Cons... none so far, but for all I know there could be some.

[hoodie]

just checking in @Pandawan @h4llow3En are the roadblocks mentioned above still valid? are we stuck here or is there something we could pick up?

[Pandawan]

Oh yeah sorry I never really got around to finishing this. Major roadblock was (probably still is) codesigning. It's possible but I have little to no knowledge of this and I can't find much documentation on doing it with non-Xcode codebases. So perhaps someone (with more experience) wants to take a stab at it?

[h4llow3En]

Unfortunately it's the same with me. I found https://github.com/indygreg/PyOxidizer/tree/main/tugger-apple-codesign which could be interesting, but I had no time to dive into it

[24seconds]

[Question]
Hello, I really like this repo and notify-rust! Awesome! While I'm working on my pomodoro cli app, I faced this issue also. At first I tried to solve this problem but failed.. And I wonder how other libraries in different languages handle this issue. So I investigated a bit.

• golang: beeep utilizes osca script
• nodejs: node-notifier has executable binary and calls this for notifying. And the binary is terminal-notifier
• php: JoliNotif, I don't know php but it seems utilizes both osascript and terminal-notifier binary

It seems many libraries uses executable directly. So I wonder is there some reason to use raw objective-c in mac-notification-sys?

[Pandawan]

For osascript/Apple Script, the capabilities are much more limited (only title, subtitle, and sound are available).

As for terminal-notifier, it doesn’t support actions and instead recommends using alerter instead for alerts (sticky notifications or notifications with actions). This would require having two binaries instead of one to support every kind of notification, which (imo) doesn’t feel very optimal when a simple objective-c file can handle both.

In general, having Rust interface directly with the API is much more powerful than this kind of indirection.

Perhaps we can integrate mac-notification-sys to use cacao (as mentioned above) since it already supports UserNotifications—or maybe take inspiration from how it does things?

The other option, which is what I was trying to do a while ago, is to upgrade mac-notification-sys and figure out how to sign it.

[ryanmcgrath]

For what it's worth, the codesigning requirement does get a bit odd for people just looking to release a cross-platform tool. There's realistically an argument to just keep using the older API until it well and truly stops working.

If you wanted to upgrade mac-notification-sys to use the newer API, there's a few things I can think of off the top of my head that are worth noting:

• Definitely feel free to borrow and/or extend the code I used in cacao. I'd be happy to be a second pair of eyes or a sanity check if it's helpful.
• For an app that's going to be a complete .app bundle, the codesigning requirement isn't too thorny. cargo-bundle coupled with a codesign script has worked fine for me in the past.
• For an binary that's not a .app bundle, you could likely make use of the API by embedding the Info.plist. You'd need to pass something like -sectcreate __TEXT __info_plist /path/to/Info.plist as a linker flag, and then run codesign on the resulting binary with an appropriate entitlements file.
• I would maybe keep both APIs (old and new) around, so users in development mode could build and test without needing to go the full codesign route from the start.

[Pandawan]

I'm willing to have another go at this; however, I'm wondering if maybe we can release the current codebase as a new version on crates.io? There have been quite a few changes since the published version was released and I think some of these could be added to notify-rust while we wait.

[nvzqz]

• For an binary that's not a .app bundle, you could likely make use of the API by embedding the Info.plist. You'd need to pass something like -sectcreate __TEXT __info_plist /path/to/Info.plist as a linker flag, and then run codesign on the resulting binary with an appropriate entitlements file.

If you'd rather avoid linker flags, I made embed_plist which handles this with a declarative macro.

[hoodie]

@h4llow3En I think we never made this release, if you want you can make me co-owner on crates.io and I can take that off your hands

[h4llow3En]

@hoodie I send an invite to be coowner

[Pandawan]

I've been trying to get this going again for the past few days with a quick objc-only project and simply cannot get past this issue:

Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'bundleProxyForCurrentProcess is nil: mainBundle.bundleURL

I've even tried with a Console project on Xcode directly and I get the same error. (To be fair, Xcode shows a lot of different options for linking, bundle, etc. so I'm not sure if I set things up properly on there).

I thought that perhaps if I were to codesign, add the appropriate entitlements and Info.plist things would start working.
So I added a quick Info.plist file which is compiled and embedded with build.sh; after this, I codesigned with the Entitlements.plist using the sign.sh script.

However, this seems to get rejected by the OS (killed immediately on start) with the error (in the Console, not from the program directly):

com.migueltenant.foo: Unsatisfied entitlements: com.apple.developer.aps-environment

implying that my push notifications entitlements are not complete but I cannot find any documentation on what the requirements for notification entitlements are. (Note: Adding/Removing sandbox does not change anything)

Note that I've been codesigning with a self-signed certificate as I do not have a paid Apple Developer license. I've tried signing with one of the Xcode auto-generated ones (for development) in my Keychain Access but this does not seem to change anything.

So any thoughts on how to get this working would be appreciated.