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.