ERROR ITMS-90075 submitting to iTunes with FB & Air 28 using dynamic frameworks

Report · Feb 12, 2018

We are having trouble uploading our Air app to the ios appstore with the the new external framework code sigining in Air 28 with FB with the following error: "ERROR ITMS-90075: "This bundle is invalid. The application-identifier entitlement is missing; it should contain your 10-character Apple Developer ID, followed by a dot, followed by your bundle identifier."

Usually, this is due to using the wrong provisioning profile or not having the correct bundle id or app id in app.xml match the provisioning profile. But not in this case.

Before this, we were using Air 25, and using a script to "re-sign" the external frameworks and .app before submitting to Apple, and that was working fine. We also tried the resigning script with Air 28 but that didn't solve the problem.

In terms of troubleshooting:

1. if we simply uncheck the "Frameworks" folder (containing the external frameworks and swift dylibs) in the packaging settings for the release build, the app is accepted by itunesconnect. If we include the "Frameworks" folder in the packaging, no dice, we get the ERROR ITMS-90075 error shown above.

2. suspecting this has something to do with code signing and entitlements with FB, we used Xcode to resign and upload to the appstore, and were successful doing it this way:

- created a dummy app in Xcode and archived it

- opened the xcode archive and replaced the dummy .app with the .app from the release build made by FB and updated the info.plist in the archive folder.

- deleted the _Codesign in .app and deleted the embedded frameworks in the "Frameworks" folder and replaced those with unsigned copies.

- copied the SwiftSupport folder from the FB .app to the copy now in the Xcode archive folder.

- used xcode to resign the app and frameworks and upload to the appstore. - Success!

3. Comparing the re-signed .app using xcode to the original from FB, the main difference seems to the that FB is applying entitlements with the code signing, and Xcode is not.

Anyway, we finally were able to upload the app store, but it required a convoluted messy procedure above using xcode to do it. Again, this seems like a problem with the way FB is packaging/signing the app, but not certain.

Report · Nov 15, 2018

Are you including Entitlements in your app.xml perchance?

I am finding that when I include any Entitlements I get this same error.

Without Entitlements everything is OK.

Digging further it appears that dynamic frameworks have a subset of the apps Entitlements applied when packaged.

It is missing application-identifier & get-task-allow & beta-reports-active

codesign -d --entitlements :- "/user/bin-release/iOS_Store/Payload/Example.app"

Executable=/user/bin-release/iOS_Store/Payload/Example.app/Example

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
    <dict>
        <key>application-identifier</key>
        <string>XXXXXXX.com.company.example</string>
        <key>get-task-allow</key>
        <false/>
        <key>beta-reports-active</key>
        <true/>
        <key>com.apple.developer.associated-domains</key>
        <array>
            <string>applinks:xxxxx.app.goo.gl</string>
        </array>
        <key>keychain-access-groups</key>
        <array>
            <string>XXXXXXX.*</string>
        </array>
        <key>com.apple.developer.team-identifier</key>
        <string>XXXXXXX</string>
        <key>aps-environment</key>
        <string>production</string>
    </dict>
</plist>

codesign -d --entitlements :- "/user/bin-release/iOS_Store/Payload/Example.app/Frameworks/FreSwift.framework"

Executable=/user/bin-release/iOS_Store/Payload/Example.app/Frameworks/FreSwift.framework/FreSwift

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
    <dict>
        <key>com.apple.developer.associated-domains</key>
        <array>
            <string>applinks:xxxxx.app.goo.gl</string>
        </array>
        <key>keychain-access-groups</key>
        <array>
            <string>XXXXXXX.*</string>
        </array>
        <key>com.apple.developer.team-identifier</key>
        <string>XXXXXXX</string>
        <key>aps-environment</key>
        <string>production</string>
    </dict>
</plist>

The reason for that appears to be this block in MachOSigner.java in adt.jar

I'm not sure I understand why these are removed for the dynamic Frameworks??

It appears to cause the app to be rejected with the above error

if ((this.frameworkEntitlementsPlist != null) && (this.entitlementsPlist == null)) {
    dict.removeNode("application-identifier");
     dict.removeNode("get-task-allow");
     if (dict.getNode("beta-reports-active") != null) {
         dict.removeNode("beta-reports-active");
     }
     entitlementsString = this.frameworkEntitlementsPlist.getXMLString();
     entitlementsString = entitlementsString.replace('\r', ' ');
}

michaelarchbold

Rohit Guglani

I think it's imperative that this be resolved for the AIR32 release. It should hopefully be a quick fix. The issue hampers greatly the use of dynamic frameworks which are becoming more prevalent. Having to use resigning scripts is extremely user un-friendly.

Report · Nov 15, 2018

The most common reason we've run into this error is when you are attempting to use a signed dynamic framework. In my discussions with the Adobe devs they are currently ignoring frameworks that are already signed and so the error above is produced. I haven't been able to get a reason for this but it seems to be an error from my perspective.

Most frameworks provided from service providers are signed and you need to resign them when packaging in an application.

Our method of getting around this has just been unpacking the IPA, signing those frameworks, and then repackaging.

Eg this one is for the Branch framework

Resign Script for Adobe AIR applications using the Branch ANE · GitHub

Definitely agree Adobe need to resolve this as dynamic frameworks are becoming common place. I'll push the AIR devs I have been in contact with again to see if they have made any progress yet.

air native extensions // https://airnativeextensions.com

Report · Nov 16, 2018

Did anybody create ticket in jira for this error? If so - could u provide us with a link to this. Thanks

Report · Nov 17, 2018

Sourabh Gupta

Although similar there are 2 separate issues.

1) Incorrect Entitlements applied to Dynamic Frameworks

2) Packaging already signed Dynamic Frameworks

I am referring here to #1. Dynamic Frameworks (FreSwift, SwiftyJSON) are distributed Unsigned, as per current Apple recommendations.

I experimented with different modifications to adt.jar and found what appears to work.

I set the Framework entitlements to a basic plist with no entries. This matches what Xcode appears to generate.

This now passes App Store validation and also runs on the device. The .app is signed correctly including Entitlements, Frameworks are signed correctly.

Here are the modifications.

adt.jar MachoSigner.java (Before)

private byte[] newEntitlementBlob(boolean isDistributionCert)
            throws GeneralSecurityException, IOException
    {
...
String entitlementsString = null;
if ((this.frameworkEntitlementsPlist != null) && (this.entitlementsPlist == null)) {
...
}

adt.jar MachoSigner.java (Modified)

private byte[] newEntitlementBlob(boolean isDistributionCert)
            throws GeneralSecurityException, IOException
    {
...
String entitlementsString = null;
if ((this.frameworkEntitlementsPlist != null) && (this.entitlementsPlist == null)) {
    entitlementsString = "<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"no\"?><!DOCTYPE plist PUBLIC \"-//Apple//DTD PLIST 1.0//EN\" \"http://www.apple.com/DTDs/PropertyList-1.0.dtd\"><plist version=\"1.0\"><dict/></plist>";
}

I have uploaded the modified adt.jar for AIR31 to GitHub

It is inside AIRSDK_additions.zip here:

https://github.com/tuarua/Swift-IOS-ANE/releases/download/2.5.0/AIRSDK_additions.zip

I have uploaded the modified adt.jar for AIR32 to GitHub

It is inside AIRSDK_patch.zip here:

https://github.com/tuarua/Swift-IOS-ANE/releases/download/3.0.0/AIRSDK_patch.zip

Here is the existing tracker ticket

https://tracker.adobe.com/#/view/AIR-4198588

Re: 2 and Branch

I don't see a _codeSignature on Branch.framework

Not to doubt you, but is it definitely already code signed?

Report · Feb 21, 2019

Hello,

Replace the attached adt.jar at location "AIRSDK->lib->adt.jar".

Find the link for new adt.jar : https://adobe.ly/2Td8Vlc

This should address the issue of missing tags (application-identifier and get-task-allow).

Kindly verify this and inform , if it solves your problem.

Thanks and regards,

PRANAV CHATURVEDI

Adobe AIR Team

Report · Feb 21, 2019

Hi Pranav,

Thanks for looking at this.

With that jar it still produces an error.

Error Domain=ITunesConnectionOperationErrorDomain Code=1091

Invalid Code Signing Entitlements. Your application bundle's signature contains code signing entitlements that are not supported on iOS. Specifically, value 'XXXXXXX.com.abc.abc' for key 'application-identifier' in 'Payload/XXXXXXX.app/Frameworks/FreSwift.framework/FreSwift' is not supported. This value should be a string starting with your TEAMID, followed by a dot '.'

My initial theory was that the 2 tags should be kept.

However I found that no entitlements should be applied to dynamic frameworks at all! This matches what Xcode produces if building a native app with dynamic frameworks. The entitlements are an empty plist. I used codesign to deduce this.

See my message from December 27th. This java, which applies an empty plist Dictionary as the entitlements has been working for me on my patched version of adt.jar

Report · Feb 21, 2019

Hello,

The error message by ITunesConnect suggests the value received in the key pair application-identifier is not supported.

The value is "XXXXXXX.com.abc.abc" which contains:

1. XXXXXXX from the .mobileprovision provided during the signing

2. com.abc.abc provided in the app-xml

According to previous error ITunesConnect suggested that application-identifier tag is missing, compared to the new error that the key application-identifier is present but the value assigned to it is incorrect.

Please verify that

1) The <id> tag's value in the app-xml is same as the App ID in the mobile provisioning used to package the application i.e for XXXXXXX.com.abc.abc the <id> in the app-xml should be "com.abc.abc"

2) The application is uploaded using the Apple Developer account with the same Team ID as in the provisioning.

Thanks,

PRANAV CHATURVEDI

Adobe AIR Team

Report · Feb 21, 2019

Hi Pranav,

1) Yes (I did mask my applicationId and TeamId for this privacy reasons )

2) Yes

Both errors are occurring because I strongly believe dynamic frameworks should have no entitlements applied. It makes no sense to do so. Xcode doesn't add entitlements to dynamic frameworks only the main ipa binary when building an archive for the App Store.

To reiterate my patched version of adt.jar is working for me and several others who had the original error with different dynamic frameworks.

The patched version outputs this and this passes Application Loader verification.

codesign -d --entitlements :- /path/to/unzippedipa/Payload/Example.app/Frameworks/FreSwift.framework

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<dict/>

</plist>

codesign -d --entitlements :- /path/to/unzippedipa/Payload/Example.app/Example

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<dict>

<key>application-identifier</key>

<string>XXXXXX.com.abc.xyz</string>

<key>get-task-allow</key>

<key>beta-reports-active</key>

<true/>

<key>com.apple.developer.associated-domains</key>

<array>

<string>applinks:abc.app.goo.gl</string>

</array>

<key>keychain-access-groups</key>

<array>

<string>XXXXXX.*</string>

</array>

<key>com.apple.developer.team-identifier</key>

<string>XXXXXX</string>

<key>aps-environment</key>

<string>production</string>

</dict>

</plist>

Report · Feb 24, 2019

Hi,

This is the Link for new adt.jar: https://adobe.ly/2IxOiw6

Kindly share the feedback if this one solves the problem.

Thanks and Regards,

PRANAV CHATURVEDI

Adobe AIR Team

Report · Feb 26, 2019

Hi Pranav,

This latest adt.jar works as expected and passes application loader's store validation.

Thanks !

Report · Mar 16, 2019

I see this fixed in 32.0.0.109