App crashes when built in release & with code-signing

[high socket]

When I compile and sign my app with the following script that I wrote, then I am not able to run the app anymore. Without signing, it works, but when I do add the signing process, it crashes immediately.
This is the lldb output I get:

lldb BMM
(lldb) target create "BMM"
Current executable set to '/Users/skyline/Programming/balatro-mod-manager/src-tauri/target/release/bundle/macos/Balatro Mod Manager.app/Contents/MacOS/BMM' (arm64).
(lldb) process launch
error: process exited with status -1 (attach failed (Not allowed to attach to process.  Look in the console messages (Console.app), near the debugserver entries, when the attach failed.  The subsystem that denied the attach permission will likely have logged an informative message about why it was denied.))

And this is the script that I run:

#!/bin/bash

SIGN_IDENTITY=$(security find-identity -v -p codesigning | grep "Developer ID Application" | awk -F'"' '{print $2}')
APPLE_SIGNING_IDENTITY=$SIGN_IDENTITY
APPLE_CERTIFICATE="certificate-base64.txt"
APPLE_CERTIFICATE_PASSWORD="<my password>"
APPLE_ID="<my apple id>"
APPLE_PASSWORD="<my app-specific password>"
APPLE_TEAM_ID="<my team id>"

cd .. && make release

• Output of codesign -dv --verbose=4 "Balatro Mod Manager_0.1.0_aarch64.dmg":
  https://pastebin.com/QvnKEsZm
• Makefile: https://pastebin.com/ND5AzHTj
• Entitlements.plist and Info.plist are also given.

@low hatch what do you think?

[high socket]

I'm probably not the only person having a problem, but I think this might be caused by tauri?

[twin inlet]

@high socket did you just start having this problem? was it working previously?

[high socket]

No, it didn't work previously too. I never got it working

[twin inlet]

Typically if the app doesn't run after signing, its the OS protecting against something that doesn't match in the entitlements or the signature of the codesign itself

what version of tauri build are you using?

[high socket]

tauri-build = { version = "2", features = [] }

[twin inlet]

I'm not super familiar with the library you're trying to add via the makefile, but most likely its the OS blocking that. Have you tried using entitlements for dyld loading? or jit?

[high socket]

For them too?

[twin inlet]

It depends on what your library is trying to do

[high socket]

Well, it's this library that I am using

this is for example the build.rs that I am using for one of my crates, that does this library:

use std::env;
use std::path::PathBuf;

fn main() {
    if std::env::var("SKIP_BUILD_SCRIPT").unwrap_or("0".to_string()) == "1" {
        return;
    }
    #[cfg(target_os = "macos")]
    {
        let manifest_dir = env::var("CARGO_MANIFEST_DIR").unwrap();
        let lovely_mac_dir = PathBuf::from(&manifest_dir).join("../lovely-injector");
        let lovely_bin_dir = dirs::config_dir()
            .expect("Could not find config directory")
            .join("Balatro")
            .join("bins");
        //
        // // // Build lovely-mac first
        // let status = Command::new("cargo")
        //     .args(["build", "--release"])
        //     .current_dir(lovely_mac_dir.join("crates/lovely-mac"))
        //     .status()
        //     .expect("Failed to build lovely-mac");
        //
        // if !status.success() {
        //     panic!("Failed to build lovely-mac");
        // }
        //
        // Get the correct dylib path
        let dylib_path = lovely_mac_dir.join("target/release/liblovely.dylib");

        if !dylib_path.exists() {
            panic!("Dylib not found at expected path: {}", dylib_path.display());
        }
        //
        // // Generate the Rust code with the dylib path
        // let out_dir = PathBuf::from(env::var("OUT_DIR").unwrap());
        // let code = format!(
        //     "pub const LOVELY_DYLIB: &[u8] = include_bytes!({:?});",
        //     dylib_path
        // );
        //
        // std::fs::write(out_dir.join("lovely_dylib.rs"), code)
        //     .expect("Failed to write generated code");

        // move liblove.dylib to the correct location (config/Balatro/bins)
        std::fs::copy(&dylib_path, lovely_bin_dir.join("liblovely.dylib"))
            .expect("Failed to copy liblovely.dylib to bins directory");

        println!("cargo:rerun-if-changed={}", dylib_path.display());
    }
}

[twin inlet]

yeah, most likely you need to adjust your entitlements, have you tried not including entitlements at all to start? see if you can just raw codesign and run?

[high socket]

doesn't it need the entitlements?

[twin inlet]

depends on what you're trying to do

like my app is not distributed on app store, and so the only entitlement i have is multicast support

i'm not using sandboxing

[high socket]

I was not really sure what I had to include in the Entitlements.plist, but does it really matter if my app needs more access?

[twin inlet]

try not including an entitlement, its worth a shot

sandbox locks down your app pretty hard from what i'm reading, and thats needed for app store deployment

[high socket]

Alright, let me try

it's building...

Nope

still crashes

[twin inlet]

Are you notarizing?

[high socket]

I am building with the script

[twin inlet]

Ok cool

So when you run, are you getting the Mac OS crash report?

[high socket]

nope

[twin inlet]

Hmm

[high socket]

But this could maybe be caused, because I accidently clicked "Ignore" or something like that 3hrs ago

[twin inlet]

Wait so how is it crashing?

If it’s truly crashing, you’d see a macOS crash report

[high socket]

Yes I know and I was getting one sometimes

very weird

[twin inlet]

So does it just open and then close?

[high socket]

Exactly

but only when I sign the app

when I build it without signing it, it works perfectly fine

[twin inlet]

Yeah it’s your OS going into protection mode

Try checking the system logs

[high socket]

What's the path again?

[twin inlet]

Just open terminal and run log

log stream --info | grep AppName

You can also use console

[high socket]

is it in /Library/Logs/DiagnosticReports?

[twin inlet]

It may be

[high socket]

but the latest one I have is from 1h ago

[twin inlet]

What does that one say?

[high socket]

nvm I just ran the command and then the app

here

[twin inlet]

So I out running some errands but a quick check looks like the sandbox setting and some missing entitlements may be the cause

[high socket]

I think so too

So I do need the Entitlements.plist and I need to adjust it?

[twin inlet]

I would recommend looking through the various entitlements on Apple developer to see if you’re missing some that you should have based on what your application is trying to do

Everyone’s application is different so it’s hard to say for your exact use case, plus you’re doing dynamic library loading, which adds a layer of complexity to it. I know they get really strict with that stuff now

When in doubt you can always reach out to Apple Support, I think you get two free support cases a year, and ask them to look into your app as well and let you know what entitlement you would need

[high socket]

With Apple Developer I only get 2 free support cases??

[twin inlet]

Per year yes, I think after that you have to pay for each Support case at like a fixed cost. If you still have questions after that, feel free to reach out to me, I’ve been around the block with Apple on a lot of this code signing stuff with my own app. I’m using Frameworks though and so it’s a little different. you may also need to sign the library file separately as well. Have you tried doing that?

[high socket]

Do I need to do that in the building process?

[twin inlet]

Tauri CLI will automatically sign frameworks that are listed in the config, but I don’t believe it does individual files that you manually include, i’m out running errands so I can’t look right this moment

So yeah, you would probably need to manually sign it during your build process

[high socket]

I see. If I would ask Apple about my project, would they be able to create an Entitlements.plist for me or do I have to do that manually? (also asking about the dynamic library)

[twin inlet]

I’m not sure, good luck lol

Hopefully they can point you in the right direction at least

Unless you’re distributing on the App Store, I don’t see a reason to use sandbox?

Maybe take that away, manually sign the library, and try again

You can also validate code signing manually after to fact to ensure it all looks correct

[high socket]

So it would just use the manually signed library then, correct?

hold on

wtf did I do

you were right

no way

there is

no way

[twin inlet]

Working?

[high socket]

I just removed the sandbox thing

it works now

@twin inlet omg thank you so much

[twin inlet]

Perfect! Anytime! Been there lol

[high socket]

/Users/skyline/Programming/balatro-mod-manager/src-tauri/target/release/bundle/dmg/Balatro Mod Manager_0.1.0_aarch64.dmg: valid on disk
/Users/skyline/Programming/balatro-mod-manager/src-tauri/target/release/bundle/dmg/Balatro Mod Manager_0.1.0_aarch64.dmg: satisfies its Designated Requirement

so it is signed now?

[twin inlet]

If you right click the app and view properties it should say for sure

[high socket]

where does it say that?

[twin inlet]

Hmm I thought it said it there

Guess not

[high socket]

codesign -dv Balatro\ Mod\ Manager.app/

Executable=/Applications/Balatro Mod Manager.app/Contents/MacOS/BMM
Identifier=com.balatro-mod-manager.app
Format=app bundle with Mach-O thin (arm64)
CodeDirectory v=20500 size=146791 flags=0x10000(runtime) hashes=4576+7 location=embedded
Signature size=9055
Timestamp=27. Jan 2025 at 23:13:01
Info.plist entries=17
TeamIdentifier=<my team id>
Runtime Version=15.2.0
Sealed Resources version=2 rules=13 files=5
Internal requirements count=1 size=188

I got this output

So, I would be able to share it now?

Like distribute it?

[twin inlet]

Yeah should be able to!

[high socket]

Hold on I'll try

I am so excited omg

Noone is online rn that I know of, that has a mac

Is there any way I can try this in a vm or something similar?

[twin inlet]

If you have Parallels you can create a VM

Really quickly actually, that’s what I do

[high socket]

Yes let me try

[high socket]

Ok, I think in the vm it doesn't run

@twin inlet

[twin inlet]

what does the report say?

[twin inlet]

it looks like your app killed itself

[high socket]

but I ran the same dmg on my main machine and it worked?

[twin inlet]

and if you dont code sign does it run on the vm?

[high socket]

Good questions

let me try

[twin inlet]

because if it doesn't run still, then your rpath may be screwed up

Tauri automatically adds the proper rpath's for frameworks but not single DYLIBs that i'm aware of

[high socket]

wait what would I need to do here again?:

"macOS": {
      "entitlements": "Entitlements.plist",
      "minimumSystemVersion": "10.13",
      "signingIdentity": "Developer ID Application: Me (My Team ID)",
      "providerShortName": "Team ID",
      "frameworks": [],
      "hardenedRuntime": true
    }

[twin inlet]

you would need to do it manually i think, since you're not using a framework

[high socket]

But I mean it wouldn't work anyways because it's a different machine, no?

[twin inlet]

it would pop up saying unverified publisher or something to that extent

it wouldn't crash

if its crashing on a different machine too without codesigning then thats a problem with your library linking

[high socket]

So, it has something to do with the library linking?

But why would it then work on my machine?

@twin inlet I don't think it has something to do with the library linking, cuz why would it work on my machine then?

[twin inlet]

you may have the library in a common place. The OS looks in multiple folders on your machine for the library. when you package the app for distribution, you have to make sure the library is in the app package and that the rpath is set so the OS knows where to find it

https://github.com/tauri-apps/tauri/issues/7710

This was something we did back in v1 for Frameworks. You may need to do this manually depending on where you're copying the dylib to.

Like i said though, if it works on the VM without codesigning, then thats not it. But if it doesn't work regardless then i would lean towards this being the issue

[high socket]

Alright, I will try this solution and see if it works. But it's pretty late here so I will go to sleep now and implement it tomorrow. Would it be ok, if I would text u tomorrow?

[twin inlet]

No problem!

[high socket]

You might be right about the thing with the dynamic library. I found a post about a similar issue but for iOS: https://forums.developer.apple.com/forums/thread/670761

[high socket]

(ignore this, I just need to paste it somewhere):

"macOS": {
      "entitlements": "Entitlements.plist",
      "minimumSystemVersion": "10.13",
      "exceptionDomain": "",
      "signingIdentity": null,
      "providerShortName": null,
      "frameworks": []
    }

[high socket]

@twin inlet hey, it's been a few days, but I've been trying to work on this and I still can't get it to work :/. If you have the time, could you maybe hop in a call so I can show you in realtime?

I tried contacting Apple, but they said that they don't provide "technical" support (although it literally says that in their name)

@twin inlet I am genuinely crashing out rn. You are my only chance to getting this fixed & I think this is one of the most annoying issues I have ever gotten thanks to Apple

[twin inlet]

Hey @high socket I’ll direct message you

[safe wren]

Reboot

I’m struggling with this also when trying to bundle gstreamer

[high socket]

I already fixed it by not using any dynamic libraries

[safe wren]

Bleh