Switch to UN* API - Githubissues

flying-sheep commented 5 years ago

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 commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

@Pandawan FYI If you still have the time 🙂

Pandawan commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

[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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

@hoodie I send an invite to be coowner

Pandawan commented 2 years ago

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.

h4llow3En / mac-notification-sys

Switch to UN* API #10