Hello, we are currently encountering a similar issue. We need to inject our capabilities into a third-party app by re-signing it (not a full re-signing process—just requiring the provisioning profile and certificate to match). However, this seems to affect the functionality of universal links. We've found that this issue only occurs on iOS 18.
We noticed that when re-signing the app, the entitlements related to associated domains are changed to a wildcard:
[Key] com.apple.developer.associated-domains
[Value]
[Array]
[String] *
However, this doesn’t cause any issues on iOS 17.
Through further testing, we discovered that in order for universal links to work properly, we need to restore the original value of com.apple.developer.associated-domains and use a provisioning profile that matches the app's bundle ID. This means our previous re-signing approach using a certificate and provisioning profile from another bundle will no longer work.
We’d like to ask: is this a new restriction introduced in iOS 18? If we manually restore the original com.apple.developer.associated-domains entitlement and use a provisioning profile that matches the app’s bundle ID, will universal links function correctly going forward?
Topic:
Code Signing
SubTopic:
Certificates, Identifiers & Profiles
Tags:
Entitlements
Provisioning Profiles
Universal Links
Code Signing