At yesterday's keynote to the 2012 WWDC conference, Apple made a number of simultaneous moves in its global chess game with partners and rivals. Let's try and unpack what we can of Apple's overall strategy by analyzing the tactical choices it has made.

The biggest loser from yesterday's announcement, clearly, was Google: the new Maps app will bite into Google's traffic and revenues. Mobile is a huge growth area for search, and "where am I and what is near me" is clearly a crucial part of that.

Make no mistakes, though: this isn't a black-and-white win for users. Cartography is a complex area and the devil is in the details: the quality of realtime traffic monitoring (which Apple apparently intends to crowdsource), the up-to-dateness of road layouts, the speed of the pathfinding algorithm.

Apple has much to prove here, even with the cooperation of license provider TomTom. The current beta of Maps in iOS 6 loses Street View as well as public transport and on-foot routing support, all of which Apple has presumably been unable to source alternative partners for (yet). Apple claims that public transport will be added later, according to Macworld editor Dan Frakes, although we don't know if "later" means before or after iOS 6 launches in the fall. Update: according to several commenters below, walking directions are indeed present in the beta iOS 6 Maps app. As I am not in the developer program (and hence not under NDA), I couldn't check that for myself.

Street View could be more problematic for Apple, though, as Google clearly owns all the data outright. This is, of course, why Google spent so much money outfitting cars and even backpacks with expensive cameras. It remains to be seen how much users will care about this. I fully expect a Google Maps app to appear in the iOS App Store, too, so the users who do care will have something to fall back on; albeit something that isn't at such an advantageous position within the OS (more on that in a second). Moving away from Google as the sole provider of geocoding on iOS also means that developers won't be bound by the separate Google Maps API agreement when their apps use location services and display maps.

Oh, and neither the 3D "Flyover" view or turn-by-turn directions will be available to iPhone 4 users (it's in the small print at the bottom), although users of the iPhone 4 and 3GS will maintain their free and paid options for TBT wayfinding. This is another part of the reason I expect Apple to approve any Google Maps app from Google directly -- to mollify any users who miss the old features.

You'd be forgiven for thinking that makers of third-party satnav apps like Garmin were obvious losers too, particularly based on the chat I saw on Twitter during the event, but that remains to be seen (and Garmin gave TUAW a predictably bullish statement). As long as I'm driving places without 3G coverage -- quite common in rural Wales, which I drive through quite often -- or travel to countries where I cannot afford swingeing roaming data charges -- which is all of them! -- there'll be room on my iPhone for a satellite navigation system that stores maps offline and doesn't rely on a data connection. I suspect I am not alone in this (although Dave Chartier of AgileBits thinks I'm in a minority), which suggests satnav app makers like Garmin, Navigon and TomTom will still have a market, albeit perhaps a shrunken one.

I've seen a few comments along the lines of "of course Apple cut Google out; Apple doesn't like to depend on others" but that line of reasoning ignores that there were also winners in the keynote. Siri has been upgraded, offering deeper integration with Yelp, as well as new links to display results from Rotten Tomatoes, OpenTable, and a whole heap of sports data from a currently undisclosed partner or partners. The new Maps app pulls in data from TomTom as well as, no doubt, other suppliers; world-wide coverage for maps, satellite views and traffic data would be logistically tough for even a company as rich as Apple to assemble alone.

So what we see, then, is an Apple that is picking and choosing which companies it works with. It elevates some to premium positions within the OS, whilst demoting others to the comparative hinterlands of an unprivileged App Store app. Why does this matter? What is Google so scared of here that it invested heavily in an entire mobile OS and then (more or less) gave it away to counter?

It's all about Siri, which is the pivot all this turns around, but not for the reasons you might think. It's nothing at all to do with the voice support.

The importance of data sinks to iOS

As a computer scientist, I was trained to think about data flow through systems in terms of sources and sinks. The source is where the actual search query comes from; in the case of a web search entered into the mobile or desktop version of Safari, for example, it's the search box the user types in. The sink is where the search query is consumed and processed; Google, say, or Bing. Then the search results reverse the flow: the search engine becomes the source, and the web browser's content pane becomes the sink. We're not concerned with this secondary step here, however.

Traditionally, ever since web search boxes appeared in browsers, users have been able to select their own sinks. Safari bucks this trend a little by only offering a restricted selection of Google, Bing or Yahoo! on both mobile and desktop (although there are extensions for desktop Safari that address this). Chrome and Firefox, however, allow users to add any search engine they like. This is good for smaller search players like DuckDuckGo, as it elevates them onto a level playing field with the likes of Google. It also means users can write custom searches for, say, Amazon Kindle book titles in one step. There's a lot of flexibility here for users and site owners. I'd argue that this democracy, this absence of hierarchy, was an essential part of the early success story of the web, too -- that any blogger with a domain name was, in a sense, on a par with the largest media organisations in the world.

iOS doesn't offer this flexibility. Mobile Safari has only the three options on offer, the user can't install any extensions to change that behaviour, and custom web browsers from the App Store are second-class citizens on iOS because all web links in other apps will always fall back to Safari. This makes a search engine's presence in that little list in the Settings app really important to its viability on iOS -- which, if we really are moving to a "post-PC world", is really important to its viability overall.

Sources and sinks: beyond web search

The obvious other source to consider in iOS today is Siri.

The importance of Siri is that is aggregates multiple search engines together, but the user cannot choose which ones; Siri itself selects based on the type of query. So restaurant searches automatically go to Yelp, navigation requests to Maps, general factual lookup to Wolfram Alpha, and so on. TripAdvisor, Navigon, and DuckDuckGo are out in the cold because the list of possible sinks is baked into iOS.

This makes Apple a kingmaker in terms of iOS user's web traffic; it can (and just did) cut off longstanding "obvious" choices like Google from vast chunks of traffic whenever it wants. Siri puts lower-rung options like Yelp on an equal or higher footing than Google's search.

This is what Google is scared of. This is why Android exists -- it's an attempt to keep Apple honest. This is also why Google gives Android away -- it doesn't need to make money on Android itself, it only needs it to have a significant enough installed base to use as a lever against Apple. It's a moat, not a castle.

We can only guess at the terms these partner firms agreed to to get a privileged place on the largest (by traffic) mobile platform. It seems safe to assume Apple secured a good deal for itself, though, and likely applied the same hardball bargaining to its software partners as it does in negotiations with hardware component suppliers. It reminds me of the famous adage that a deal with Walmart can be the best and worst thing a small farmer can do -- the farmer get exposure to a massive market, but at terms strictly dictated by a powerful entity that doesn't have the farm's best interests at heart.

This is the commercial argument as to why we might never see the mooted Siri API. There are technical arguments, too; the level of integration Siri demands makes it hard for third parties to integrate to without risking the slickness of the end product. But technical difficulties are always resolved over time. My weak hunch is the commercial argument is strong within Apple, and it's unlikely that Apple will relinquish absolute control over Siri anytime soon; I certainly don't think we'll see it before iOS 7 at the earliest, now, and (I contest) we might never see it. Like the iron grip Apple has over the App Store, this control brings power of significant strategic value, and I imagine it's loath to give that up.

That all sounds rather negative. I should note that this is, generally, what's best for iOS users. Arguably the single biggest factor in Apple's rise to strength over the last decade or so has been its impeccable taste -- its sense of what people want to see. Siri's deep integration into various search providers is key to it working as well as it does.

Still, I find it hard not to be concerned about the distorting affects Apple's concentrated power might have on the online services market in all sorts of segments. So far, Apple has handed out competitive advantages to chosen partners in social (more on that in the next section), search, mapping, restaurants, and cinema bookings. Who knows which ones come next?

Sources and sinks: the post-PC play

Factory-standard iOS is strongly sandboxed, meaning that applications have very few opportunities to bridge data or settings between themselves. One app can't open a file saved from another; the only way to move data around is copy/paste (text and images) or the Camera Roll (images only). This makes the built-into-the-OS services even more important than they would be otherwise, because they are easily the smoothest path a user can choose to move data from source to sink.

As with Siri, though, Apple has absolutely control over these. Tumblr, for instance, cannot offer the user a "post this link" option via the action button in Mobile Safari. Only services blessed by Apple get into the default sharing options, which is why Twitter and soon Facebook get a competitive advantage over other social networks. Users who prefer more obscure sites -- don't forget about the fans of Google+! -- are left out in the cold.

Users can work around this, of course, but it inevitably feels clunky. To share a link on Twitter on my iPhone 4: tap Share, tap Tweet (slight pause, there, probably because of my older iPhone), and enter some optional commentary. To share on Tumblr (assuming I'm not posting by email): tap and hold Address Bar, pause for the menu to appear, tap "select all," pause for menu, tap "copy" and hit Home. Locate Tumblr app, load it up, select Post, select Link, tap and hold on URL field, pause for menu, select "paste" -- and now I can write some commentary if I want. Like I said, clunky, comparatively speaking.

This isn't just for social network sharing, either. It's inherently easier to add a web page to Safari's built-in Reading List than it is to put it in competing apps like Instapaper or Pocket.

Apps can work around the limitations, to some extent. For example, Tumblr offers a Javascript bookmarklet that accomplishes the same task, as does Instapaper -- although Tumblr's one uses popup windows so it doesn't work very well on iOS. One can also post to Tumblr by email, but that's neither as obvious nor as accessible; the process for adding tags to posts isn't very discoverable, for example. Apps can also pass data around via URL schemes but only if the data sending app is explicitly programmed to connect to a specific receiver app.

Apple could, of course, release an API for this, and allow users to permit apps to add themselves to the Sharing menu. It could also add a "default app" bit in Settings to allow, say, all web links to be opened in iCab, or all mail links in Sparrow. Calls for these things to be added into iOS date all the way back to the birth of the App Store but we're yet to see it. It's perhaps something Apple simply hasn't gotten around to yet, or -- and this is just baseless speculation on my part -- maybe something it's not planning on doing. As with Siri, this is an aspect of iOS that puts Apple into an enviable kingmaker position, and maybe Apple wants to hang on to that control. (It's very possible Apple will make an announcement in the future that makes me look stupid for saying that, but hey: nothing ventured, nothing gained.)

I'd argue this is somewhat more toxic to at least some users than the Siri thing, though. This lack of flexibility, of control, of (dare I say it...) openness feels significant to me when I ponder the idea of using an iPad for the majority of my computing tasks. I suppose, in a way, my iPad never really feels like mine. It's rather more like a games console for apps than a computer, which is (of course) a well-worn simile. This makes me feel uneasy.

I must accept, however, that I am a curmudgeon in these regards -- I've been using computers for almost three decades and I came to OS X after a long spell of using Linux as my primary desktop OS. I like lots of control over my environment. I frequently feel like iOS's limitations get in my way. I miss Alfred and the Services menu and having lots of windows open at once. However, I don't think my feelings on this matter represent those of the majority, and therefore I don't think they spell any sort of doom for the idea that the iPad is the post-PC future of computing.

(I do see problems that I believe stand in the way of the mainstream user moving to iPad, particularly for work rather than play; but that's a subject for another day and another overlong post.)

Wrap up

As our own Dave Caolo said, "Begun, these map wars have." Apple's announcements, in aggregate, speak to me of a company positioning itself strongly against Google -- and unafraid to align itself with numerous smaller partners to do so.

I would prefer to see Apple to move to an iOS model that allows more user configuration of the wiring from source to sink, but that doesn't seem to be on the cards. It's possible that it may surprise us with some extra features when iOS 6 is formally released but that seems unlikely to me because such features would only work with developer support, so WWDC would have been the perfect time to announce them.

As we're entering iOS's sixth major iteration without these customization options, I think there's some reason to believe that such openness is simply not part of Apple's plan for the platform. That weakens it a little bit, in my eyes; but many will disagree.

Photo by Lori C. | flickr cc

iOS 6: On partners and partings, sources and sinks, and the dreaded word "open" [Updated] originally appeared on TUAW - The Unofficial Apple Weblog on Tue, 12 Jun 2012 15:15:00 EST. Please see our terms for use of feeds.

Source