Enhanced Security Capability < iOS 26

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"

Posting here in case anyone is following the progress - The resolution has gone from "Potential fix identified - For a future OS update" to "Open"

I want to highlight a couple of points in the releases notes for the software that we seeded yesterday:

• Xcode 26.4 Beta Release Notes documents new entitlements that allow your app to deploy back to pre-xyzOS 26 systems (search for 168185600 to find the info).
• iOS & iPadOS 26.4 Beta Release Notes document that hard mode is now an option (search for 160719439).

I haven’t had a chance to play with this yet, but I encourage you to take it for a spin and lemme know how you get along.

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