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 ?
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:
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.
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
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.
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...
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.
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
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
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.
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:
This should at least get you started debugging this issue.