Failed Submission Checks with Error ITMS-91065: Missing Signature

[lancefu-eventbase]

Description

What We Use Firebase For

• Analytics

How We Use Firebase

At my company, we have an analytics framework (dynamic), which defines protocols and wrappers to allow integration of more than one analytics service. This is where our implementation of Fireworks lives. We recently updated our framework to target 10.25.0 for Firebase.

One thing to note here is that our CI/CD pipeline uses older version of Xcode, 15.0.1, as opposed to Xcode 15.2 like the release notes says this version requires. We saw the requirement at the time, but after testing it internally, everything seemed to be in order. Therefore, we proceeded with 10.25.0 still.

Failed Submission Checks

Yesterday, when we submitted one of our apps for review for the purpose of distributing TestFlight builds on App Store Connect, we got the error: ITMS-91065: Missing signature.

At this point, we realized our integration of Firebase is likely incorrect. After some research, I realized we're supposed to embed and sign static xcframeworks. I made the appropriate changes in addition to add PrivacyInfo.xcprivacy in our own framework, and exported the xcframework and made a test build.

After uploading using Transporter, I got this error:

Asset validation failed (90085)
No architectures in the binary. Lipo failed to detect any architectures in the bundle executable. (ID: ecb746c1-c4aa-4750-94a6-3598cbe7a0ce)

After some research, the issue seems to be the Info.plist in the embedded frameworks from Firebase now. Using FirebaseCore.framework as example, its Info.plist specifies that CFBundleExecutable is FirebaseCore. Yet the executable is nowhere to be found within FirebaseCore.framework because it's a static library.

Questions

It's very likely that the issue lies in our project configuration and setup instead of anything on the Firebase side. However, I'd like some assistance confirming it.

Is using lower version of Xcode (15.0.1 instead of 15.2) a factor here?

According to the integration instructions included in Firebase.zip and Apple's own instructions, we're supposed to choose the Embed & Sign option for static frameworks since Xcode 15. However, the change is giving me the above Asset validation failed (90085): No architectures in the binary issue. Do these steps change if we're using Firebase in our library project instead of app project?

Expected Outcome

App integrated with Firebase can go through Apple review without issue.

Reproducing the issue

1. Create a dynamic framework project in Xcode
2. Follow integration steps in Firebase.zip in the releases
3. Build and export xcframework
4. Create an app project in Xcode
5. Include the xcframework from step 3
6. Build and export the IPA
7. Upload via Transporter
8. Observe error: Asset validation failed (90085) No architectures in the binary

Firebase SDK Version

10.25.0

Xcode Version

15.0.1

Installation Method

Carthage

Firebase Product(s)

Analytics

Targeted Platforms

iOS

Relevant Log Output

If using Swift Package Manager, the project's Package.resolved

Expand Package.resolved snippet

```json Replace this line with the contents of your Package.resolved. ```

If using CocoaPods, the project's Podfile.lock

Expand Podfile.lock snippet

```yml Replace this line with the contents of your Podfile.lock! ```

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[paulb777]

See the code signature file in the file hierarchy. With the new code signing requirements, the FirebaseCore xcframework must be linked as is:

[paulb777]

There may also be issues using an Xcode version before Xcode 15.2, since Apple's linker do not guarantee support of linking objects from future versions.

[lancefu-eventbase]

@paulb777 Thanks for the quick reply. I am going to try to compile and export the xcframework manually with newer Xcode to see if that does the trick.

[lancefu-eventbase]

To give an update, unfortunately, using Xcode 15.2+ didn't fix the issue. I still got the same error when uploading via Transporter, which complained about no architecture in the binary that doesn't exist.

Failing that, I tried to switch to Swift Package Manager from Carthage to rule out Carthage being the problem. At the end, I ran into more issues with our CI/CD, which I didn't see when building locally. I took the xcframework that I built locally and put it into the app project and got errors about Firebase framework not found.

At this point, I think the issue is one of the following:

• There's unknown issue with our project setup that removes the binary itself along with the codesign folder.
• Including a static framework within a dynamic framework while the former needs to be signed simply isn't supported by Apple.

I then pivoted and started removing our Firebase integration and implementation in the library, and moved it to the app project itself. No issues were observed when uploading through Transporter. The build was processed, then I submitted it for review to distribute to external group on TestFlight. I will report back after it's reviewed.

Here's the file structure of Frameworks inside the IPA:

It looks more in line with what we're expecting.

[zhaojb9]

@lancefu-eventbase Have any progress？

[zhaojb9]

I also encountered almost the same problem here. Firebase has been repackaged. We are currently signing the SDK after the repackage (Firebase is still statically packaged in it) and submitting it for review again. What progress will be made in the future? Will share it.

[lancefu-eventbase]

@lancefu-eventbase Have any progress？

@zhaojb9 After removing Firebase from our library and moving it to the app itself, everything looks fine. Apple has reviewed the app for test build distribution and we're able to use it to verify things are in order as well on the Firebase integration side. Ideally, we'd prefer leaving the integration code in our library. However, we're rushing to get it "fixed" so that app submissions won't be blocked. I will circle back if I learn more.

I also posted on Apple Forum, but it didn't get any traction unfortunately. See https://forums.developer.apple.com/forums/thread/751766.

[paulb777]

Thanks for sharing @lancefu-eventbase! I'll close for now and we can reopen with new information.

[zhaojb9]

@lancefu-eventbase Sorry, I also want to confirm some information. Have you tried including Firebase in your own library, then signing your own library, and then submitting it for review. After my investigation, I found that the Signatures folder in the archive directory after the app is packaged contains the signature information files of all frameworks. These files should be uploaded to the appstore for review and confirmation by reviewers. After we manually signed our library, this folder contains the signature information, but I am not sure whether the firebase inside the library will also pass the review because of the signature of our library. I think Apple’s intention is to make the SDK signature tamper-proof, so the SDK signature after secondary packaging should also meet Apple’s requirements. I think Apple will not record the SDK signature, but only check whether it is valid.

[zhaojb9]

After my continued investigation, I will share the following information with you Whether a signature is required varies depending on how the SDK is introduced.

• If the SDK is imported from source code, no signature is required, because you have to bear the responsibility of trusting the source code yourself (such as pod introduction)
• If you download the Xcode project file of this SDK and compile it yourself, and then introduce it through xcframework (officially said binary), this xcframework needs to be signed. The signatures mentioned here can be signed by yourself. Because the open source is the source code, and the signature should be done by the person who generated xcframework. If you don't want to sign, you can introduce it through pod (source code).

I hope to be helpful.

[lancefu-eventbase]

@lancefu-eventbase Sorry, I also want to confirm some information. Have you tried including Firebase in your own library, then signing your own library, and then submitting it for review. After my investigation, I found that the Signatures folder in the archive directory after the app is packaged contains the signature information files of all frameworks. These files should be uploaded to the appstore for review and confirmation by reviewers. After we manually signed our library, this folder contains the signature information, but I am not sure whether the firebase inside the library will also pass the review because of the signature of our library. I think Apple’s intention is to make the SDK signature tamper-proof, so the SDK signature after secondary packaging should also meet Apple’s requirements. I think Apple will not record the SDK signature, but only check whether it is valid.

Yes, I have tried.

If I embed the Firebase xcframeworks in our library, then the IPA file will have modified contents within those xcframeworks and the actual executable and code signature folder removed. The xcframeworks all get signed by our distribution certificate, but not Google's. Uploading this IPA via Transporter will result in an error as mentioned previously:

Asset validation failed (90085)
No architectures in the binary. Lipo failed to detect any architectures in the bundle executable. (ID: ecb746c1-c4aa-4750-94a6-3598cbe7a0ce)

If you get a different result, I'd love to hear what your setup is like. We are using a rather old Xcode version at 15.0.1. I don't know if Carthage or Fastlane does something funny to cause this either.

[zhaojb9]

@lancefu-eventbase After I signed it myself, no errors occurred when I uploaded it through xcode. Let me briefly share my operation process.

• Use Xcode15.1 to sign our internally packaged SDK, using the company's developer plan, and the signing process uses a python script written by GPT instead of xcode
• The signed xcframework will be displayed as verified in xcode, and the unsigned framework will be displayed as unsigned.
• The signing process is carried out before the app is archived, because I found that the signature information is not saved in the .app folder, but in an external archive folder, and will be uploaded to the apple server when xcode is uploaded.

I have never used Transporter and I don’t know if the problem you are talking about is a compatibility issue that causes the upload to fail. I always upload directly through Xcode.

[zhaojb9]

@lancefu-eventbase Latest results. Apple has successfully passed the review. So I need to summarize.

• The SDK developer of the binary distribution cannot confirm the source code, so the packager needs to sign it to confirm whether the SDK has been tampered with.
• Since Firebase pod is a source code reference, when performing secondary distribution of the SDK, the person who ultimately distributes the SDK needs to sign his or her own SDK.