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 ?
I'm still facing issue on watch app eventhough i'm on bigsur
after re-signing also it still shows CodeDirectory v=20400 so in which case this will change to 20500 ?
Also even i'm on bigsur so if i try to export archive and install it still fails so when i looked into pagesize flag -7 is missing, is it the expected issue even on bigsur after exporting archive?
ps: After export iOSApp.app seems to be contained 7, but extension like watchApp missing 7 but before export it seems to be fine any idea?
@kumar.pavan
Also even i'm on bigsur so if i try to export archive and install it still fails so when i looked into pagesize flag -7 is missing, is it the expected issue even on bigsur after exporting archive? ps: After export iOSApp.app seems to be contained 7, but extension like watchApp missing 7 but before export it seems to be fine any idea?
Thanks for reporting. I am assuming it is, but make sure that your embedded watchOS app is also signed during the iOS export process in Big Sur. After the export, check the hash slot entitlement for -7 on the watchOS executable and if it's missing you will need to re-sign everything. The same goes for other extension executables in your app bundle.
NOTE, do not try to just resign the watchOS embedded executable only. This could invalidate the outer signature on your iOS app. If you need to, re-sign the embedded executable for the watchOS app and then re-sign the outer iOS app to make sure the signatures are all valid.
Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
Thanks for reporting. I am assuming it is, but make sure that your embedded watchOS app is also signed during the iOS export process in Big Sur.
Yes during export process it's resigning watchapp but still it's missing -7 and -6 flags on bigsur i believe this must be Xcode issue will it resolve before final release of iOS15?
Just curios to know is there way to specify --generate-entitlement-der during exportArchive command else resigning app and extensions is like tedious process since we have many nested extensions internally?
@kumar.pavan
Yes during export process it's resigning watchapp but still it's missing -7 and -6 flags on bigsur i believe this must be Xcode issue will it resolve before final release of iOS15?
Not sure, but you are signing with the latest version of Xcode on Big Sur, and you can confirm that the DER hash slot is not available then you should open a bug report. You will need to re-sign in this case to workaround this.
Regarding:
Just curios to know is there way to specify --generate-entitlement-der during exportArchive command else resigning app and extensions is like tedious process since we have many nested extensions internally?
There is not a way that I know of to integrate the command for --generate-entitlement-der into the xcodebuild process because xcodebuild is handling the codesign commands for you. You could try to add this argument to your build settings, but in my tests this did not work as expected. You would need to re-sign after the export.
Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
As a general point of advice for anyone that may be reviewing this thread I did want to point out an additional debugging technique if you are re-signing, your signature contains the DER hash slot for (-7), but you are still experiencing issues. Check to make sure that your Provisioning profile complies with the new Provisioning profile updates described here.
Please make sure that the new Provisioning profile that you are re-signing with contains the key for DER-Encoded-Profile. It will look something like this:
<key>DER-Encoded-Profile</key>
<data>MIIOUwYJKoZIhvcNAQcCoIIORDCCDkACAQExD....</data>
You can check this in your Provisioning profile by converting your profile to a plist and looking for this key:
$ security cms -D -i embedded.mobileprovision -o Profile_Dist_iOS.plist
$ /usr/libexec/PlistBuddy -c "Print :DER-Encoded-Profile:" Profile_Dist_iOS.plist
..... lots of data .....
If your Provisioning Profile does not contain this key then you will need to go to the Developer Portal and create a new provisioning profile and then this profile should contain this updated key.
Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
Do I need to take any action to resolve this issue?
Yes, if you are distributing an app through an Enterprise Distribution method then you need to take a look at the information on this thread to make sure you are ready for the changes to the signature requirements coming in iOS 15.
Starting in iOS 15, iPadOS 15, tvOS 15, and watchOS 8 the system requires the new, more secure, signature format that uses DER to embed entitlements into your app's signature. For more on DER, or Distinguished Encoding Rules, see DER discussed in RFC 5280 (https://datatracker.ietf.org/doc/html/rfc5280#section-4.1) for Basic Certificate Fields.
Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
Matt, can you clarify? You wrote "Starting in iOS 15, iPadOS 15, tvOS 15, and watchOS 8 the system requires the new, more secure, signature format that uses DER to embed entitlements into your app's signature." However https://help.apple.com/developer-account/#/dev2ab310a57 says "In iOS, iPadOS, and tvOS 15 or later, some entitlements without “com.apple.developer“ in the entitlement key may require the DER-encoded version to be included in the provisioning profile" -- which is not the same thing.
The official docs are too vague: some entitlements ... may require? We need a complete list of the new requirements, so someone can inspect a given Provisioning Profile to determine compatibility with iOS 15, without having to test an install. My company supports customers who sometimes have literally 100's of in-house apps, and asking them to test re-installing each one -- with only a few weeks before iOS 15 drops -- is not feasible.
Also, earlier you had mentioned official documentation was still forthcoming. Is the help.apple.com link above what we were waiting for, or is there something else we can refer our customers to? Referring them to a developer forum thread seems a bit sketchy.
@c l i f f
Matt, can you clarify? You wrote "Starting in iOS 15, iPadOS 15, tvOS 15, and watchOS 8 the system requires the new, more secure, signature format that uses DER to embed entitlements into your app's signature." However https://help.apple.com/developer-account/#/dev2ab310a57 says "In iOS, iPadOS, and tvOS 15 or later, some entitlements without “com.apple.developer“ in the entitlement key may require the DER-encoded version to be included in the provisioning profile" -- which is not the same thing.
You are correct, these are not the same thing. There are two requirements being outlined here. The first requirement that I was speaking of is regarding, "the system requires the new, more secure, signature format that uses DER to embed entitlements into your app's signature," and this is a new DER hash slot that is added to the actual signature of your app during code signing. This new DER hash slot is identified by the addition of -7 in the code signature:
$ 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
This is done when re-signing using the flag for --generate-entitlement-der:
$ 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
Now, you should not need to add this new DER hash slot to your signature on Big Sur or Monterey, these versions of macOS should do the right thing.
The link for the Provisioning profile updates means that if your app's signature has the DER hash slot that I described above, but you are still having issues installing the app on iOS 15 then there is a good chance you will need to generate a new provisioning profile to make sure it contains the key for:
<key>DER-Encoded-Profile</key>
<data>MIIOUwYJKoZIhvcNAQcCoIIORDCCDkACAQExD....</data>
Using a new profile with the DER-Encoded-Profile key and the new DER hash slot in your signature should put you in a good place.
Also, earlier you had mentioned official documentation was still forthcoming. Is the help.apple.com link above what we were waiting for, or is there something else we can refer our customers to? Referring them to a developer forum thread seems a bit sketchy.
The previous link that I post for the new Provisioning Profile updates was not the documentation updates that I had previously mentioned. There is a documentation effort still underway.
Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
Any chance these requirements could be postponed to iOS 15.1+?
Right, as mentioned, I do not have control over this. My role here is to try and explain the situation, and help out where possibly, so that Development teams can assess how this impacts their situation as they prepare for the release of iOS 15.
Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
This worked for my enterprise app: 0) downloaded latest xCode
@c l i f f
Matt, if any docs have been published yet, can you please share the link?
I am working on the documentation right now. I will share the link when I have it.
Is it because of the Enterprise Prov Profile or Mac system versions used to sign and wrap the App?. Signed with Xcode 12.2 Intune Wrapped with mac system Version of MACOSX is 10.14.6 Version of XCode installed is Xcode 11.3.1 —
It could be both of these things causing you issues. Take a look through the previous posts on this thread, but you will need to make sure that you have the DER hash slot for (-7) in your signature as well as you will need to sign your app with a provisioning profile with the key for DER-Encoded-Profile. The simplest path here would be to generate a new provisioning profile and build and sign your app from macOS Big Sur using Xcode 12.5 or later.
Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
We have same issue with azure devops MacOS Catalina agent and build with Xcode 12.4 command line. The app builded and distributed with enterprise provisioning profile not worked for iOS 15 devices. Creating new provisioning profile for enterprise distribution and set OTHER_CODE_SIGN_FLAGS=--generate-entitlement-der not enought and got same error for iOS15.
Finally, after we upgrated MacOS agent to BigSur and build with new provisioning profile, Xcode 12.4 than start working for iOS 15.
I've been following this thread, having a similar issue with our watch extension app that suddenly stopped working when our testers updated their iOS device to iOS 15 and watch to Watch OS 8.
So far I've recreated new provisioning profiles, verified that the codesign looks similar to what is suggested, seen that there's a DER-profile entry in the provisioning profile and also tried adding --generate-entitlement-der to build settings. Still, building the app for enterprise and installing it works on the iOS device but the embedded watch app does not. When you try to install it from the iOS watch.app, then it fails with "could not install the app at this time"
And the error we get is: 0x170053000 -[ACXInstallQueue _onQueue_deQueueNextOperation]_block_invoke_2: Failed to install app my.test.app (p = N, ui = Y) : Error Domain=ACXErrorDomain Code=17 "Got error 17 in install done from remote side (MI error ApplicationVerificationFailed ; Extended 0xe8008029 ; Desc Failed to verify code signature of /var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.y3l1mI/extracted/Payload/Watch.app : 0xe8008029 (The code signature version is no longer supported.))" UserInfo={SourceFileLine=646, NSLocalizedDescription=Got error 17 in install done from remote side (MI error ApplicationVerificationFailed ; Extended 0xe8008029 ; Desc Failed to verify code signature of /var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.y3l1mI/extracted/Payload/Watch.app : 0xe8008029 (The code signature version is no longer supported.)), FunctionName=-[ACXServerInstallOperation receivedDictionaryOrData:]}
Which indicates that the wrong provisioning profile is used but that doesn't seem to be the case.
Our page size: Page size=4096 -7=8d48d5d98df3b77ce25ac0b1ad03b1d4f50e23d7e377979e409b107324e18266 -6=0000000000000000000000000000000000000000000000000000000000000000 -5=4146cb67c2b6ce380836b0f27ac5760098b8a1af18608163202fd0a9d961d29d -4=0000000000000000000000000000000000000000000000000000000000000000 -3=e722d3b1b52761052da2177e2b81de694bec9d06dab31ad57519afca738d4e6e -2=4b1957d850c9cd59d4a501d12adc7db5ffc46fd3a68f0f7cb7665edc2be308dd
CodeDirectory v=20400
Like I mentioned, the iOS app works fine, it's only the watch extension app that doesn't launch.
I've tried to build the app on Xcode 12.5.1 and Xcode 13 and the machine is running Mac OS Big Sur.
I am not sure what else to try, any ideas?
I wanted to mention that the official documentation that I have been referring to on this thread did get published last night. Please refer to Using the Latest Code Signature Format for all of the officially documented details that have been discussed on this thread.
Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
Still, building the app for enterprise and installing it works on the iOS device but the embedded watch app does not. When you try to install it from the iOS watch.app, then it fails with "could not install the app at this time"
This sounds like your watchOS bundled executable is not getting the DER entitlements for some reason. However, I would have expected that Xcode 12.5.1 an Xcode 13 would be doing the right thing here. Also regarding:
Our page size: Page size=4096
-7=8d48d5d98df3b77ce25ac0b1ad03b1d4f50e23d7e377979e409b107324e18266 -6=0000000000000000000000000000000000000000000000000000000000000000 -5=4146cb67c2b6ce380836b0f27ac5760098b8a1af18608163202fd0a9d961d29d -4=0000000000000000000000000000000000000000000000000000000000000000 -3=e722d3b1b52761052da2177e2b81de694bec9d06dab31ad57519afca738d4e6e -2=4b1957d850c9cd59d4a501d12adc7db5ffc46fd3a68f0f7cb7665edc2be308dd
If the above is the hash slot output from the signature of your bundled watchOS executable then you should open a TSI so I can take a look at this situation in more detail. If the above is the hash slot output from the signature of your iOS app, then take a look at your watchOS app and confirm that -7 is there too. If not, then I suspect this is your problem and you will need to re-sign your app from the inside out.
Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
I am facing exactly same issue which one @OliverTrifork faced. I can able to install my app in all iOS 15 devices but its not installed in watch OS 8.
I checked my app page size and CodeDirectory CodeDirectory **v=20400 **
page size is
**Page size=4096
-7=06475d1765dfc11c70d05f2cc4b31d16c49442fc81b07fba2411a492fe696ea6
-6=0000000000000000000000000000000000000000000000000000000000000000
-5=627bc89b3daaaceea7274123e434b0b71eed2c30c3fdb42939bac462ac3c6650
-4=0000000000000000000000000000000000000000000000000000000000000000
-3=040742e532e2adff2af765f976ff83e64eabf3a9c05e907d130e6b1ee075ac3a
-2=734bcba99334852efc4e73c0b65c680cb77c90e7640f9b8cee6aa10f4057dbd3**
Looks like valid signature.
The I tried to check page size of my watch app. I am getting below
**Page size=4096
-5=3f24f91dba33893a034e70ead571e68df75ad6ec7411ad6222171b41c2ac7914
-4=0000000000000000000000000000000000000000000000000000000000000000
-3=a6cf7974ca6d700e37e621d978129162ccc94f2365909650ecd8af34255a2b5d
-2=06b64bd8b69e0816298afe0398435dd6270b40de237bd2e406500acb5c48008b
CDHash=db4c46254c8c2748ae0ad3d96b1f528d63d849ad
Signature size=4821**
here -6 and -7 is missing, that means I needs to resign my app?
Even I tried to resign my app using below command line but I am getting error like 'No Such job'
% codesign -s "Your Codesign Identity" -f --preserve-metadata --generate-entitlement-der /path/to/MyApp.app
Below which one I tried.
% codesign -s "iPhone Distribution: My Company Name" -f --preserve-metadata --generate-entitlement-der /Users/Ponlee/Desktop/Payload/myapp.app
I want to know "Codesign Identity" is correct or not? I copied the name of distribution certificate stored in my keychain. is this correct? Please help to to fix this issue.
Thanks in advance.
Eagerly waiting for your positive and quick response.
Regards Ponlingam
Just to confirm - if I am on Catalina, to distribute ad hoc, after building an .ipa I will always need to go through the resign process?
Yes, Catalina did not have the machinery built into it to create a signature with the DER hashed entitlements. You will need to resign in this case. Follow the steps here.
The I tried to check page size of my watch app. I am getting below **Page size=4096 -5=3f24f91dba33893a034e70ead571e68df75ad6ec7411ad6222171b41c2ac7914
here -6 and -7 is missing, that means I needs to resign my app?
This is common issue. What you will need to do is sign any framework or executable inside your app and then sign your main app last as to make sure you do not corrupt the outer signature. Signing everything inside out. Look at the following folder structure:
MyApp.ipa
Payload/
MyApp.app/ (Need to be re-signed last)
(Many files)
_CodeSignature/
Info.plist
Frameworks/
FrameworkA/ (Need to be re-signed 1st, CANNOT have entitlements)
FrameworkB/ (Need to be re-signed 1st, CANNOT have entitlements)
Watch/
MyAppWatch (Need to be re-signed 1st, can have entitlements)
Plugins/
MyExtension.appex (Need to be re-signed 1st, can have entitlements)
If you have any frameworks, watchOS executables, or app extensions then you will need to sign them first and then your main app last.
Regarding:
I copied the name of distribution certificate stored in my keychain. is this correct?
Yes, this is the name of the signing identity in the Keychain. Moreover, it's actually the name of signing certificate that is visible when click on the item in Keychain Access.
So in my case it would be: iPhone Distribution: Apple Inc. - DTS Matt Eaton (XXXXXXXXXX)
Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
@meaton I tried below command for code signing my app, But I got error " No Such job"
% codesign -s "iPhone Distribution: Dubai Electricity And Water Authority" -f --preserve-metadata --generate-entitlement-der /Users/Ponlee/Desktop/Payload/Myapp.app/Watch/WatchMyapp.app
-bash: fg: %: no such job
Please correct me if anything wrong on above command.
Please guide me how can I do sign. I am using macOS Big Sur Version 11.4 and Xcode 12.5.1
what are the ways to sign or resign app?
-bash: fg: %: no such job Please correct me if anything wrong on above command.
It looks like you are trying to use zsh while in a Bash terminal. For example, if I am in a Bash terminal, denoted by $, and I hit % codesign or just % I will get:
myComputerName:~ muUser$ % codesign
-bash: fg: %: no such job
Switching to zsh should fix this issue, or you can copy the command without %.
After you are in zsh you should be able to run the following command:
myComputerName:~ muUser $ zsh
myComputerName:~ muUser % codesign
Usage: codesign -s identity [-fv*] [-o flags] [-r reqs] [-i ident] path ... # sign
codesign -v [-v*] [-R=<req string>|-R <req file path>] path|[+]pid ... # verify
codesign -d [options] path ... # display contents
codesign -h pid ... # display hosting paths
Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
@meaton After taking a closer look, I see the same as @sponlingam, except we build on big sur, so I'd expect it to sign the watch properly, since it does it correctly for the iOS app. The watch and extension does not have 6-7 signature.. why though? is this an xcode bug? if so.. when can we expect to see this fixed?
This is what the watch signature looks like after archiving through both xcode 12.5.1 and xcode 13:
Page size=4096
-5=b913d5b0ef9ff48816f16a42342ab0037740a6153282266b7935458e6f55d9ab
-4=0000000000000000000000000000000000000000000000000000000000000000
-3=4f2a93c3945beb4b402e6bcad790b4b4c2cff641a50a758b6f3b37ca28a89e6a
-2=516af77f9e299974d68307536ce805fdd9619a4c0cfd8c53d978f6b2bbbce81b
Signature size=4821
After I run codesign manually though, it looks correct... so I suspect that Xcode is for some reason not adding all the relevant params to the watch and extension.
I even tried to force the same params in xcode and from what I can see, it does the same... Taken from the build log:
/usr/bin/codesign --force --sign <redacted> --preserve-metadata --generate-entitlement-der --preserve-metadata=identifier,entitlements /path/to/*.framework
Yet the signature is still wrong, however if I paste the exact same into terminal after archiving, then it seems to sign it properly.
I guess the next step would be to create a dummy project and see if I can reproduce, so I can make a proper TSI...
@meaton After following your suggested steps, right now I can able to install app in iWatch OS 8. But watch app is crashing when I am opening. How can I fix this issue? Please guide me.
@OliverTrifork For you working fine? after re-sign app?
Please help me to fix this issue.
Thanks in advance.
Regards Ponlingam
except we build on big sur, so I'd expect it to sign the watch properly, since it does it correctly for the iOS app. The watch and extension does not have 6-7 signature.. why though?
I can reproduce the same thing on my end in Big Sur with Xcode 12.5, i.e., the outer iOS signature containing the hashed DER entitlements while the inner signature does not contain these entitlements on the watchOS executable (and possibly the watchOS App Extension Executable). You can work around this by adding the --generate-entitlement-der flag to Xcode build settings for Other Code Signing Flags in the watchOS target(s) ane then building the outer iOS app again in Xcode. Then, if you look through the signatures on the executables, you will see the DER hash slot available.
Again, I tested this on Xcode 12.5 in Big Sur 11.5.2.
Note, that while this does work in Xcode 12.5 on Big Sur, I have not been able to get this to work on Xcode 12.4 in Catalina. If you are using Xcode 12.4 on Catalina you will still need to re-sign by hand.
Lastly, there should be a bug opened on this case as I would have thought that Xcode 12.5 on Big Sur would have added this to the signature on it own. Please respond with the Feedback ID.
Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
After following your suggested steps, right now I can able to install app in iWatch OS 8. But watch app is crashing when I am opening. How can I fix this issue? Please guide me.
The advice OliverTrifork provided is correct. It sounds like you are running into a code signing issue and that is why you are crashing on startup. Take a look at the signatures on your watchOS executables. (I just posted an update recently on how to workaround some of these issues in Big Sur with Xcode 12.5)
Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
I can reproduce the same thing on my end in Big Sur with Xcode 12.5, i.e., the outer iOS signature containing the hashed DER entitlements while the inner signature does not contain these entitlements on the watchOS executable (and possibly the watchOS App Extension Executable). You can work around this by adding the --generate-entitlement-der flag to Xcode build settings for Other Code Signing Flags in the watchOS target(s) ane then building the outer iOS app again in Xcode. Then, if you look through the signatures on the executables, you will see the DER hash slot available.
Strange, I have already tried to add --generate-entitlement-der and --preserve-metadata to the xcode project file, so all my targets currently has the params set, but I cannot reproduce your success scenario. The only workaround that has been working for me for now is manually signing.
In no case do I get an .ipa where the watch app or extension has the correct signature.
@meaton Strange issue. I tried both ways, but nothing is working for me.
First Framework Folder Framework A, Framework B ... Etc
Then Watch app
then Under plugin folder Extension 1, Extension2 ... and etc
But no luck. Any other way there to try? Please help me to fix this issue. This is in production issue for me.
@OliverTrifork If you got any solution, Please let me know.
Thanks
Ponlingam