Flutter desktop app for MacOS using extra binaries crashes when exported
As it turns out, it was an issue with paths. If I go to my project directory and then enter the debug build directory:
$ cd build/macos/Build/Products/Debug
then from this point I can access two identical asset directories:
$ ls -lh App.framework/Versions/A/Resources/flutter_assets
(output omitted)
$ ls -lh flutter_sample.app/Contents/Frameworks/App.framework/Versions/A/Resources/flutter_assets
(the same output, omitted)
As it turns out, I was actually trying to call the binary in the first asset directory (even though I posted the second one in the question). And apparently the other one is correct when the app is packaged for distribution. After changing this the binaries work in the exported, notarized app.
Rafał G.
Updated on December 30, 2022Comments
-
Rafał G. over 1 year
I want to distribute a Flutter desktop app outside of App Store. The app includes some extra binaries using the
assets
key in pubspec.yaml. The binaries end up in this directory inside the app:flutter_sample.app/Contents/Frameworks/App.framework/Versions/A/Resources/flutter_assets/bin
So that's what I use with
Process.run(...)
and it works locally. However, if I try to notarize the app in Xcode and export it then app will crash immediately when trying to run an included binary. I opened Console and found the following entry in launchd.log corresponding to the time the app crashed:2022-01-07 08:28:04.875197 (gui/501/application.com.example.flutterSample.1772919.1772925) : removing job: caller = runningboardd
2022-01-07 08:28:04.875204 (gui/501 [100020]) : removing service: application.com.example.flutterSample.1772919.1772925
2022-01-07 08:28:04.875309 (gui/501/application.com.example.flutterSample.1772919.1772925) : internal event: PETRIFIED, code = 0 2022-01-07 08:28:04.875311 (gui/501/application.com.example.flutterSample.1772919.1772925) : job state = removedI wasn't able to find any other information about the error. If I enclose the code using
Process.run
in a try-catch block it doesn't change anything, the entire application crashes anyway. The same happens if I use a zone or onError handler as described on the handling errors page in Flutter docs.Extra details:
- I've disabled com.apple.security.app-sandbox in the *.entitlements files, with it running the processes didn't work even locally
- I've enabled hardened runtime in Xcode, it was required to notarize the app.
- the app also crashes if instead or exporting from Xcode I plainly archive the build directory (with
tar
) and send it via internet (or setcom.apple.quarantine
withxattr
). It won't crash if I just pack and unpack it without marking it as quarantined. That makes sense but I expected that notarizing the app would fix it.
So, what can I do to prevent these crashes, or at least get more details when they happen so I can investigate further?
-
Rafał G. over 2 yearsThanks for the suggestion, it was worth a try. Unfortunately it didn't solve the problem. The app wasn't able to copy the binaries to /tmp. I also tried getTemporaryDirectory() from the path_provider package, but that didn't work either.
-
ch271828n over 2 years"The app wasn't able to copy the binaries to /tmp. I also tried getTemporaryDirectory() from the path_provider package, but that didn't work either." -- That may not happen, or your permission setting is wrong. You may create a separate Stackoverflow question and link it here. This suggestion should solve the problem after you can copy the files
-
Rafał G. over 2 yearsI was able to get it to work yesterday. I need to check a few things, I'll get back to this question in a day or two.
-
ch271828n over 2 yearscongrats! the bounty cannot be awarded to yourself and is not refundable. do you think my answer is also helpful
-
Rafał G. over 2 yearsYour answer was worth trying, thanks, but ultimately it didn't solve the problem or make it easier to find the solution. If someone runs into the same problem and finds this thread, I think it might be confusing if they see the bounty went to one of the answers even though it didn't solve the problem. So I'll just let it expire.
-
ch271828n over 2 yearsSure, no problem. "ultimately it didn't solve the problem or make it easier to find the solution" - indeed for someone else sometimes my solution is the only approach or the suggested approach for multi platforms ;) And IMHO accepted answers are at the top.