Enhanced Security Capability < iOS 26

Hi,

After enabling the new Enhanced Security capability in Xcode 26, I’m seeing install failures on devices running < iOS 26.

  • Deployment target: iOS 15.0
  • Capability: Enhanced Security (added via Signing & Capabilities tab)
  • Building to iOS 18 device error - Unable to Install ...Please ensure sure that your app is signed by a valid provisioning profile.

It works fine on iOS 26 devices.

I’d like to confirm Apple’s intent here:

  1. Is this capability formally supported only on iOS 26 and later, and therefore incompatible with earlier OS versions?

  2. Or should older systems ignore the entitlement, meaning this behavior might be a bug?

Answered by DTS Engineer in 864837022

Please file a bug about this. There’s advice on how to gather the necessary info in that error alert, and it’d be great if you attach that to your bug report.

Once you’re done, please post your bug number, just for the record


When you click the Show Details button in that error alert it shows a bunch of info about what’s causing the error. It’s clearly grumpy about the provisioning profile. However, when you compare the profile’s allowlist and the code signature’s claims, things generally look OK.

One thing I did notice is that there’s a bit of a mix up about the type of the com.apple.security.hardened-process.enhanced-security-version entitlement. That’s documented to be a string, and the profile’s allow list uses a string value of *. However, the code signature claims an integer value of 1.

I manually re-signed the app to use a string:

% cat tmp.entitlements 
…
<dict>
    …
    <key>com.apple.security.hardened-process.enhanced-security-version</key>
    <string>1</string>
    …
</dict>
</plist>
% /usr/bin/codesign --force --sign 09513FD4A03387429F6568048A5F76A74387828A --entitlements tmp.entitlements --timestamp\=none --generate-entitlement-der Test806195.app 

and the app installed and ran. My guess is that iOS 26 is smart enough to interpret a string * as authorising an integer 1, but iOS 18 isn’t. However, I’m really just guessing here. My advice is that you file a bug and let the experts investigate.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Please file a bug about this. There’s advice on how to gather the necessary info in that error alert, and it’d be great if you attach that to your bug report.

Once you’re done, please post your bug number, just for the record


When you click the Show Details button in that error alert it shows a bunch of info about what’s causing the error. It’s clearly grumpy about the provisioning profile. However, when you compare the profile’s allowlist and the code signature’s claims, things generally look OK.

One thing I did notice is that there’s a bit of a mix up about the type of the com.apple.security.hardened-process.enhanced-security-version entitlement. That’s documented to be a string, and the profile’s allow list uses a string value of *. However, the code signature claims an integer value of 1.

I manually re-signed the app to use a string:

% cat tmp.entitlements 
…
<dict>
    …
    <key>com.apple.security.hardened-process.enhanced-security-version</key>
    <string>1</string>
    …
</dict>
</plist>
% /usr/bin/codesign --force --sign 09513FD4A03387429F6568048A5F76A74387828A --entitlements tmp.entitlements --timestamp\=none --generate-entitlement-der Test806195.app 

and the app installed and ran. My guess is that iOS 26 is smart enough to interpret a string * as authorising an integer 1, but iOS 18 isn’t. However, I’m really just guessing here. My advice is that you file a bug and let the experts investigate.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

The resolution of FB20939056 was : Investigation Complete -- unable to diagnose its current information. I added this thread to the "add more information" for added context. I added as much information as I could.

Seeing as I can reproduce this myself, I’ve added my own info to the bug and, between your efforts and mine, that should get it back on track.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks again. Resolution has been updated to "Potential fix identified - For a future OS update". Could be wrong but this may mean an Xcode update.

A quick update.

Based on the work so far in FB20939056 it seems that my analysis of the issue was pretty solid. iOS 26 was specifically changed to allow the type mismatch between the entitlement claim and the provisioning profile authorisation (r. 152513118). That fix is not in iOS 18, and hence the app doesn’t run.

Curiously, if you deploy this to the App Store it should run on iOS 18, because App Store apps are re-signed by Apple and thus don’t need a provisioning profile to authorise their entitlement claims. Of course that’s a risky option.

The standard way to mitigate such risks is with TestFlight. I haven’t tried this there. My best guess is that it’ll fail in the same way, but I wouldn’t be surprised if it worked. My understanding of the provisioning machinery for TestFlight is not as good on iOS and it is on macOS. If you try this, please reply here to let me know if it worked or not.

On obvious, albeit clunky, workaround is to remove the capability when running on iOS 18 devices and add it back when running on iOS 26 devices. Not fun, but it should work.

Getting around this in Xcode is likely to be tricky, but we haven’t quite given up yet. I’ve ask that we use FB20939056 to track that effort.

[I guess this wasn’t such a quick update after all |-:]

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks for the update!

I had tried with TestFlight previously and it fails to install as well.

We support iOS versions 15-26 and distribute QA builds to testers via TestFlight so the only viable option at the moment is to programatically add the capability for iOS 26 only but I have not found a way to do that!

TestFlight … fails to install as well.

Thanks for confirming that.

programatically add the capability for iOS 26 only but I have not found a way to do that!

That’s not possible. Xcode reflects this capability into your app’s entitlements. Entitlements are baked into your code signature. You can’t add them at runtime.

If you’re curious how this actually works, have a read of TN3125 Inside Code Signing: Provisioning Profiles.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Enhanced Security Capability &lt; iOS 26
 
 
Q