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

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 web1.

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 OmniFocus2 (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 email3.

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”4, 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.

  1. To me, one of most glaring indications that Apple Music isn’t a “service-first” product is the fact that there isn’t a shared “Next Up” queue that persists across all of your devices. If I’ve started playing an album on my Mac, I should be able to walk out the door and pick up right where I left off on my phone. Rdio did a masterful job of this (even letting you choose to either transfer playback to your phone or simply use it as a remote for your computer), and I really miss it.

  2. Incidentally, Brent also works on OmniFocus now.

  3. It’s only a matter of time until I build my own server that simply turns incoming HTTP requests into outgoing emails to Omni, but this isn’t ideal. My proxy server will have to return a 200 OK for every request, regardless of if an action was successfully created on Omni’s server or not, for example.

  4. Don’t even get me started about how much of a mistake I think it is that Siri integration is entirely client-side as opposed to server-side. Farhad Manjoo (Can Apple Think Outside the Device?) and M.G. Siegler (Siri in Chains) perfectly dissect this decision in their respective pieces.

Libraries we didn’t need

At Tumblr, we were beyond thrilled when iOS 8 provided the ability for us to create an extension that could integrate with the OS at a deeper level than our application did. In practice, we ran into a handful of limitations. For a non-trivial part of my final year there, I worked on a library called XExtensionItem, intended to address a couple of these shortcomings.

As I approached a 1.0, iOS 9 was released, obviating the primary issue that prompted me to build XExtensionItem in the first place. It still would have proven useful, but the diminished utility didn’t seem to justify much more development effort (or any subsequent evangelization). I effectively gave up on it and it hasn’t been touched since.

This isn’t a sob story, however. Third-party libraries are usually built because we’re lacking an adequate first-party solution to a problem, and in most cases, the best thing for the broader community is for a first-party solution to eventually materialize. The percentage of iOS developers who would’ve ever heard about my library – let alone actually integrated it – pales in comparison to how many have benefited from the fix that Apple ended up adding in iOS 9. Most almost certainly don’t even realize it.

I remember feeling bad for my friend Jared Sinclair after he put so much work into OvershareKit, only for Apple to go ahead and release the very Extensions APIs that we had been clamoring for at Tumblr. But in hindsight, I don’t think he would have wanted me to. OvershareKit wasn’t built because he expected it to bring him fame or fortune; he was simply trying to provide a solution to a problem that he knew he wasn’t the only one facing. While he may have preferred many aspects of OvershareKit to Apple’s built-in UIActivityViewController, he knew that no solution he could deliver was better than the problem simply going away.

So while I don’t actually care that something I put a lot of time into didn’t amount to anything in the end, it felt weird that I never ended up talking about it. Hence my talking about it now.

I’m glad you didn’t need to exist, after all.

Nice and smart people

To say that I was full of emotions as I was leaving my first full-time job would be an understatement. I had been there for almost four years (and even interned prior to graduating). It was there where I learned how to write production software, as opposed to how to pass computer science exams. To work as part of a team. To earn the trust of my colleagues and embrace the opportunity afforded by meritocracy. I knew that I was ready for a new challenge, but really wasn’t sure what to expect. Speaking with my soon-to-be-former boss, I lamented that everyone who we currently worked with was so smart, and more importantly, so nice. That they had truly become some of my best friends, not simply coworkers.

He laughed, and in no uncertain terms, told me that having nice and smart coworkers would be a terrible reason for me to stay.

He helped me realize that I should consider working with nice and smart people to be a requirement, not merely a perk. That he didn’t think I’d accept a new job unless I believed that my new coworkers would be equally as likely to become great friends, even if this belief was subconscious. That the world is full of smart and nice people, and that it’d be foolish simply to cling to those who I already knew.

Of course, he was right. In my subsequent years at my next job, I forged a number of meaningful new friendships that I remain incredibly thankful for today. But crucially, this didn’t make it harder for me to leave there when I knew that the time had come.

It made it far easier.