Directions and Disintermediation

Apologies for a double-post to iDevBlogADay, but I didn’t want to hit the wider audience with two straight anime/manga-related iOS blogs, and I was way behind on entries for the first few months of the year anyways.

With WWDC and presumably iOS 6 approaching, John Gruber looks for obvious gaps in iOS to fill, and in Low-Hanging Fruit, he doesn’t report many. Following on reports that Apple will switch from Google to an in-house Map provider, he writes that while controlling such an essential functionality is crucial, the switch has to be flawless:

This is a high-pressure switch for Apple. Regressions will not be acceptable. The purported whiz-bang 3D view stuff might be great, but users are going to have pitchforks and torches in hand if practical stuff like driving and walking directions are less accurate than they were with Google’s data. Keep in mind too, that Android phones ship with turn-by-turn navigation.

This was an interesting graf to me, because Gruber usually gets the details right, and this time he’s pretty far off.

Start with “users are going to have pitchforks and torches in hand if practical stuff like driving and walking directions are less accurate than they were with Google’s data.” That’s a fundamental misunderstanding of what the iOS SDK provides. Neither Map Kit, nor any other part of the SDK, provides directions. Map Kit only provides map tile images, and a “reverse geocoder” that may be able to correlate a given location to a street address or at least a political region (city, state/province, country). There’s nothing in Map Kit that knows that a yellow line is a road, a blue polygon is a lake, a dashed line is a state or country border, etc. More details in my write-up of writing Road Tip and my Bringing Your Own Maps talk from 2010, but the long-and-short is that any app that provides directions has to be getting its data from some source other than Map Kit, probably a web service hosted by Google, MapQuest, Bing, etc.

I also did a little research to see what the Android API for this stuff looks like, assuming it was easier, and was quite surprised to see that it’s not. A DrivingDirections class was apparently removed after Android 1.0, presumably due to the fact that implementing it required third-party data (TeleAtlas, NAVTEQ) that Google wasn’t in a position to redistribute for free. The suggested workarounds I’ve seen are all to either license a third-party directions API (embedded or webservice), or to make a specific request to and scrape the result as JSON… in other words, to use Google as the directions webservice and not worry about the terms of service. I only spent about 15 minutes looking, but it didn’t appear to me that getting directions is any easier for Android developers than it is on iOS. So while Gruber notes that “Android phones ship with turn-by-turn navigation”, that seems to be a user feature, not a developer feature.

So, on the one hand, third-party apps probably won’t change right away, because they haven’t counted on iOS for their directions anyways. But maybe that’s an opportunity: if Apple controls its own data, maybe it could offer an easy-to-use directions API, consisting of easy Objective-C calls rather than JSON or XML parsing like webservice clients have to do now.

There might be a licensing snag too: using Map Kit today means that developers are implicitly accepting the Google Maps terms of service. If iOS 6 switches providers, the terms presumably change as well, and I wonder how that would be handled. Would creating a MKMapView magically default to the new Apple maps in iOS 6 (and thereby inherit new Apple terms of service), or would developers maybe have to resubmit or add a credential to their apps to get the new maps?

And taking maps in-house has other interesting side-effects. The other day when I was out with my kids, I searched for “Arby’s” in Jackson, MI and the result appeared on the map as a “Sponsored Link” (I can’t re-create it here at home… maybe it’s only an ad when you’re physically nearby?). The money for that ad presumably goes to Google, a revenue stream that will start to dry up if Apple provides its own business location data when searching maps. We’ve also heard that Siri could hurt Google search if people start performing speech-based searches rather than keying terms into via the mobile browser.

And isn’t this exactly what Google was afraid of, and why they felt the need to create Android? With iOS, Apple is in a position to disintermediate Google. And with Apple’s wrath towards Android, the company may be more interested and willing to do so than it might otherwise have been. Smooth move, Andy.

Comments (2)

  1. I think Gruber was referring to the Maps application, rather than the Map Kit SDK. The Maps app does provide driving, walking, and public transportation directions.

  2. Kris: fair enough, his link to 9to5Mac is written as “Apple is set to switch the back-end data in iOS’s Maps app from Google to its own mapping services”. But if I am inferring that they’d bring the SDK along for the ride, I don’t think that’s a big leap to make; it’s in their best interest to get third-party apps off the Google dependency too.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.