Not able to install enterprise build in iOS 15 beta version

@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

@OliverTrifork

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

@sponlingam

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

@meaton

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.

1. Re-sign app (Manual signing)

First Framework Folder Framework A, Framework B ... Etc

Then Watch app

then Under plugin folder Extension 1, Extension2 ... and etc

1. Added '--generate-entitlement-der' in Other Code signing Flag in watch app

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

Any updates on this one. Facing the same issue with iOS app with watchOS extension

Any updates on this one. Facing the same issue with iOS app with watchOS extension

Here is what I did; I added the --generate-entitlement-der flag to each of the watchOS target's build settings for Other Code Signing Flags. Then I went through in Xcode and built each one of these watchOS targets separately. Then I built the outer app in Xcode and inspected the signatures on the nested executables to make sure the DER hash slot was there. If the DER hash slot is getting there and you still cannot run the app then something else might be going on and you should open a bug report.

Keep in mind that your iOS bundle may looks like this with many sub-levels of watchOS executables:

MyApp.ipa 
 Payload/
   MyApp.app/ (Need to be re-signed last)
      (Many files)
      _CodeSignature/
      Info.plist
      Frameworks/
        FrameworkA/ (Need to be re-signed 2nd, CANNOT have entitlements)
        FrameworkB/ (Need to be re-signed 2nd, CANNOT have entitlements)
      Watch/
        MyAppWatch (Need to be re-signed 1st, can have entitlements)
          (Many files)
          _CodeSignature/
          Info.plist
          MyAppWatch
          Plugins/
            MyAppWatch Extension.appex (Needs to be re-signed 1st, can have entitlements)
              _CodeSignature/
              Info.plist
              MyAppWatch Extension
      Plugins/
        MyExtension.appex (Need to be re-signed 2nd, can have entitlements)

And so if your watchOS apps are preventing your iOS app from working then you need to interrogate the bundle structure to make sure that each of the nested executables contains the DER hash slot (-7) on the signature. If you have a bundle structure similar to the one above, try doing the following:

1. Start with Xcode 12.5.1 on macOS Big Sur add the --generate-entitlement-der flag as I mentioned above to EACH of the build target's Build Settings for Other Code Signing Flags. Then build each target in Xcode starting with the watchOS targets and ending with the iOS target. Inspect the signatures then in the Terminal before you move on and confirm that the signatures contains the DER hash slot.

2. If #1 does not work, then you will need to re-sign this be hand as mentioned in Using the Latest Code Signature Format.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

Thanks for the reply @meaton. Is there a way to automate this process? Also, we are using third-party frameworks, can we sign them. Any guide would be appreciated

@sapramit

Is there a way to automate this process?

I will leave the automation up to your specific build system requirements.

Regarding:

Also, we are using third-party frameworks, can we sign them.

Yes, you should sign these frameworks. The framework will keep their bundle identifier, but you should sign the framework first/second (as indicated above), just do not add entitlements to this signature.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

..

I am using Catalina and followed the re-signing instructions successfully. After re-signing with DER entitlements I was able to launch the app in my ios 15 device and use it. But I noticed one weird behavior in regards to the App launching icon. The app Launch icon appears as white icon with lines in it, when I tap on the icon it launches the app and for a short while (before app opens) I can see the proper Launch icon for the app. If I close the app and go back to Home screen then I see the proper Launch icon for a second or so, then it goes back to the white icon. Is this indicating an issue with signature or something else?

Follows the white icon.

@esrodrigorcl

I am using Catalina and followed the re-signing instructions successfully. After re-signing with DER entitlements I was able to launch the app in my ios 15 device and use it.

Glad the re-signing instructions work out for you.

Regarding:

The app Launch icon appears as white icon with lines in it, when I tap on the icon it launches the app and for a short while (before app opens) I can see the proper Launch icon for the app. If I close the app and go back to Home screen then I see the proper Launch icon for a second or so, then it goes back to the white icon. Is this indicating an issue with signature or something else?

This does not sound like a signature issue if the app is able to open and function. If it were a signature issue the app would not even be able to open. Please open a bug report about this as it may be a caching issue on the system.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

I did not open the bug report because when I upgraded my device to IOS 15.0.2, the Launch Icon issue disappear.

Great news!

Regarding:

I tested in BigSur with xcode 12.5.1 and the ipa did NOT need to be re-signed. I also tested in BigSur xcode 11.3.1 and the ipa did NOT need to be re-signed.

Great point to bring up here. When I mention different versions of Xcode here on this post, it is often associated with Xcode versions supported by a specific version of macOS. For example, Catalina will only run up to Xcode 12.4 and then Xcode 12.5 is Bug Sur and later. That is the vantage point that I have taken in this thread because this is what I have primarily seen out in the community and also what I am able to test in my office.

Now, what you are saying is correct, Big Sur should do the right thing here and sign with the DER hash slot because it has the machinery to do so. If you are have nested executables such as watchOS apps or extensions, please please make sure to double check that your Xcode version with Big Sur has also signed with the DER hash slot there as well.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

So Im having this issue even tho I'm using macOS Big Sur 11.6 & Xcode 13 (from the App Store).

I created a dummy empty app with a watch app extension.

After building, archiving & creating the spa file. Only the iOS app has the right DER hash slot (6 & 7), but the watch app does not have them.

I have added --generate-entitlement-der in Other Code Signing Flags and still does not work.

Im archiving the release scheme of the app then distributing with the new provisioning profiles (I have made sure they contain the new DER key).

Any ideas?

Thanks in advance.

The issue (that we were having) seems to be have been fixed with Xcode 13.1. Our build server which is running mac OS 11.5.2, updated Xcode to 13.1 yesterday, and now our .ipa are being properly signed.

It would have been nice if the release notes addressed this though...