Pkg installation package uploaded to macstore email prompt ITMS-90296

First things first, the TestFlight issue (ITMS-90886) is covered by TestFlight, Provisioning Profiles, and the Mac App Store.

Regarding the App Sandbox issue (ITMS-90296), there’s a variety of potential causes for this. I recommend that you check whether App Sandbox is actually enabled on the binary that you submitted to App Store Connect. To do that:

1. Locate the installer package (.pkg) you submitted.

2. Unpack that. I usually do this with a third-party app (Pacifist), but Unpacking Apple Archives explains how to do it the hard way.

3. Run codesign against the resulting app to confirm that its signature is valid:

   % codesign --verify -vvv /path/to/your.app
   

4. Run codesign again to check that you have App Sandbox enabled:

   % codesign --display --entitlements - /path/to/your.app
   

   I’d expect to see output like this:

   % codesign --display --entitlements - /Applications/PCalc.app 
   …
   [Dict]
       …
       [Key] com.apple.security.app-sandbox
       [Value]
           [Bool] true
       …
   

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

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

I noticed an error message

Yeah, that’s not good, and it’s quite possible that it’s causing your other problems.

The ._node_modules file is an AppleDouble file. The __MACOSX directory suggests that you’re using sequestered resources. This is problematic for an installer package that you’re submitting to the Mac App Store.

I talk about these concepts in more detail in Extended Attributes and Zip Archives.

You need to track down how these items made it into your installer packages. In general, your app shouldn’t need to use extended attributes. You should work out what extended attributes are present and update your build process so that they don’t get added. If you have to keep them for some reason, let me know the reason and we can talk about that.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

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

Amazing, it worked.

Yay!

But now I have encountered another problem and need your help The following entitlement is not set in my entitlement. plist file:

My understanding is that you’re not using Xcode to sign and package your app. Given that, there’s a limit to how much I can help you with this. Your third-party tooling is probably based on Apple’s low-level tools, xcodebuild (perhaps), Clang, codesign, and so on. Those tools don’t add entitlement claims spontaneously. They only do that if you instruct them to. So you have two choices:

• Seek help from the support channel for the tools you’re using.

• Or take ownership of the tool, and work through the steps that it takes to create your package to see where it’s adding these entitlement claims.

If you get to a point where you see an Apple tool misbehave, please post the details and I’ll take a look.

With regards entitlements specifically, when manually signing code you use the codesign tool. You can find advice on how to use that correctly in Creating distribution-signed code for macOS.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

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:

1. Before I signed the app, it could run normally, but after I signed it, I found that the app package could no longer run.
2. I submitted the version to Apple Connect, but even after downloading it through TestFlight, I couldn't open it.
3. Even if I turn off sandbox mode in the entities file, I cannot open it after signing.
4. 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

Before I signed the app, it could run normally, but after I signed it, I found that the app package could no longer run.

That’s not necessarily indicative of a problem, assuming you’re using distribution code signing. See Don’t Run App Store Distribution-Signed Code.

If you want to test this locally, use the same signing process but sign it with an Apple Distribution signing identity.

Regarding provisioning profiles, you only need a provisioning profile if you use restricted entitlements. The entitlements to enable the App Sandbox are not unrestricted. See TN3125 Inside Code Signing: Provisioning Profiles.

You will need to use restricted entitlements to deploy via TestFlight [1], but you can ignore it when you do the local test I suggested above (that is, signing with Apple Development).

If your development-signed code has problems launching, see Resolving Trusted Execution Problems for hints and how to investigate that.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] See TestFlight, Provisioning Profiles, and the Mac App Store.

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:

1. Isn't that correct? Or is it true that it cannot be opened
2. Where might the problem lie

I hope to receive your help

Thanks for the clarification.

However, when I downloaded the corresponding version from Testflight on my local computer, I couldn't open it

So, to be clear, by “downloaded the corresponding version from Testflight” you mean that you’re installing that version using the TestFlight app, right?

If so, then, no, this shouldn’t crash. However, there’s no guarantee that this crash is related to code signing. Release versions of an app can crash for all sorts of weird reasons.

Does running the app generate a crash report? If so, please post it here, using the steps described in Posting a Crash Report.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

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

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.

I use @ electron/osx sign to sign

The entitlement information displayed in Apple Connect is as follows:

Then unable to open

This is the complete crash log file

Thanks. This is a classic hardened runtime incompatibility crash. I talk about these in Resolving Hardened Runtime Incompatibilities, part of my Resolving Trusted Execution Problems series.

It seems that the code hitting this is inside your third-party runtime. Usually you can resolve such crashes by signing the code with one of the hardened runtime exception entitlements. I can’t offer advice as to which one is appropriate in this case; you’ll need to ask that via the support channel for your chosen runtime.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

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

If so, is there a tool to check which entities should be provided?

No, because the answer depends on what your code does. Let’s consider two common cases:

• If your code implements a JIT using modern techniques — that is, MAP_JIT — then you you need com.apple.security.cs.allow-jit.

• OTOH, if your code hasn’t been updated recently, you need com.apple.security.cs.allow-unsigned-executable-memory.

You need to either understand how this code works or talk to someone who does.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

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 ?

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