Code Signing Issue: A sealed resource is missing or invalid about xamarin.swift

[bwalpoleuk]

Sorry yes the error is when we upload to the store:

ERROR ITMS-90035: Invalid Signature. A sealed resource is missing or invalid.

But it doesn't give any detail as to why the signature is invalid so what I shared was the output from codesign -vvvvvvv <Path to .app> to identify which resource(s) the message was referring to and it seems to be the Swift .dylib files that it isn't happy with.

[Flash3001]

Hey @bwalpoleuk when are you getting this error? I assumed it was from App Store when upload, but the path says /Users/Me/Downloads/Payload/MyApp.Touch.app/.

[tentom]

@bwalpoleuk
I think I had this error once or a twice but I am not 100% sure. Replying with what I remember have given me trouble uploading to AppStore. I could try to replicate it buy i'm not at the build mac ATM , I will try it tomorrow as i'm going to upload a version of my app anyway.

I think had a similar error message when I forgot to remove the SwiftFrameworksSimulator folder or I signed the archive before removing said folder but I can not remember 100%

[bwalpoleuk]

@Flash3001 Great thanks, at least I'm not the only one to see the issue. I can't see the SwiftFrameworksSimulator in the .app, would any potential signing issue be caused by the order of the targets in the .csproj or something like that?

[Flash3001]

@bwalpoleuk there was an issue related to the order of execution on the .csproj that was causing the SwiftFrameworksSimualdor folder not to be removed. It was related to using PackageReference. You can see more about that here Flash3001/iOSCharts.Xamarin#47 (comment). The script was updated to fix this issue, but I don't think this is what is causing your upload errors.

So if you are using https://www.nuget.org/packages/Xamarin.Swift4/ version 4.0.0.1 and its targets run before the basic Xamarin.iOS targets a lot can get wrong (reason on the comment I mentioned before). On version 4.0.0.2 the order shouldn't matter anymore, but there is a report on #25 about it not working as expect (didn't identify the issue yet).

That kind of issue you see when checking with the codesign happens because your APP was modified after it was signed.

Please check the following:

• What is the Xamarin.Swift4 (or 3) version you are using? 4.0.0.1 or 4.0.0.2?
• Run the codesign using codesign -dv PATH. It will return the TeamIdentifier, this way we can know if it was signed. Here is an example of one of mine:

Identifier=com.apple.dt.runtime.swiftCoreAudio
Format=Mach-O universal (armv7 armv7s arm64)
CodeDirectory v=20400 size=1863 flags=0x0(none) hashes=52+2 location=embedded
Signature size=4860
Signed Time=20 Mar 2019 23:40:23
Info.plist entries=5
TeamIdentifier=MY_TEAM
Sealed Resources=none
Internal requirements count=1 size=232

Let's try a few the following to see if we can get more clues on what is going on:

• Build your app using the Archive for Publishing from VS4M then press Sign and Distribute -> App Store. Check the codesign for this build.

One thing from your error logs that caught my attention is that on the first line it says Payload/MyApp.Touch.app/: a sealed resource is missing or invalid file modified

I had several issues with invalid codesigns during the initial development for this project, if I am not mistaken it was happening because I had all the device dylibs in a separated folder. They were signed in there and then moved to the final destination. It was some time ago so I might have confused myself haha.

[bwalpoleuk]

@Flash3001 We are using 4.0.0.2 of the Swift 4 libraries.

If I build and archive locally via VS4M then the code signing appears to be valid, below is the output from codesign -dv PATH for the two builds.

Valid code signature:

Identifier=co.uk.myapp
Format=app bundle with Mach-O universal (armv7 arm64)
CodeDirectory v=20400 size=233664 flags=0x0(none) hashes=7293+5 location=embedded
Signature size=4792
Signed Time=21 Mar 2019 at 08:28:35
Info.plist entries=37
TeamIdentifier=MY_TEAM
Sealed Resources version=2 rules=13 files=491
Internal requirements count=1 size=188

Invalid code signature:

Identifier=co.uk.myapp
Format=app bundle with Mach-O universal (armv7 arm64)
CodeDirectory v=20400 size=233504 flags=0x0(none) hashes=7288+5 location=embedded
Signature size=4792
Signed Time=18 Mar 2019 at 08:12:31
Info.plist entries=37
TeamIdentifier=MY_TEAM
Sealed Resources version=2 rules=13 files=493
Internal requirements count=1 size=188

On the face of it the only difference I can see is that the invalid build contains two more files, this seems to be the iTunesArtwork and iTunesArtworkx2 files.

But what this does seem to show is that the issue is only happening when the app is built on AzureDevOps, we are using the standard Xamarin.iOS task to do this: https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/build/xamarin-ios?view=azure-devops.

We do copy the .ipa to a new location after the build so it can be published as an artefact.

[bwalpoleuk]

@Flash3001 I've created a new AzureDevOps pipeline to try and investigate the issue, even if I limit this pipeline to just build the app using the standard iOS task as referenced above the code signature is invalid.

So the problem seems to be related to how AzureDevOps is doing the build, this task does build at the solution level I don't know if thats a problem?

[bwalpoleuk]

@Flash3001 After a bit more investigation I've found that adding the Xamarin.Swift4 4.0.0.2 package is fine but adding any other package even Xamarin.Swift4.Core 4.2.1.1 causes the issue.

[Flash3001]

@bwalpoleuk this is quite interesting. I have no experience at all with AzureDevOps, but is it possible to define your Xcode version?

If you add Xamarin.Swift4.Core 4.2.1.1 or any other 4.2.1.1 package it breaks or version 4.2.1 and 4.2.0 also breaks it?

Package 4.2.1.1 was uploaded to work with Xcode 10.1 10B61. 4.2.1 is the same, but at some point Apple was (not sure if it still is) blocking the upload for apps including arm64e architecture so I had to remove it from the Swift dylibs. That is the only difference between 4.2.1.1 and 4.2.1 . If 4.2.1 is working for you try to keep it.

Can you send me a build log from a clean Release|iPhone build from AzureDevOps (using Diagnostics verbosity)? If you don't want to put in here please send it to my e-mail. I want to check if any build step is doing any change to those files that are not expected.

[bwalpoleuk]

@Flash3001 You can set the Xcode version thats used in the build and we have this set to 10.1.

I've tried using 4.2.1 and 4.2.0 but I get the same result, I'll send you a build log via email.

[Flash3001]

@bwalpoleuk I've checked the log you've sent me and the first thing I noticed is that the only Swift runtime it is processing is libswiftCore.dylib. If you check it you wont find any references to others like libswiftUIKit.dylib or libswiftFoundation.dylib. Can you open the generated APP file and see if they are included? That is a bit different from the codesign -vvvv check you first sent as it indicated that those files were included.

[bwalpoleuk]

@Flash3001 Sorry this is a reduced build where I only pull in the core NuGet package to try and isolate the issue, I still get the same code signing problem though.

[tompi]

@bwalpoleuk I was banging my head against this issue yesterday, and I have no explanation why, but downgrading Xamarin.Swift from 4.0.0.2 to 4.0.0.1 solved it. Perhaps worth a try if this is still a problem.