Not able to install enterprise build in iOS 15 beta version

@jazuara

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).

I have reproduced this scenario locally except for I was using Xcode 12.5.1 on macOS Big Sur. I resolved it by adding the --generate-entitlement-der flag to EACH of the build setting targets for Other Code Signing Flags. So that means the watchOS build target and the watchOS extension build target. Then I build and signed each of these targets locally and then switched to the outer app and built and signed that target. I then exported the app as an Ad-Hoc build for testing and was able to break it open and see the DER hash slot (-7) on each of the executables:

$ codesign -dvvvvv watchApp.app

If that does not work then you will still need to resign somehow for installation on iOS 15 and watchOS 8. My first recommendation would be to try update your version of Xcode to Xcode 13.1 on Big Sur. Next, you could also try the same test project on Xcode 13 with macOS Monterey. If none of those options work, then you will need to re-sign by hand.

@OliverTrifork

Regarding:

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.

Glad the issue you were seeing is now resolved. I see that you followed up on (FB9661051), and this would be the best place to get more information. From what I can tell the core of this fix was to remove the need to add in the flag for --generate-entitlement-der to the Other Code Signing Flags.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

On iOS 15, when our app runs we see: AMFI: constraint violation /private/var/containers/Bundle/Application/272392ED-BF0A-48A0-8FB1-4FB707B234A0/REDACTED.app/Frameworks/SwiftProtobuf.framework/SwiftProtobuf has entitlements but is not a main binary

for all our .frameworks.

I checked and all our .frameworks have an empty plist as their entitlements, even though none of them specify an entitlements plist in anywhere in Xcode.

Pray tell why these empty plists are being added Eskimo? And also, why does it trigger a violation in AMFI?

app/Frameworks/SwiftProtobuf.framework/SwiftProtobuf has entitlements but is not a main binary

The SwiftProtobuf executable has been flagged as the outer framework with entitlements. Check this framework executable, or one of its internal executables for entitlements. I would check this out and remove these entitlements from the executable(s) in question:

$ codesign -d --entitlements :- SwiftProtobuf.framework

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

I know everyone seems to be having variations of this issue but I'm seeing this with one of our InHouse apps, the others have compiled/installed/run on iOS devices with no issues but this one app is proving stubborn.

Im running Monterey 12.0.1 with Xcode 13.1. The app is targeting iOS 15, it builds and runs on iPhone 13 Pro 15.1.1 from Xcode fine. I've Archived and Exported with automatic code signing like all our other apps.

Running codesign -dvvvvv ./Payload/AppName.app gives

CodeDirectory v=20400
Page size=4096
    -7=f98e5aa1b62669f050c7f71f4a36834a291ba177b4b8ce8a746de324098ce336
    -6=0000000000000000000000000000000000000000000000000000000000000000
    -5=d1343f304ebed50ddd6d18e38b6602a00cd6e784e02bfe9c5aef1240ace1734e
    -4=0000000000000000000000000000000000000000000000000000000000000000
    -3=fdec1782c98ec9832e5641b126404722b9bcd1e339da35f46766afae8b44dde6
    -2=3fe1b0c56bb490dbc4f2e446ce534fcf547abecd63ffa198978b9615f28ecff6

embedded.mobileprovision also contains

<key>DER-Encoded-Profile</key>
<data>MIINkAYJKoZIhvcNAQcCoIINgTCC...</data>

If I drag the .ipa onto the phone in the devices window the app installs and runs.

However, If I install the app OTA with itms-services://?action=download-manifest&url=https://website.com/manifest.plist I get the "Developer needs to update the app..." message.

Any help would be greatly appreciated.

Thanks, Richard

@richardm

However, If I install the app OTA with itms-services://?action=download-manifest&url=https://website.com/manifest.plist I get the "Developer needs to update the app..." message.

I'm not sure what would be the difference here where installing using both techniques. Do you have any embedded executables that may be causing issues, i.e., an extension or watchOS executable?

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

Im running Monterey 12.0.1 with Xcode 13.2.1 The app is targeting iOS 15, it builds and runs on iPhone 13 Pro 15.1.1 from Xcode fine. I've Archived and Exported with manual code signing. 

Running codesign -dvvvvv ./Payload/AppName.app gives CodeDirectory v=20400

Page size=4096 -7=13e26ed361e9d0FB32727147120d3535af43da3b931bd1e00dc025141324ca26 -6=0000000000000000000000000000000000000000000000000000000000000000 -5=5b48f351db9b9de0fda01ec60714d81c38033c3944bbbe18fa39f4328e8afcaa -4=0000000000000000000000000000000000000000000000000000000000000000 -3=50ecfd80a6734c559a86b3276498b236dc1d427db20f7f1ae93aae5d394f625f -2=de72623b1f6d32dc5f4a0c54270d2238aa5cc2170dc7fb948a832b5bf7b889b7 

However, If I install the app OTA with https://vodafoneidea.quodeck.com/ipa/VILLearning.ipa%C2%A0it does not install

Any help would be greatly appreciated. 

Thanks, Arijit

@meaton

I'm running Monterey 12.4 with Xcode 13.4.1. disctribute the APP With Enterprise method. Running codesing -dvvvvv command line to see the page size result; the APP:

Page size=4096 -7=8e4902ff5912e6e274c0cbc16e9a014c500e5b385cadfc560564f7a82ff107a3 -6=0000000000000000000000000000000000000000000000000000000000000000 -5=33c7cfe078dd02de216dd2363419a2f81c5c0e3bc18515671c48f2b0c3eb25a5 -4=0000000000000000000000000000000000000000000000000000000000000000 -3=bc47e0b759f5972467927a4c3f2b4ca8a72dc340adc10d6df74ac14395d6f643 -2=820825e4e1050e6713d5977da8940a797c59bb8a7069f788e7bc910b39d17f4c

the Frameowkrs in the APP:

Page size=4096 -5=eda0e349a903d27ba3b4d17ddb7364e137bc8292a2457384a8dfa9a663f78802 -4=0000000000000000000000000000000000000000000000000000000000000000 -3=be631c8b88d2d8c886962664f2bdcf69e482566ece81dffe308f8f81ad57a671 -2=a42bc2c474f444f5e1ebe96eb1ffce04c1a73a203c18d6d8229c03aa21bb479b

And there is the Problem: The APP launch up takes less than 2s on devices which system version < iOS 15; but takes more than 10S on some devices which system version > iOS 15.0. I tried to re-sign the APP as 'https://developer.apple.com/forums/thread/682775#681438022'%C2%A0tells. but It does’t work. The codesign result is same as above. I open a TSI for help and your colleagues told me do as 'https://developer.apple.com/forums/thread/682775#681438022'%C2%A0tells three times。I tried,and the frameworks still missing -6 and -7 value lines and the APP still takes more than 10s to launch up.

@Dorado_999

For iOS 15, ensuring that your app's main binary and any embedded binaries, (watchOS apps or app extensions) contain signatures with the embedded hash slots that you have indicated is the first primary step. So, if your app does NOT have an app extensions or watchOS app, and your main app has the hash slots you are indicating, then you should be good if you have this:

Page size=4096 -
-7=8e4902ff5912e6e274c0cbc16e9a014c500e5b385cadfc560564f7a82ff107a3 
-6=0000000000000000000000000000000000000000000000000000000000000000 
-5=33c7cfe078dd02de216dd2363419a2f81c5c0e3bc18515671c48f2b0c3eb25a5 

Now, for your frameworks, checking to make sure that your CodeDirectory complies with what is described here is the main requirement. If your app is able to launch at all on iOS 15 that means that you have at least satisfied the code signature requirements. If your app did not satisfy these requirements your app would crash right away and not take 10 seconds. I suspect the reason why you are wondering about this is that 10 seconds is a very long time to wait for your app to launch, or you might be getting hit with a watchdog termination on launch. There are a few things I would recommend that you do from here:

• Take a look at the provisioning profile and the certificate(s) attached to the profile. Is it a case where you have multiple certificates attached to the profile and does it take a long time to evaluate each certificate on the profile? Likewise, if you have a lot of large frameworks does reducing the amount of certificates attached to the profile decrease this evaluation any?
• Take a look at the logs to see if your signature evaluation is being hung up anywhere? For example, are there multiple nested layers of framework dependencies that a signature is being evaluated from?

This should at least get you started debugging this issue.