Apple, client-side applications, and being “good at web services”

July 05, 2016 · 5 minute read

There’s been a lot of talk these past couple of years about how good Apple is or isn’t getting with regards to developing web services. When referring to Apple’s services acumen, I think people generally mean the speed, consistency, and reliability of offerings like iMessage, iCloud, Apple Music, and the App Store(s).

I’d argue that these characteristics, while necessary, are not sufficient for a web service to truly be “great.” To make a great service, the proprietor must truly understand and buy into one of the web’s core tenets: interoperability. This is only becoming more important as time goes on.

A couple of years ago when the web vs. mobile debate was still (sort of) interesting, John Gruber published his thoughts on the matter:

We shouldn’t think of the “web” as only what renders inside a web browser. The web is HTTP, and the open Internet.

I really like the sentiment here, but I worry about whether or not Apple sees it this way. HTTP, a universal protocol that allows clients to talk to servers in ways that wouldn’t be possible if everyone used a different (perhaps proprietary) transport mechanism, is only as good as the number of clients that are actually allowed to communicate with your server using it.

CloudKit web services is one of Apple’s more recent service endeavors, and the fact that it can be openly communicated with over HTTP is reason for optimism. But let’s take a look at Apple Music. Unlike most other streaming music services, Apple Music doesn’t have a public HTTP API, meaning a third-party like Last.fm can’t easily integrate with it; there simply isn’t a way for the Last.fm servers to connect with Apple’s the way that they can and do integrate with Spotify. iOS 9.3 did add client-side Apple Music APIs, but these aren’t nearly as useful as an HTTP API would be. Nobody’s servers run on iOS.

Apple Music works with Sonos speakers, but it doesn’t work with the Amazon Echo. And no one outside of a Cupertino business development meeting will have the ability to make it work with the next great Internet connected speaker or smart home device. I buy the argument that the new web is “HTTP and the open Internet,” but in this case, Apple might as well be using something proprietary instead of HTTP. The lack of openness means they aren’t actually allowing their service to be a part of this new web¹.

Apple now claims that being a services company is important to them. If they’re able to address the latency and reliability issues that their services have historically been plagued with, they may have succeeded at exactly what they set out to improve. But I still personally won’t consider them a good services company until they take tangible steps towards making their APIs far more open than they have been to date. These types of companies understand that they alone cannot build all of the interactions their users would find useful (nor would targeted, limited partnerships suffice). They earn the adoration of their developer community by empowering them to create the next big app or feature, standing on the shoulders of giants rather than sitting in their pocket.

In addition, I’d love to see this same mentality adopted by third-party client-side application developers, not merely Apple. In 2013, Brent Simmons astutely opined that when his customers asked him for “sync,” they were usually really asking for multiple versions of an application. Users of his Vesper app for iPhone wanted an iPad version and/or a Mac version; the fact that an HTTP API running on a server would facilitate these new versions was an implementation detail, not what anyone was explicitly asking for.

While I think he was right in 2013, I’m not positive that this same logic holds today. For the apps and services that I rely on the most, I increasingly do care about how the back-end can be communicated with. Products like IFTTT, the Echo and Google Home will only proliferate this mentality to more and more non-technical consumers. They may not know about REST or HTTP, but they’ll wonder why their Echo can hail an Uber but not a car from a different car service. Interoperability will become more of a selling point as the Internet-of-Things becomes more of an actual thing.

Take OmniFocus² (one of my most beloved app/service combinations), for example. The OmniGroup recently added some new (incredibly laudable) client-side automation features, but still don’t allow developers to easily hook into their back-end directly. Their justification for this is that they don’t actually have a back-end, and while I commend their commitment to a degree of user control/data security that a centralized server wouldn’t allow for, I still can’t help but be discouraged.

Their answer to products like IFTTT and the Echo is Mail Drop, a service that turns emails that into OmniFocus actions. While I’m heartened that they clearly care about interoperability and plan to continue making Mail Drop more advanced, I’m flummoxed as to why they wouldn’t give us a service based on HTTP rather than email³.

Closed systems have enabled Apple (and members of their developer programs) to deliver many of the user experiences we know and love, but past performance does not equal future success. While embracing interoperability might require a philosophical shift away from what has worked to date, I worry that the alternative is Apple continuing to stretch themselves thinner and thinner as software continues to eat the world and hardware continues to become smaller, cheaper, and more ubiquitous.

The Echo, programmable Dash buttons, and now a Siri “API”⁴, are only the beginning. As the number of Internet-connected devices that we use increases, so does the importance of third-party developers being able to integrate these devices and services without their proprietors having the foresight or granting us specific permission to do so.

Enabling this is what being good at web services means to me.