Demystifying Siri, Part 6: Enums in Custom Intents
At the end of Part 5 we came tantalisingly close to our goal of implementing a Countdown numbers game solver in Siri. But we hit a snag. Siri recognises the user saying “three” but not “eight”. What is going on here? Let’s take a look at the screenshots:
There’s a clue there. When I say “three”, Siri identifies my spoken input as a number 3 and moves on. When I say “eight”, Siri identifies my spoken input as the word “Eight” and doesn’t match any of the enum values. Could this inconsistency between words and numbers cause the issue? Time to get stuck into Apple’s documentation for SiriKit enums.
Hmm. So Plan B then is to try and fill in the gaps in the documentation.
How Siri resolves enumerations
UPDATE: The below information will soon become out of date as I’m told that there are software changes in build 18F5046f (iOS 14.6 beta) which solve this problem. I’ll update the blog when I have more information.
When creating a new enum case, there are a few different fields to fill in. Which of them, if any, does Siri use to compare with your spoken phrase?
Let’s create a new enum case. The case value is .red but we’ll give it a display name of blue. We’ll also add a speakable match of green. I’ve added pronunciation hints for clarity but they shouldn’t be needed. What happens now if I say ‘red’, ‘green’ or ‘blue’?
The answer is… nothing matches!
- When I say ‘red’, Siri renders this as ‘Read’, which doesn’t match.
- When I say ‘blue’, Siri can’t identify a matching case. To be fair, this is a display name only, though I have no idea why a display name needs a pronunciation hint.
- When I say ‘green’, Siri can’t identify a matching case. I’d have expected this to match, given that this is described as an “Alternative Speakable Match”.
Ok, so perhaps the case value is a promising lead. Let’s tweak it slightly…
What happens now? ‘Kettle’, ‘toaster’, ‘spoon’ and ‘knife’ don’t get matched, but ‘dishwasher’ does. Funnily enough, so does ‘dish’. And ‘washer’. But not ‘dishwasher tablets’.
Every day is a learning day
We can now therefore conclude the following:
- Siri can identify an enum case if all or part of the enum value is spoken.
- Setting the Display Name and Alternative Speakable Matches appear to have no effect on what is matched.
- If Siri decides on a different interpretation of your spoken input (e.g. ‘red’ vs ‘read’ or ‘seven’ vs ‘7’) then there is no match.
(All of the above is current as of iOS 13.7.)
The lack of implementation of Alternative Speakable Matches is a surprise but can be confirmed by looking inside the custom generated class for InitialNumberResolutionResult - there’s no sign of our values. (Have a look for yourself by right-clicking on an instance of InitialNumberResolutionResult and selecting Jump to Definition.) A Google search for Alternative Speakable Matches turns up very little too, so maybe we’ve reached the seldom-visited frontier of SiriKit functionality.
So far, so frustrating. But we can use the partial matching of case values to our advantage. As a workaround, let’s change our case values to .one1, .two2, .three3 etc. Does this work I wonder?
Yes! It’s a little clumsy but finally we can match numbers consistently. And now we have a way of providing input parameters to Siri, and have Siri respond with a result. We’re there or thereabouts now - everything else is just window dressing.
Talking of which, recall when we created our Intents extension, back in Part 5. We kept that Include UI Extension box checked - to round everything off, in Part 7, we’ll find out why.