I can answer part of this. I can't test in China or on an iPhone 15 sold there, so whether this is regional gating or device limitation stays open, and only Apple can answer that.
Is this region gating?
I don't know. The docs for AuthorizationStatus.unavailable give three causes: an unsupported device, an app without the entitlement, or "the framework isn't available in a specific region". So, it implies that region matters. Apple has not published a list of regions or supported models, and the iOS 27 feature availability page doesn't list this feature. The support page gives no regional limit in English or Simplified Chinese. None of that tells you whether it runs on your phone.
One could assume that because the Chinese support pages show how to enable this feature to the users, the feature might be available in the region. Perhaps the limitation is with the device. The fact that the Settings entry is missing indicates either/or, that something is causing the device to not have this enabled.
In my tests, the entry was present even before I had any apps (including mine) that exercised the feature. Once the app was installed and ran, it appeared under the entry.
Don't rule out the entitlement yet.
security cms -D shows what the profile allows. What counts is what the app was signed with, so check the built app:
codesign -d --entitlements - /path/to/YourApp.app
will show if the app was signed correctly and includes the entitlement in the bundle.
What to test
If you confirm that the binary indeed includes the entitlement, you can test, by changing one thing at a time. After each change, look for the Settings entry and log authorizationStatus(for:). I don't know whether any of these matter, which is why they're worth testing.
-
Test with the latest 27.3 beta, in case this is indeed region gating that will be enabled later.
-
If you can, run the same build on an iPhone bought outside China. If it gets .notDetermined or .authorized, your build and entitlement are fine. Alternatively, prepare a small project that only demonstrates your implementation of TrustInsights and attach it to your reply here. Perhaps someone outside China can test it for you.
-
On your phone, change Settings > General > Language & Region > Region, then run it again. Change it back afterwards.
-
Check that you're signed in to the App Store [sic]. The support page says turning the feature on might need that. I don't know if that's a typo and they mean logged in to your Apple ID on the device.
If you have a test Apple Account with a different country or region, try that too. Don't move your main account for this.
For comparison, on my iPhone, outside China, I added the capability in Xcode and requested nothing else. With the setting on, the permission alert appears and evaluations come back. When I turn the setting off, for the app or for the feature, authorizationStatus(for:) returns .denied. So a switched-off setting doesn't explain your .unavailable.
I have a TrustInsightsSample that does work on a US phone. You can also test that to see if the lights are on.
Which one is the actual gate?
Act on authorizationStatus(for:). Apple's example in the framework overview checks it first and stops on .unavailable, so don't call requestEvaluation after that. It is possible that if the authorization is unavailable, the further statuses are undefined.
I can't explain why you get denied there. The docs tie denied to the person's options and notAvailable to the device, and your case sounds like the second. File that in Feedback Assistant with a sysdiagnose, whatever the tests show, and post the number here in case someone from Apple wants to follow up.
The Settings row
The support page describes the top-level entry and its switch first, with per-app access underneath. So I wouldn't expect the top-level entry to be waiting for your app's first request. Like I said, for me on a phone where no app has ever asked, the Settings entry was present.
Working without the Settings entry
The WWDC session says values and errors can be overridden with launch arguments, and points to the documentation for the list. I can't find that list. If you found that key in Apple's documentation, post the link for everyone. Reading it back from UserDefaults only shows the argument reached your process. Any -key value launch argument does that, whether a framework reads it or not.
You don't need Trust Insights for the UI work. Put the decision behind your own enum (no evaluation, unknown, medium, high) and drive the screens from a debug switch. That won't exercise the evaluation or reportConsumption, which still need a device where the framework is available. Ship the no-evaluation path as a normal path: your existing checks decide and the action goes ahead.
Developer-side enablement
The only requirement I can find documented is the com.apple.developer.trustinsights.base entitlement. I can't find anything about enabling it per region. Whether a region needs anything more is for Apple to answer, so ask that in the same Feedback report.
-------------------------
| S.Beck - 7strikes.dev |
-------------------------
