Framework signature won't upgrade past v=20200

I have some third party frameworks that are signed with a v=20200 signature.

When I add them to my project and set them to Embed and Sign, the app won't install on my device giving the error The code signature version is no longer supported.

I have tried resigning them using codesign -s "Apple Development: XXXX XXXX (BLXXXXXX)" -f --preserve-metadata --generate-entitlement-der XXXSDK.xcframework but the signature always reports v=20200.

I tried removing the code sign and letting Xcode do it's thing, but get the same result. Is this a problem with the way the .xcframework was built? Can I fix this without getting it rebuilt?

Replies

Framework signature won't upgrade past v=20200

What version of macOS are you running?

Share and Enjoy

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

  • 12.3.1 on both an i7 and an M1

Add a Comment

12.3.1

OK.

I’m not sure what’s going on here but, on re-reading your original post, I noticed that you’re signing the .xcframework itself. Is that right?

If so, that won’t work. An .xcframework is meant to bundle up a bunch of framework variants, and it’s those frameworks that are signable. Try signing the .framework within the .xcframework.

Share and Enjoy

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

Still the same. See attached image of me resigning. The signature changes, but not the version.

When you sign bundled code, sign the bundle not the specific library. In your example, sign MTGSDK.framework, not MTGSDK.framework/MTGSDK. In this case it doesn’t matter but in some cases its does.

[Oh, and please post terminal transcripts as code blocks, using the triple backquote delimiter, or by click the Code Block button. That way I can copy’n’paste snippets rather than having to retype them.]

Looking at your codesign output, there’s something weird going on with this framework. Note that the Format field is bundle with generic where I’d expect this:

% codesign -d -vvv FFF.framework 
…
Format=bundle with Mach-O thin (arm64)
…

Hmmm, perhaps bitcode is in play here. What does this print:

% file MTGSDK.framework/MTGSDK

Share and Enjoy

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

darrenjones@macbook-pro ios-arm64_armv7 % file MTGSDK.framework/MTGSDK
MTGSDK.framework/MTGSDK: Mach-O universal binary with 2 architectures: [arm64:current ar archivecurrent ar archive] [arm_v7]
MTGSDK.framework/MTGSDK (for architecture arm64):	current ar archive
MTGSDK.framework/MTGSDK (for architecture armv7):	current ar archive

The frameworks are a third party Ad framework: here

Ah.

This indicates that the MTGSDK file is a universal static library. Someone has taken that and put in a .framework wrapper. I see folks do this all the time, calling it a static framework, but that’s just nonsense. Static libraries and frameworks are different things. If you try to pretend that a static library is a framework you’ll run into all sorts of weird issues, just like this one.

IMPORTANT Apple does not support this as a build product, and that includes both generating and using it.

Note While the XCFramework format does support static libraries, each element must be a static library. The advent of XCFramework doesn’t improve the story for these so-called static frameworks.

My advice here is that you escalate this to the SDK vendor requesting that they ship build products in a format that Apple supports. If they can’t do that, they have to assume the burden of integrating their build products into your app.

Share and Enjoy

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

  • Thank you very much for the update. I'll certainly report that back to them.

Add a Comment