Building MacOS app runs fine locally, but shows "is damaged and can't be opened" on other machines.

[daring lance]

Has anyone run into this issue? I thought I'd get a security message about running apps from unidentified developers, not "the app is damaged and can't be opened"

[fathom pivot]

yeah, gatekeeper is a bit stricter about arm binaries

if you run x86_64 binaries via rosetta (or on intel systems in general) it will only show a warning

[daring lance]

I see. Makes sense. Thanks 🙏

[terse estuary]

I am on apple silicon and ran rustup target add x86_64-apple-darwin to add x86-64 to my build options, but when I run npm run tauri build --target x86_64-apple-darwin the build chunk sizes and then errors our saying unexpected argument 'x86_64-apple-darwin' found.

[fathom pivot]

npm needs an extra -- to forward the argument to tauri so it's npm run tauri build -- --target x86_64-apple-darwin

[abstract berry]

Never had this issue even on Arm when using github actions to compile it.

Now that I've migrated to 2.0 and there is no actions framework for it and I have to compile locally I'm getting this issue (after uploading and then downloading it to test).

Info.plist on both apps ends up the exact same. seems like Apple trusts Ci more than a local build or something is up with 2.0, not sure. When I run the app locally compiled it works just fine though.

All of this is very strange and I hope there's a way to avoid this without having to use rosetta as suggested previously.

[abstract berry]

@fathom pivot

[fathom pivot]

are you sure you compiled it for arm? This needs a bit extra work in github actions.

tauri-action should work for v2 too btw. well, the desktop bundles at least.

When I run the app locally compiled it works just fine though.
I assume you mean on the same machine? If you move that file to another file it should have the same issues

p.s. nothing changed in tauri.

[abstract berry]

I’m sure because the only rust target I have is Arm and I’m on an M1 MacBook

[fathom pivot]

no i meant what you were building in ci

it was a reaction to this

Never had this issue even on Arm when using github actions to compile it.

[abstract berry]

My app is desktop only and I already had a configuration for my tauri v1 app but of course it doesn’t run now

What are the steps to make t2.0 compatible for the actions repo?

[abstract berry]

Ah, I should have specified that was on tauri 1.x

Before I migrated

My mistake

[fathom pivot]

i understood that

[abstract berry]

I have a targets for both arm and x86 in gh actions if that’s what your asking

I don’t compile to anything but mac though

[fathom pivot]

basically yeah.

[abstract berry]

Sorry if my messages are slow or hard to read, typing on mobile is a pain in the ass

[fathom pivot]

My app is desktop only and I already had a configuration for my tauri v1 app but of course it doesn’t run now
It may not be fully up to date since there were a few new changes but our migration guide is here: https://beta.tauri.app/guides/upgrade-migrate/from-tauri-1/
What are the steps to make t2.0 compatible for the actions repo?
If your project works with v2 on desktop it should work as-is in CI.

[abstract berry]

Ah actually I may know the issue now

I forgot to mark a devtools thing for debug_assertions before I started the action

I’ll try again and see if that helps

Thanks so much for the help though

[abstract berry]

@fathom pivot

Run tauri-apps/tauri-action@v0
running npm [ 'install', '-g', '@tauri-apps/cli' ]

added 2 packages in 27s

1 package is looking for funding
  run `npm fund` for details
running tauri [ 'build' ]
       Error `tauri.conf.json` error on `tauri > bundle`: Additional properties are not allowed ('updater' was unexpected)
       Error `tauri.conf.json` error on `tauri > security`: Additional properties are not allowed ('assetProtocol' was unexpected)
Error: Command failed with exit code 1: tauri build

Locally it builds just fine

Seems like it's expecting a Tauri 1.x style config file?

Any way to configure it to install the 2.0.0 alpha cli?

[fathom pivot]

right, it will install the 1.0 cli if your project doesn't have one installed already

[abstract berry]

So should I add the 2.0 cli to my package.json devDependencies?

[fathom pivot]

yes, or install the cargo based one

or do what the action does

if you use the cargo or a global install you'll have to set the tauriScript config

[abstract berry]

A couple other changes and I've got it all working

Once again thanks for the help

Yeah for some reason when it's built on a gh actions machine and then uploaded to a bucket I just get "developer cannot be verified" instead of saying its "damaged"

Quite strange

Apple is weird

[fathom pivot]

that's putting it nicely :D

[abstract berry]

yeah lmao

Now I'm getting a segfault on the actions build when I run it

wtf

wish me luck

[abstract berry]

long story short I was compiliing to intel on gh actions the whole time due to some oversights on my part

I'm getting the same "x is damaged" alert as before.

@fathom pivot besides getting the app notarized, are there any other options for the Arm version?

[fathom pivot]

that's what my first question was about

[fathom pivot]

i think you can deactivate some security mechanism and then use xattr -c on the binary to run it

not viable if you have actual users but for your and (tech savvy?) friends it may be enough

[abstract berry]

yeah i misunderstood

[abstract berry]

Just enrolled in the apple developer program, my account is still "Pending," have heard some bad stories about it taking forever so I'm hoping that's not me 🤞

I hate apple ngl

[fathom pivot]

same

[timber pier]

sorry for bothering you on this old thread but i had the same problem and manged to fix it thanks to what it was written here so to start, thank you very much for all the info. i was wondering though where did you find this thing about gatekeeper and arm binaries? is it something made public by apple somewhere or comes from experience?

[fathom pivot]

I always based this on the general consensus (what i've seen here and on SO etc) but according to search engines it looks like Apple actually warned about this in the Big Sur announcement back then. (for example https://eclecticlight.co/2020/08/22/apple-silicon-macs-will-require-signed-code/)

[timber pier]

ok thanks. and do you confirm that this has nothing to do with tauri itself or how it builds the app and the bundle?

[fathom pivot]

Yes, this applies to all apps no matter the framework used.

That said, until Apple notices/fixes it, you can self-sign your app to make it behave like x86 apps by adding "signingIdentity": "-" to the tauri config.