I have a dext target in a project which fails to install on my iPad because "the code signature version is no longer supported". Indeed, when I look at the built dext (before or after is has been copied into the hosting app's System Extensions folder), codesign -dv tells me that it has CodeDirectory = 20200. The hosting app has CodeDirectory = 20400.
Curiously, in the same workspace, I have another iOS app which hosts another version of the driver (using the same source code files). The other app is a minimal test app. It is signed with CodeDirectory = 20500 and the driver has CodeDirectory = 20400 inside this minimal app.
In both the more complex target and the simple target, the codesign invocation has the same options. Only the provisioning profile and the name of the dext differs between the working and non-working version. Here are the options, on multiple lines to make them easier to read
/usr/bin/codesign
--force
--sign D0...A0F (same for both)
-o runtime
--entitlements <path to driver>.dext.xcent
--timestamp\=none
--generate-entitlement-der
<path to driver.dext>
I've searched high and low for a solution to this problem, but found none. It has come up before, in particular here https://developer.apple.com/forums/thread/683214?answerId=679712022#679712022
I'm using Xcode 15 on macOS Sonoma 14.0. I've thrown away the Derived Data for the project, I've thrown away the ModuleCache.index and the SymbolCache.index I've restarted my Mac. I've restarted the iPad.
There's no legacy code here. This is all new, newly built and signed by a new version of Xcode. But I don't seem to have any control over what version of signature Xcode chooses to use - what influences that? Obviously there's some difference, perhaps in the hosting app or target, between the environment where everything works and where nothing works.
If it helps, the more complex app was already built, signed and deployed to the App Store without a driver. The driver is under development, and it is a new addition to the target, so the existing Identifier, Certificate and Profile for the app pre-date the addition of the embedded driver target.
Any ideas. Anyone?
My specific problem here was that there was no code to sign. I was messing about with two near-identical projects trying to fix a link error, and removed all the code from my dext, then forgot I had done so.
This is what DTS said:
This system extension has no main executable. For some reason it’s gone completely missing, making it a codeless bundle. So, the code signature gets stashed away in extra files in the _CodeSignature directory, and that has no place to store DER entitlements.