After updating the os, not able to install the enterprise app through ipa, it throws error unable to install the app.
Also not able to launch the enterprise app which was present in the device before updating the OS iOS 15 beta, it throws error, the developer of this app needs to update it to work with this version of iOS
Kindly update on this. Any app side changes has to be done for this to fix these issues ?
We ran into the same error with a couple of our enterprise apps that were released last September/October, but not with any released this year since March. I watched the console when intune was trying to install the app and saw this error:
Failed to verify code signature of Prices.app : 0xe8008029 (The code signature version is no longer supported.)
We renewed the app's provisioning profile, resigned the IPAs, and the app launches now.
Hope that helps.
When testing iOS 15 beta we found that this occurred when code signing on a macOS Catalina system. Code signing on a macOS Big Sur system resolved this issue.
I haven't seen any official documentation on what has caused this and what the requirements are, but I would love to know more.
Good luck!
This is most probably the issue discussed in Using the Latest Code Signature Format.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
We're also affected by this, but the "Using the Latest Code Signature Format" article only mentions needing to code-sign with 10.14 or later.
We build and codesign on 10.15, but when I do look at the output of codesign -dv, I do indeed see the version of 20400.
Is it possible this article needs to be updated? I'm confused why the version would be still 20400 on Catalina while the article suggests that signing on 10.14 or later should produce a v20500 CodeSignature format.
Also since I evidently read the article a bit too fast: it says "For any value of v less than 20400, you’ll need to re-signed [sic] your app."
Signing on Big Sur (Xcode 12.1, still) seems for me to generate v20400.
Hey @timothy-sutton, The Apple documentation on this subject is incorrect I believe (but could be wrong).
If you are code signing from the command line you will need to include the below as an option where [options] and [more options] should be replaced with the options you would use.
codesign [options] --options runtime [more options]
Once you include this you will see the Code Directory updated to the latest one available for your Xcode version.
I have had a Feedback open for Apple to correct the Documentation at the below URL for some time now but it hasn't been addressed.
https://developer.apple.com/documentation/xcode/using-the-latest-code-signature-format
Hopefully this helps!
It still doesn't work for me :(
I used the --options runtime flag in Xcode 12.2 on macOS Catalina and I can't install the app on an iOS 15 device.
If I do the resign on a mac with BigSur and Xcode 13, it works.
With the flag. Before resign:
❯ codesign -dv /Users/ndr/Downloads/Payload/MyApp.app
Executable=/Users/ndr/Downloads/Payload/MyApp.app/MyApp
Identifier=com.test.rd
Format=app bundle with Mach-O thin (arm64)
CodeDirectory v=20500 size=19389 flags=0x10000(runtime) hashes=597+5 location=embedded
Signature size=4736
Signed Time=7 Jul 2021 at 10:32:12
Info.plist entries=37
TeamIdentifier=XXXXXXXXXX
Runtime Version=14.2.0
Sealed Resources version=2 rules=10 files=112
Internal requirements count=1 size=192
After resign:
❯ codesign -dv /Users/ndr/Downloads/Payload/MyApp.app
Executable=/Users/ndr/Downloads/Payload/MyApp.app/MyApp
Identifier=com.test.rd
Format=app bundle with Mach-O thin (arm64)
CodeDirectory v=20500 size=19453 flags=0x10000(runtime) hashes=597+7 location=embedded
Signature size=4736
Signed Time=7 Jul 2021 at 10:42:56
Info.plist entries=37
TeamIdentifier=XXXXXXXXXX
Runtime Version=14.2.0
Sealed Resources version=2 rules=10 files=112
Internal requirements count=1 size=192
We had something similar happen with an Enterprise App. I'm not sure which one of the following steps or a combination of these steps resolved the issue, but it's now installing on iOS 15 beta.
As noted on this thread already, you can resolve the error for The code signature version is no longer supported, by re-signing your app. To check if you need to re-sign your app, use the codesign utility to take a look at the version contained on your app's CodeDirectory. Note that this will be output with something like:
$ codesign -dvvvvv MyApp.app
Executable=/path/to/myapp/MyApp.app/Contents/MacOS/MyApp
Identifier=com.example.mycompany-samplecode.myapp
Format=app bundle with Mach-O universal (x86_64 arm64)
CodeDirectory v=20500 size=949 flags=0x10000(runtime) hashes=20+5 location=embedded
And if you see a version with v=20500 on it then you should be good here. If you see a version less that 20400 here then you'll need to re-sign your app.
Another case could be that you previously re-signed your app and the CodeDirectory is 20400 or higher, but the app does not install on iOS properly. If this is the case then you may need to re-sign your app including the DER entitlements. To check if you need to re-sign using the DER entitlements, run the following command to take a look at the hash values in the signature'sPage size:
codesign -dvvvvv MyApp.app
...
Page size=4096
-7=4ade7be00e0a7b6db853edc4843e7ece1eea646f6f13d1809f78fc50d8db461f
-6=0000000000000000000000000000000000000000000000000000000000000000
-5=1dfa58bd8ac3c4fb42142c1c4d28c436128b3a7460186a44526194fb690112bc
-4=0000000000000000000000000000000000000000000000000000000000000000
-3=ef08dbe5a7c355336e1fb571604b683ce1c54536cb59a6155a1d18387fd23f6e
-2=5b730fa46ffd405fd88da9606d82eda9af7f460f6049047afc176163326f5a7f
If -5 contains a value and -7 has a zero value, or is not present at all, then you will need to re-sign your app with DER entitlement. One way to do this is to add this into your Xcode Build Settings by setting the --generate-entitlement-der for OTHER_CODE_SIGN_FLAGS. This can also be done on the command line by using the following command:
# Re-sign your app
% codesign -s "Signing Identity Name from Keychain" -f --preserve-metadata --generate-entitlement-der MyApp.app
...
MyApp.app: replacing existing signature
# Check your signature again
% codesign -dvvvvv ActionExtensionHostSSO.app
...
Page size=4096
-7=4ade7be00e0a7b6db853edc4843e7ece1eea646f6f13d1809f78fc50d8db461f
-6=0000000000000000000000000000000000000000000000000000000000000000
-5=1dfa58bd8ac3c4fb42142c1c4d28c436128b3a7460186a44526194fb690112bc
-4=0000000000000000000000000000000000000000000000000000000000000000
-3=ef08dbe5a7c355336e1fb571604b683ce1c54536cb59a6155a1d18387fd23f6e
-2=5b730fa46ffd405fd88da9606d82eda9af7f460f6049047afc176163326f5a7f
...
Signed Time=Jul 9, 2021 at 6:40:59 AM
Try the following steps below and if there are still issues installing or re-signing apps, please let me know.
Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
Building with Xcode 12.5.1 fix it!
@ juliana17
If v=20400, it should still be able to install on device with iOS 15 beta, right?
You will want to check the Page Size as I mentioned about if you are unable to install on iOS 15 with a CodeDirectory of 20400. Also, another course of action here would be to re-sign your app on macOS Big Sure or macOS Monterey.
Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
I'm running macOS Catalina and am having this exact issue.
I've tried code signing with --generate-entitlement-der, but the -6 and -7 are still missing from the app's page size.
Thoughts?
I'm running macOS Catalina and am having this exact issue. I've tried code signing with --generate-entitlement-der, but the -6 and -7 are still missing from the app's page size. Thoughts?
Try the re-sign on macOS Big Sur or Monterey. If this is still an issue after re-signing on either of those two OS's, please open a bug report and follow up with the Feedback ID.
Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
It would still be great if this could just be documented publicly (see FB9190730).
I can confirm that this works for me when code signed with macOS Big Sur. What I am hoping is (in order):
(a) Code signing and app distribution isn't required prior to the release of iOS 15. (b) Code signing and app distribution is required, but can be done on macOS Catalina.
Or, if neither of the above are possible:
(c) Official documentation on this requirement, similar to the 'Using the Latest Code Signature Format' article that Quinn linked above.
If (a) or (b) isn't possible, then (c) would at least help support change management, etc.
I have just submitted a bug report regarding this: FB9318576
@timothy-sutton and @JLJohnson
It would still be great if this could just be documented publicly (see FB9190730).
and
(c) Official documentation on this requirement, similar to the 'Using the Latest Code Signature Format' article that Quinn linked above. I have just submitted a bug report regarding this: FB9318576
Thank you for opening bug reports here. As for the documentation, there is an effort underway to update the existing documentation, but I do not have a timeline for when that is available.
Regarding:
(a) Code signing and app distribution isn't required prior to the release of iOS 15.
Could you elaborate a bit more about what you are wanting here with (a)?
Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
For anyone having an issue with code signing their app with the --generate-entitlement-der on macOS Catalina, here is what I did today as a workaround:
(1) Built an Ad-Hoc iOS app that targeted iOS 13 on macOS Catalina. I checked the Page size on the signature and saw the missing -7 value:
$ codesign -dvvvvv MyTestApp.app
...
Page size=4096
-5=7c741a970873bb7f6a05c1ad5b9425f4b5b1ac86645b2cb8c842a57f51818eb5
-4=0000000000000000000000000000000000000000000000000000000000000000
-3=f7ddc8d932def2f393dfc1719252e61b1561afeed76d32044ae0cd793e380bc6
-2=904f563968898c7569794e19bcd9304d46ca5c0b9f09c792081bdb8ec9c04c92
(2) I tried to install this build from macOS Monterey to an iOS 15 device and received the following error message for (The code signature version is no longer supported):
default 11:41:15.649815-0700 installd 0x16be2b000 -[MIInstaller performInstallationWithError:]: Installing <MIInstallableBundle ID=com.dts.MyTestApp.app-mattsignature; Version=1, ShortVersion=1.0>
default 11:41:15.649936-0700 installd com.dts.MyTestApp-mattsignature:7:5:1:1:Start : Install (New)
default 11:41:15.720695-0700 installd 0x16be2b000 +[MICodeSigningVerifier _validateSignatureAndCopyInfoForURL:withOptions:error:]: 74: Failed to verify code signature of /var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.pEXcje/extracted/Payload/MyTestApp.app : 0xe8008029 (The code signature version is no longer supported.)
(3) From here I resigned the MyTestApp.app on macOS Catalina with the --generate-entitlement-der flag:
$ codesign -s "DTS Matt Eaton (xxxxxxxxxx)" -f --preserve-metadata --generate-entitlement-der MyTestApp.app
Warning: default usage of --preserve-metadata implies "resource-rules" (deprecated in Mac OS X >= 10.10)!
MyTestApp.app: replacing existing signature
(4) From here I checked the Page size on the resigned app and saw that -7 is now available.
$ codesign -dvvvvv MyTestApp.app
Executable=/path/to/MyTestApp.app/MyTestApp
Identifier=com.dts.MyTestApp-mattsignature
...
Page size=4096
-7=915c86eb5653ea2122901068e9735fd3c98d7622ab9aefe478e3c358a9a8ffeb
-6=0000000000000000000000000000000000000000000000000000000000000000
-5=7c741a970873bb7f6a05c1ad5b9425f4b5b1ac86645b2cb8c842a57f51818eb5
-4=0000000000000000000000000000000000000000000000000000000000000000
-3=6f00b3831b7c1a3ba39fbfe9fc3a4f2267816bbd2c8d77e1aac17fb1726cf9f3
-2=904f563968898c7569794e19bcd9304d46ca5c0b9f09c792081bdb8ec9c04c92
CDHash=2a38a2b310e7a46c8e88a6f82f50fa31138fd894
(5) From here, I needed to zip up my Payload/MyTestApp.app directory again and then rename it with an ipa extension. (6) After that I was able to install and run MyTestApp.app properly on an iOS 15 device from macOS Monterey.
Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
I'm still having the same issue even after following all the solutions listed in this thread. After more investigations, I found out that provisioning profile that has <key>DER-Encoded-Profile</key> fails to install on iOS 15 beta.
XCode beta seems to auto-generate the provisioning profile without this key. However, downloading the provisioning profile from Apple's developer portal has this key and does not let me side load the app.
I haven't come across the DER entitlement before. What is about?
I do not have an official answer here, but DER is short fro Distinguished Encoding Rules and is a standard by which ASN.1 structures are transferred. ASN.1 is a standard by which data can be encoded and decoded no matter which platform is being used. ASN.1 in this specific case applies to data encoding rules for cryptographic signatures, and I am assuming for code signing applies to how the entitlements are encoded.
Regarding:
Can we expect this issue to be fixed in the final release of iOS15?
What item are you referring to here that needs to be fixed?
Regarding:
Or do we have to resign all apps and add the entitlement to make the apps work with iOS15?
If you are signing on macOS Big Sur or macOS Monterey then you should be able to sign your apps and install them on an iOS 15 device. At least I have not had an issue doing so, please let me know if you see an issue here.
As for macOS Mojave and Catalina, you will at the moment need to re-sign your iOS app to use the new --generate-entitlement-der argument as I have demonstrated above. I did attempt to test this in Xcode but was not able to make this work. I do have a bug open for this (r. 80574083)
Regarding:
If you have a iOS14 device with some apps already installed with the correct signature version but without the entitlement, will they still work after the update to iOS15?
See my above comment about signing on macOS Big Sur or macOS Monterey.
I'm still having the same issue even after following all the solutions listed in this thread. After more investigations, I found out that provisioning profile that has DER-Encoded-Profile fails to install on iOS 15 beta. XCode beta seems to auto-generate the provisioning profile without this key. However, downloading the provisioning profile from Apple's developer portal has this key and does not let me side load the app.
If you create an Ad-Hoc signed app from macOS Big Sur or macOS Monterey then are you able to side-load onto an iOS 15 device?
If you are attempting to re-sign on Catalina can you walk me through the steps you took here?
Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
I've made a bit of progress implementing the workaround of setting --generate-entitlement-der during our archive builds on Catalina.
When we perform an archive we also pass -archivePath <path to .xcarchive> and then do an -exportArchive in a subsequent step, and from there we archive the resultant enterprise-signed IPAs for use in development and QA.
I set OTHER_CODE_SIGN_FLAGS=--generate-entitlement-der in both the xcodebuild archive invocation and then the subsequent -exportArchive. The resultant xcarchive produces a .app within Products that does contain 6 and 7. However, the .ipa from the -exportArchive step does not, so I can't install the exported IPA as-is.
I am able to manually create an IPA wrapper for the built product originating from the .xcarchive by copying this .app into a new Payload directory and zip-ing it into a file with a .ipa extension. Installing this manually-cobbled IPA onto an iOS 15 device seems to work fine.
I see from looking at IDEDistributionPipeline.log from the -exportArchive step that there is still a lot of logic to the -exportArchive step. I see when it gets to Processing step: IDEDistributionCodesignStep:
it eventually gets to:
2021-07-20 16:23:18 +0000 [MT] Running /usr/bin/codesign '-vvv' '--force' '--sign' '<scrubbed>' '--entitlements' '/var/folders/6f/tcr7g_ms167blz6vbzctyrth0000gn/T/XcodeDistPipeline.~~~ubOEou/entitlements~~~QfGC1G' '--preserve-metadata=identifier,flags,runtime' '/var/folders/6f/tcr7g_ms167blz6vbzctyrth0000gn/T/XcodeDistPipeline.~~~ubOEou/Root/Payload/<scrubbed>.app'
..so I can see it has re-signed the top-level .app bundle without the additional flags we had specified from the original archive build.
Is there some other way we can tell the archive export stage about the --generate-entitlement-der flag? For example, defining it in the export options?
Given there is so much additional logic I see in the IDEDistributionPipeline.log steps I'm hesitant to try and do our own IPA repackaging by simply copying the .app out of the xcarchive and into an IPA zipfile, given that all of this is stopgap work for us until we upgrade to Big Sur. We're still blocked on upgrading all of our release build machines to Big Sur due to FB9363703 and FB9006786.
@timothy-sutton
Thank you for the update here.
Regarding:
However, the .ipa from the -exportArchive step does not, so I can't install the exported IPA as-is.
I opened a bug (r. 80574083) for a similar workflow using --generate-entitlement-der directly in Xcode with the OTHER_CODE_SIGN_FLAGS set in the build setting.
Regarding:
Is there some other way we can tell the archive export stage about the --generate-entitlement-der flag? For example, defining it in the export options?
The only other way that I can see to workaround this at the moment would be to complete the export and then open the IPA and perform the re-sign on the .app after the export. So, it would almost be like a 3rd step in your build process, i.e., archive, export, resign.
Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
for example I'm not sure whether this process is any different if the .app contains app extension but now I see from CI logs that our "real" apps need our usual (42-ish) number of codesign invocations
Yeah, my re-sign example in this thread is very basic because I am signing a flat iOS app without any framework dependencies or app extensions. During the re-sign process these extensions and dependencies would also have to be taken into account. Lastly, make sure there are not any static frameworks embedded in the application as these cannot take on the new code signature format.
Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
Hello, did you get it fixed? I have the same problem and none of the solutions here or other places help. The project refuses to install on physical device but works in on simulators. This started happening yesterday after updating to Big Sur to 11.5.1. My device was using iOS14.5 for some times and there were no problem installing. I'm not sure if updating the OS automatically update Xcode since I don't remember what version I was using, but the problem occurs instantly after the OS update and mac restarts. Any advice from anyone is appreciated.
Some info:
What I tried:
Since this is an iOS 14.7 installation issue I suspect you may be seeing a slightly different problem. Can you confirm a few things for me:
Create a distribution Ad-Hoc build of your app and try to install it on your device. What is the installation failure message you see in the Console.app for the device? Is it the same message being recorded on this thread, i.e., "The code signature version is no longer supported.?"
If it is this same message then you may want to also checkout the signature on those embedded frameworks, and each extension in your app bundle. You can check these executables with the same procedure I described above, using this command:
$ codesign -dvvvvv MyTestApp.app/Contents/path/to/framework/executable
$ codesign -dvvvvv MyTestApp.app/Contents/path/to/extension/executable
However, this time make sure you are looking at the paths to each executable embedded in your bundle. For example, any framework or extension executables. If you see any of these executables with an old signature format then you will have to re-sign them also.
If this is not the same message then I suspect you have something else going on here and you can do one of two things; you could create a new post describing your problem on the Code-Signing tag, or you could open a TSI and one of my colleagues will take a deeper look at this situation.
Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
Hello Matt, thank you for your quick reply and detailed instruction.
No problem at all.
Regarding:
I followed it and found out which framework was causing the problem. Now the app can be installed normally.
Yep, this has been known to be a common issue for anyone running into re-signing or old code signature format issues. For anyone reading this, please make sure to check all of the executables inside your main app bundle to see if they also need to be re-signed as this may be causing problems as well.
Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com