Categories
iOS SiriKit

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.

A screenshot of the entirety of Apple's SiriKit Enumerations documentation - 'no overview available'
SiriKit enumerations – or maybe not

Hmm. So Plan B then is to try and fill in the gaps in the documentation.

How Siri resolves enumerations

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’?

A test enum case with identifier .red, display name blue and alternative speakable match green
A test enum

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…

A test enum case with identifier .dishwasher, display name kettle and alternative speakable match spoon
Another test

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?

Result!

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.