Apple resurgent – thoughts on WWDC

Today’s WWDC keynote was a sign of a renewed swagger on the part of Apple, whose executives seemed to relish the deluge of new product announcements they unleashed on developers and on their customers. In the process Apple established or strengthened its competitive positioning against two major foes – Microsoft and Google – while opening itself up in unparalleled ways to developers. Today’s announcements may come to be seen in the same way as Steve Jobs’ original launch of Mac OS X, in that it lays the groundwork in several areas for years of future Apple products.

The demotion of Google continues

Two years ago at WWDC, Apple removed erstwhile close partner Google from the iPhone in two significant areas: as the backend provider for the Maps app, and in the form of the pre-installed YouTube app. But Google’s last major bastion on iOS is its position as the default search engine in Safari, and it’s much harder to remove there. In the sense of typing a query into a search box or address bar in a browser, hitting enter and being presented with a screen of blue links, Google is unrivaled, and Apple knows that. But it has slowly been inserting itself between the user and that search box over the last couple of years, and today’s keynote provided further evidence of Apple’s pre-empting of the Google search on both iOS and OS X devices.

Apple’s more subtle disruption of the user-Google relationship began with the launch of Siri, which began to address some users’ queries without an explicit search, and which uses Wikipedia, Wolfram Alpha and Bing, but not Google, as underlying search providers. And it has continued since then, as more third party services have been layered into Siri, pre-empting the Google search for movie listings, restaurant reservations and sports scores. Today’s keynote added Spotlight search to the list of places where users will now find answers to their queries without the classic search box experience, thus further inserting Apple between users and Google.

This is potentially significant for Google, for which the US continues to be easily its single biggest and most lucrative market, and for which mobile is increasingly important. To the extent that iPhone users, which make over 40% of US smartphone users, start using Apple and its tightly integrated third party services instead of Google, for search, that’s pretty bad news. That isn’t, of course, why Apple is taking these steps, but it’s an unpleasant side effect for Google. And a great way for Apple to participate in the search business without having to match Google in the page-of-blue-links business.

A device for every need, not one device for every need

Apple also set out a vision of cross-device integration which is very different from Microsoft’s. Microsoft’s vision of integration can be seen in a couple of different ways: on the one hand, the continuing false claim that the Surface line of tablets is a no-compromise device, combining tablet and laptop, which I talked about previously here. But on the other hand, Microsoft’s approach to integrating the operating systems it sells for three categories of devices: smartphones, tablets and PCs. There are several layers to this work of providing integration between these different form factors, and I’ve illustrated them in the diagram below:

Integration layers Apple and Microsoft

These layers comprise those which are developer-centric (shown at the bottom) and those which are user-centric (shown towards the top). The middle layer combines elements of both. I find it interesting to look at the layers Microsoft and Apple respectively have targeted. Microsoft has focused primarily on two, the top and bottom layers in the stack, and is now more actively developing a third, the center layer. It began with the common code base (an entirely developer-centric layer) and the user interface at the uppermost level, when it created Windows Phone 8 and Windows 8 both to be touch-led, with a tile-based interface.

Apple, on the other hand, has resisted the temptation to do both the top and bottom layers, eschewing the forced convergence of disparate operating systems both at the code base and user interface layers, and instead focusing on the stuff in between. Thus, Microsoft is focused on making all devices look and feel the same to both users and developers, while Apple is focused on creating a more consistent user experience, even as the underlying code and the interface remain distinct. This was in evidence even in Mavericks and iOS 7, but the philosophy was only ingrained more deeply in Yosemite and iOS 8. The theme of Continuity (not sameness) runs through the new elements of cross-device integration in iOS and OS X, and at the same time there’s really meaningful integration at a device level too, with the ability to share phone calls and text messages between Macs and iPhones in close proximity.

That last item is a great example of what sets Apple’s tightly-integrated hardware/software/services strategy apart from any of its competitors. Even Microsoft, which now makes some of its own hardware in tablets and phones, can’t offer the same degree of integration all the way from Bluetooth LE radios through to end-user services on all Windows devices. Though most of the benefits of Apple’s integrated approach are somewhat transparent to users, this one is much more obvious. But it’s also about cementing the value of iOS and iPhone as platforms with huge appeal to end users because of what they uniquely enable. This will be critical as iPhone growth starts to shift towards conversion from other platforms (notably Android).

At the same time, a more open Apple

Even as Apple is demoting Google as a provider of tightly-integrated third party services, Apple is opening itself up in ways it never has before to loosely-integrated third party services. Consider just the following list of new ways for third-party developers to become more deeply integrated both within iOS and with each other:

  • Widgets in the Today screen in iOS and OS X
  • Extensibility on iOS between applications and within Apple’s own applications such as Photos
  • Opening up to third-party keyboards
  • Opening up the Touch ID API.

Then there’s the increased openness demonstrated by the inclusion (not discussed in any detail) of OneDrive and Box in certain functions in Apple’s operating systems. This is a new Apple. But it also wants to be very clear that, even as it embraces an Intents-like model for inter-app integration, it is maintaining its focus on protecting user privacy and security. The sandbox-to-sandbox sharing it described today maintains the user-centric sandboxing model to protect privacy and security while enabling interactions between apps on a broad basis. Apple continues to put the user first, and it wants to reinforce this concept as a competitive vector against Google.

The one remaining big area where it seems Apple is holding fast on its closed approach is setting apps other than its own as the default apps for key functions such as the browser, calendar, email and maps. Here, Apple’s openness comes to an end.

HomeKit and HealthKit as destroyers of fragmentation

Based on rumors of both features, I wrote about the potential for what we now know as HealthKit and HomeKit here and here. And it seems that I got the concepts mostly right for both products. These products promise to overcome the fragmentation currently in evidence in both these markets with a plethora of devices that don’t talk to each other, by creating a single user interface to control various smart home devices on the one hand, and gather data from a variety of health devices on the other.

The key thing with both concepts is that they’ll be most useful for people who have more than one such device, whether in the wearables or smart home category. If a Nest is the only smart home device you have, the Nest app is probably fine, and if you only have a Pebble smartwatch, the Pebble app is probably fine. But it’s when you start to make use of more than one such device that Apple’s HomeKit and HealthKit will spring into action. That points, though, to an interesting difference between the two. While I suspect many smart home hobbyists (and let’s face it, that’s the state of the market today) will install multiple devices from different vendors, the number of people using more than one health and fitness wearable device from different vendors is probably much lower.

Having said that, I think the impact for someone managing a chronic illness could be profound, as they’ll now be able to gather the data from various devices in a much more unified way that allows them to control their own health monitoring much more easily than they can today. As society struggles with allowing more of its elderly to age in place controlling healthcare costs, HealthKit could enable new scenarios that currently aren’t possible or at least commercially viable for most people.

This leaves open the question of what, if any, hardware we’re likely to see from Apple in the wearables space. I continue to be somewhat skeptical that we’ll see an iWatch anytime soon, for reasons I’ve outlined before. But, of course, HealthKit would be a great repository for data generated by such a device were Apple to launch it, and a lot of people seem to see HealthKit as evidence that an iWatch is imminent. Whether or not Apple launches a single device, though, HealthKit will be necessary for anyone wanting to combine data from such a device with health data from more specialized devices Apple is never going to make. And that’s perhaps why HealthKit makes so much sense.

A new development language as the foundation for the next fifteen years

New development languages are always a double-edged sword: on the one hand, they allow developers to leave behind the baggage of the past, and on the other they require learning something new. Swift appears to exhibit the same characteristics. On the one hand, it’s intended to allow developers to ditch some of the less attractive qualities of what it’s replacing, but on the other it (and Metal) make it harder to do cross-platform development, because iOS will now have even less in common with other platforms. Having said that, the mood in the keynote hall seemed decidedly positive, which suggests developers are inclined to see the upside.

Regardless, though, Apple seems determined to create a common language which may do more to unify its three operating systems (I’m including Apple TV as a third, though I suppose it’s nominally a flavor of iOS). Some of the enhancements will make for easier development and more powerful apps for iOS. But there’s also potential for interesting things on Apple TV too, especially with Metal. This may well set up a big revision for that product line in the fall.

Overall, though, the combination of Swift and Metal feels like potentially as big a shift as when Steve Jobs first introduced Mac OS X as the platform for Apple’s next fifteen years (interestingly, almost fifteen years ago). By recreating the core programming language for its major platforms with a view to the future, Apple itself is dumping some of the baggage associated with past languages and setting the foundation for its own future roadmap, some of which we’ll no doubt see later this year.