Sorry, forgive me, I have made a new discovery and added two entities (com. apple. security. cs.allow jit) and com. apple. security. cs.allow-Unsigned-executable memory, ） The inability to open now is different from the past. Previously, if it couldn't be opened, a crash record would be generated. Now, if it can't be opened, no crash record will be generated, and the Mac console app cannot see it. Only the dock bar jumps to exit. I don't know if this information is critical

I tried using com. apple. security. cs.allow jit and com. apple. security. cs.allow-Unsigned-executable memory, and also tried to generate an empty shell app (the main function only opens a blank window), but after uploading it to app connect and downloading it on TestFlight, I still couldn't open it. Suddenly, I thought of something, that is, the version I uploaded can be opened by testers in the Mac store, but the same version, only the one I downloaded from TestFlight cannot be opened. Is there any difference between the two ?

I have read the link article you provided, and I understand that my problem may be due to some missing entities in the configured entities file. If so, is there a tool to check which entities should be provided? This project includes many modules, and I am not sure what specific entities are needed

Thank you, as you said： you’re installing that version using the TestFlight app This is indeed what I meant Then I checked my crash log and found that it may still be related to the signature This is the complete crash log file Mac crash information.txt Then this is the entitlement file I used to sign, where the entitlement. mas file is used for signing the main program, and the entitlement. mac. other file is used for signing other internal executable files. entitlements.mas.txt entitlements.mac.other.txt I use @ electron/osx sign to sign The entitlement information displayed in Apple Connect is as follows: Then unable to open

Sorry, I didn't express my problem clearly. The phenomenon I encountered was ： when I successfully uploaded the application to Apple Connect, I could see this version in Testflight, and the reviewers in the Mac store could also open my application. However, when I downloaded the corresponding version from Testflight on my local computer, I couldn't open it(I could see some crash messages in the Mac console), and even another computer couldn't install it directly (it suddenly disappeared as the download progress bar was about to end and turned into a download button) My question is: Isn't that correct? Or is it true that it cannot be opened Where might the problem lie I hope to receive your help

You're right, I'm not using XCode for development. I know why this issue didn't occur, and I hope it can be helpful for those who come across this blog in the future. But now I have encountered another problem and need your help The following entitlement is not set in my entitlement. plist file: The reason for this issue is that when using @ electron/osx sign for signing, some parameters in the old option were invalid, resulting in the execution of the default entitlement. plist file in the node_module package. But now, I have encountered a new problem and I hope you can help me take a look: When I submitted a new binary file for review, I received a response saying that the software could not be opened, and other phenomena included: Before I signed the app, it could run normally, but after I signed it, I found that the app package could no longer run. I submitted the version to Apple Connect, but even after downloading it through TestFlight, I couldn't open it. Even if I turn off sandbox mode in the entities file, I cannot open it after signing. When I don't carry entitlement or provisioning profile, I use the command line directly. %Codesign - f - i com. iflyrec. iflyrec Client - s "3rd Party Mac Developer Application: IFLYREC CO., LTD. (66927FHK7D)" - v "./iFlytek Listen. app" -- deep Sign it and it will open normally. I found through positioning that the problem may have occurred during the signing process. But I'm not sure if the problem lies in the fact that the signature carrying the entitlement and provisioning profile itself cannot be opened, or if there is a problem with the OSX sign signature. I hope you can help me take a look

Amazing, it worked. Thank you!The problem is that after packaging it, I used %unzip ... to unzip a file into the app package, resulting in the appearance of the MacOS folder after packaging.After deleting it, the issue was resolved But now I have encountered another problem and need your help The following entitlement is not set in my entitlement. plist file: com.apple.security.device.camera com.apple.security.files.bookmarks.app-scope com.apple.security.print com.apple.security.device.usb I didn't even mention it throughout my entire project, But after I signed the app, I found that they appeared in my app and I wanted to remove them. Can you help me to handle it

I tried using a third-party app (Pacivist) to open the app in pkg, nd export the app locally，then followed your instructions to perform the following actions: 1、 Run codesign against the results app to confirm that its signature is valid: % codesign --verify -vvv /path/to/your.app The results obtained: PS:I noticed an error message IFlytek heard. app: a sealed resource is missing or invalid File missing:/Users/pploo2/Desktop/icon/1/iFlytek heard. app/Contents/Resources/tj_S1/_MACOSX/ node_modules I don't know if this is the key to the problem ITMS-90926. 2. Run codesign again to check that you have App Sandbox enabled: % codesign --display --entitlements - /path/to/your.app The results obtained: You can see that there is sandbox=true here Now back to the first step, I performed operations on the app before packaging it as pkg and found that there were no missing related issues