Why Apple Chose the SiriKit Categories

Craig Federighi introducing SiriKit

For years app developers have been asking for a way to connect their apps to Siri. At WWDC 2016 Apple released a preview of SiriKit, a way for developers to allow Siri to control their apps. Unfortunately, instead of the wide-open API that developers were hoping for, Craig Federighi revealed that SiriKit would be only available to a select group of app types. The categories that can interact with the first version of SiriKit are:

  • Ride booking
  • Messaging
  • Photo Search
  • Payments
  • VoIP Calling
  • Workouts

In addition to those categories mentioned at WWDC (called “Domains” in SiriKit), there are three more:

  • CarPlay Climate
  • CarPlay Radio
  • Restaurant Booking

The allowed categories seemed like an unusual choice and people began trying to understand why Apple chose this particular set of domains. John Gruber asked this question to Craig Federighi in a Talk Show special. He answered that the domains were ones which Apple has a lot of experience with and could model easily.

I think this is half true. Apple does have experience in using Siri for some of the domains, but has never offered ride booking, payments or restaurant booking. Workouts have only been available since Apple Watch debuted, just a year ago.

My theory is that there are two additional reasons for the choice of domains, both of which stay true to Apple’s love of the 80–20 rule. The first is that the domains allow a limited rollout for SiriKit. The second is that they target the largest number of customers for the smallest effort.

The thing that most of the domains have in common (with a single exception) is that they are categories that are only available to very large companies. This means that the number of app developers that can use SiriKit is small, probably in the dozens or hundreds at most. Examples of these companies are Skype, Uber, Nike, Square and OpenTable. Most of the domains require a large-scale back-end or some other complicated setup. It would be near-impossible for a small developer to create a ride-booking service. It’s true that there are some exceptions, like small-scale workout tracking companies, but that category has mostly been whittled down to apps that are free but charge subscriptions for access to a back-end.

So why would Apple want to limit the number of companies that can use SiriKit? The first reason is that they can make sure that SiriKit isn’t abused. A smaller set of companies using SiriKit means that people will use it as intended. Apple most likely has close, one-to-one relationships with many of the target companies and they can work together to both vet the apps and to iron out any problems. With an unlimited rollout, someone would be sure to use SiriKit to create a sexy fembot app, attracting the usual bad press for Apple.

The odd-one-out is photo search. It’s possible for a small app developer to create a photo tagging and organizing app, but most indie development in that area is focussed on photo-taking apps. I believe that domain is there for apps like Instagram, Facebook and Flickr to use, and because photos have become such an important part of Apple’s strategy with the iPhone.

The second reason for the choice of domains is the amount of reach this small set of companies have. The large majority of iPhones would have one of the target apps installed. The large majority of customers would use one of these apps each and every day. Messaging and VoIP companies like WhatsApp and Skype number their users in the hundreds of millions. By just targeting a small number of companies Apple gets the biggest bang for their buck.

There’s another aspect of the choice: Competition. Apple has opened up Siri to companies that compete directly with technologies like Apple Pay, iMessage and FaceTime. But notably, they’ve prevented use by music and mapping apps. These are both areas where Apple has lagged, with Apple Music just one year old, and Apple Maps still trailing Google Maps for accuracy. While controlling Spotify playback with Siri seems like one of the best use cases, and it’s the one most end-users would clamour for, it may be several years before it’s opened up.

The last aspect of the choice of domains is practicality. SiriKit is offered to developers through the Intents framework. Even though there are only 9 domains, the API is enormous. There are over 200 new items (types, protocols and other assorted stuff).

Each domain has one or more intents, each representing a user action. Each intent has at least three things associated with it, to clarify, confirm and handle the intent. There are also multiple model types that represent real-world objects. Furthermore, all this is handled in all 36 locales that Siri can communicate in.

Creating, testing and maintaining the Intents framework is a significant job for Apple. Because of this it makes sense to get the best return for developer time. It makes sense to limit the rollout to a small number of experienced developers who represent the largest segment of Apple’s user base.

So while I’d love to be able to add tasks to my Todo list app, I understand that this use case is still too niche to allow time to be invested in it. When trying to predict which domains will be opened up to SiriKit in 2017, look for ones that enable the largest number of customers to perform a task offered by a small number of companies in an area that Apple already has a good foothold in.