I have been working through what it would take for a real app, say a bank's, to adopt Trust Insights in a way that works for customers around the world, using only what has been published so far: session 379, the framework documentation and the support article. While the client side works well, there is information a production app needs that I could not find. So I am posting this for two reasons. Some of what I learned may save you time, and since the rest needs an answer from Apple, I would like to have those questions answered in one place.
If you would like to see working code, the sample project I used keeps all of the API in one file.
What I measured
Adding the Trust Insights capability in Xcode was all I needed to get the whole flow running on a device: the permission alert, the evaluation and the report. The simulator returns .unavailable, so you will need a device to test any of this.
There are two switches to keep in mind, the system one at Settings > Privacy & Security > Impersonation Risk Detection, and one for each app underneath it. This is what I got from authorizationStatus(for:) in a development build:
With the setting turned off, for the app or for everything, it returned .denied right away, even though the support article says changes might take up to 24 hours.
It was still .denied 24 hours later.
When I turned the setting back on, it returned .authorized right away.
After deleting and reinstalling the app it returned .denied, and did not go back to .notDetermined.
So while the documentation describes .denied as the person refusing permission, in practice it also covers the setting being off, and you should plan for customers who will never see your permission alert. Since I could not find an API that opens that page in Settings, all you can do is tell them where it is, and you should call it Impersonation Risk Detection because that is the name they will see there.
What I would do today
Treat having no evaluation as a normal path. Between permissions, availability, the network and server errors, some of your customers will not get a result, and in all of those cases your existing checks should decide and the transaction should carry on as it did before.
Start the evaluation early. The session says it takes a couple of seconds and the documentation says several, so I start it when the screen appears, and a production app should also stop waiting after a deadline of its own. An evaluation that comes back too late still has to be reported, as .notUsedError.
Call reportConsumption once for every evaluation, on every path, including a transaction the person cancels (.notUsedNotNeeded). The documentation says that skipping it may result in rate limiting or losing access to the service, so this is not something to leave for later.
Until the server side details are available, only use the result to add friction. A decision made in the app can be changed by anyone who can change the app, which does not matter for a warning, but it does matter if unknown lets someone skip a check.
Keep the eventID with your transaction records, even if you have no way of using it yet, because that is what the documentation says identifies the evaluation when fraud is discovered later.
If your fraud team wants to see numbers before anything changes for customers, .usedEvaluationOnly is the documented way to report an evaluation that had no effect on a decision.
For UI work, put your decision behind a type of your own and drive the warning screens from a debug switch, because there is no way to create the conditions for a medium or a high on purpose.
What I could not find: the information we need from Apple
These are the questions I would like answered, along with what each one means for you until they are.
The session says values and errors can be overridden with launch arguments, and refers to the documentation for the list. Where can we find that list? Until then, the medium, high and error paths can only be tested by reading the code, which is not a comfortable place to be for a flow that holds someone's money.
Which devices and regions are supported, and what determines the region that applies to a device? The documentation for .unavailable mentions both without listing them, so if your app has customers around the world, you cannot yet tell your support team who should be getting this, and .unavailable on its own will not tell you why.
What status should an app expect on a phone where the setting has never been changed, and can it show the permission alert in that state? If the answer is .denied, your app cannot ask until the customer has found the setting on their own, which would change how you plan for adoption.
What does the 24 hour delay apply to, and do evaluations behave differently during it? Because the status changes immediately, at least in development, I cannot tell you what to expect in production.
Which environment do TestFlight, Ad Hoc and Enterprise builds use? The session only separates development (sandbox) from the App Store (production), so you cannot be sure how much your beta testing tells you about production.
What are the rate limits, and is there guidance for rolling this out to a large installed base, as there is for App Attest? The documentation says a limit can apply to the app on one device or across all devices. For now I would ramp up slowly, and treat rateLimitExceeded as having no evaluation.
What period of activity does an evaluation reflect, and how long does the result stay meaningful? Because I have to start it early, I do not know how much a result from when the screen appeared says about what is happening when the person taps Confirm a few minutes later.
How does a server verify signedPayload? I could not find the keys or the payload schema. Until that is available, using a result to reduce friction (.usedReducedFriction) cannot be done safely.
Where is the API for reporting fraud after the fact documented, and can it be used without a verified business on Apple Business Register? The session refers to the documentation for this, and also to Partner Data Services, which I could not find described anywhere public.
I have filed all of this as a documentation request, FB25453150, which also covers a few smaller items like language support and privacy declarations. I will update this thread as I learn more, and if you have measured something different from what I describe here, please post it, because that would help everyone working on this.
S.BECK - 7strikes.dev
