Needing workaround for subprocess in signed application bundle

[ErikBjare]

I'm trying to use this library from a PyInstaller-built binary aw-notify running as a subprocess in my application.

The whole thing is correctly signed with PyInstaller (see spec file). The CFBundleExecutable is aw-qt, which manages aw-notify as a subprocess.

However, the subprocess doesn't seem to get NSBundle.mainBundle.bundleIdentifier set. Which fails the check at:

https://github.com/samschott/desktop-notifier/blob/233d8c8981945c64fb92df2dbade908624896b7b/src/desktop_notifier/macos_support.py#L55C11-L55C11

@samschott wrote here:

The alternative would be to try and fake a valid bundle identifier at runtime. Some other packages do this but its a nasty hack and will prevent any apps using it from being accepted in the App store.

I am now assuming that I would need some kind of workaround like that, and that things would probably work if it wasn't for this NSBundle check (hopeful/wishful thinking).

Since the testing process is rather lengthy for me, given how I have to wait for CI to sign etc, I thought I'd make this issue before I venture further. I've only done a little bit of research on this, and am not sure if I'm likely to meet further resistance once I've worked around the bundleIdentifier check.

[samschott]

Sorry for not getting to this earlier. If this is still an issue:

NSBundle.mainBundle should indeed return the bundle that the aw-notify is contained in, but maybe checking for the presence of a bundle identifier is indeed too hard of a requirement.

If you remove those checks all-together from

desktop-notifier/src/desktop_notifier/main.py

Line 73 in 233d8c8

if has_unusernotificationcenter and is_signed:

, do you get a segfault when initialising DesktopNotifier in your bundled app? If not, it suggests that at least some of those checks are not required.

If it does segfault, the underlying problem lies likely in how PyInstaller bundles your executables into an app.

[samschott]

I am not at all familiar with PyInstaller and how it would bundle multiple executables, and Apple's documentation on which type of executables are allowed to send desktop notifications is also scarce.

If bundling is indeed the issue: The typical approach would be to include a full helper app nested in your app bundle (Chrome does this for example with "Google Chrome Helper (Alerts).app", so does the Sparkle update framework). Standalone signed executables are more common as command line tools or helpers, as described at https://developer.apple.com/documentation/xcode/embedding-a-helper-tool-in-a-sandboxed-app, and I would not be completely surprised if those are not allowed to send notifications.

[michelcrypt4d4mus]

_ I would not be completely surprised if those are not allowed to send notifications._

i'm actually using this package right now from an embedded helper app inside another bundle and it's working fine so i can confirm this isn't the issue... though in order to get it to work (to get the whole app bundle, not just this package) i had to manually handle all the codesigning, including manually resigning a bunch of compiled python libraries and the python executable after i packaged it up with briefcase which is similar to pyinstaller.

You set the bundle ID when you code sign. Also according to some of apple's docs on embedded apps it is important that the embedded app have a bundle id that's an extension of the one it's embedded into. their example:

• main bundle id: com.example.apple-samplecode.AppWithTool
• embedded app com.example.apple-samplecode.AppWithTool.ToolX

i don't know if that actually matters bc i did it the way apple suggested from the jump but it's definitely something to try.