Chalk up another point for Apple in the ongoing battle for iOS mapping SDK dominance. Via NSHipster, Mattt Thompson writes:
In all of the hubbub of torch burning and pitchfork raising, you may have completely missed a slew of additions to MapKit in iOS 6.1. Namely: MKLocalSearch..., which provides a simple way to find local points of interest. Because of its no-hassle web services integration and tight integration with MapKit, any location-based app would do well to take advantage of it.
With MKLocalSearch, users can search within a geographically defined area of maps displayed within your app. Intuitively, it’s what they'd expect. More specifically, the current map view is treated as a bounding box for the query. MKLocalSearchRequest accepts a natural language search query, such as "hamburgers," and returns an array of MKMapItem objects. Each object contains a record matching the search result, i.e., the name of the establishment, phone number, URL, and address information via the placemark.
Incredibly, it’s free! Other map and search providers charge developers for natural language search queries. Apple provides the service as part of Siri, and despite its continued beta status and endless jokes, more users are making Siri’s natural-language capabilities part of their everyday workflows. As Thompson says:
Perhaps the most counter-intuitive thing about MapKit in iOS 6 is that it's still widely used. Nevermind the "Apple Maps-gate" melodrama, MapKit, even with the introduction of impressive iOS mapping SDKs from Google and MapBox, developers are still using it. When developing with another mapping SDK or geospatial webservice, licensing terms are almost necessarily going to be more limited than what Apple makes available for free. Free is a tough price to beat, and it's all-the-more compelling because there is no worry of going over API limits for tile loading or API calls.
There might be new competition from Facebook, which announced yesterday that it was hard at work on natural-language Graph Search. If you've ever built a Facebook app, you know that formulating semantic statements in the Facebook App Dashboard for how your app will announce activity to users in the News Feed. As Facebook's detailed post on the subject says, all this information will be used to construct a much more detailed semantic network of searchable entities and verb-noun relationships:
The Graph Search engine is built upon highly structured datain the form of a graph, representing hundreds of types of nodes and thousands of types of edges. People, pages, places, photos and posts are all nodes in the graph, each with structured information of its own nature... Someone can like a page, study at a school, live in a city, be in a relationship with another user, check in at a place, and comment on a photo. It is the richness of the data that defines the nature of Graph Search; the system needs to be designed toward understanding the user intent precisely and serving structured objects.
This part of the Facebook platform is "one percent" finished, says the post, but when the other 99 percent comes into play, it will enable Facebook to do search with much less context than before. If the goal of search is to provide "just type" launcher functionality—think the way webOS would find anything with a few keystrokes—then Facebook's search is going to be less rigid and less brittle than its competitors. The post explains the weakness of traditional keyword-based search:
There was consensus among the team that a keyword-based system would not be the best choice because of the fact that keywords, which usually consist of nouns or proper nouns, can be nebulous in their intent. For example, "friends Facebook" can mean "friends on Facebook," "friends who work at Facebook Inc," or "friends who like Facebook the page." Keywords, in general, are good for matching objects in the graph but not for matching connections between the objects. A query built on keywords would fail in cases where a user needs to precisely express intent in terms of both nodes and edges in the graph.
For Apple, search has been a longtime weak point, whether it's egregious App Store search or even the search function in the Mail.app that comes bundled with Mac OS. Apple and Facebook haven't traditionally seemed like competitors, but anyone with powerful semantic search should be feared in Cupertino and elsewhere.
Previous story below: An In-Depth Comparison Between iOS Map Frameworks: Apple MapKit vs. Google Maps SDK
Two developers of geocentric apps say Apple’s iOS MapKit maintains enormous advantages—but that's not stopping both of them from integrating Google Maps into their apps. Find out which one makes sense for your app, and whether you need to implement both.
"When we first got sight of Apple’s maps in the iOS 6 SDK beta at WWDC 2012, we were excited," says Lee Armstrong, developer of the popular Plane Finder app, which tracks planes in flight all over the world. "For years the Maps SDK had not had any new major features and it was looking like Apple would be able to give it some attention."
But everyone knows about the mess that came next: Cupertino was apologizing for the abysmal public response to Apple Maps and Google Android suddenly had a stronger selling point.
Now Google has its Maps back on iOS as a third-party app, at the end of February it rolled out the Google Maps for iOS SDK. The big question for iOS developers now: Better to stick with Apple’s MapKit or risk a jump to Google Maps SDK? And why not integrate aspects of both?
Armstrong says his app’s ratings took a hit as a result of Apple’s new Maps SDK. "We have over 4 million users of Plane Finder and the instant reaction from our users was not good. Many people blamed us for issues with the maps. The issues ranged from missing or incorrectly positioned towns and cities to missing airports. Where we had plotted aircraft on runways previously we were now showing them landing in fields! The reviews on the app store took a dive from 5 stars down to 3 stars. Twenty percent of our daily support emails were also on this issue."
Apple’s problems became everyone’s problems. Who were disgruntled users supposed to blame? "Apple concentrated their efforts on showcase features, like the 3-D flyover view and turn-by-turn navigation," says Bryce McKinlay, who codes the London Transport app, Tube Tamer. "Both of these are actually very well-built features, but they are not things I personally spend a lot of time using. Apple worked hard on this flashy stuff, but neglected some of the basics. The worst and most buggy aspect of Apple Maps is not the maps, but the search feature. Even now, more than six months after the release of iOS 6, searching for a destination isn’t always reliable. Even some of the most common searches in London like "Heathrow Airport" often produce incorrect results."
Google’s Maps for iOS SDK was released to a limited audience in December of 2012. "Even before we released the SDK, developers were pinging us on various social channels asking for it," Mano Marks, Lead Geo Developer Advocate at Google told me. "We got it to them as fast as we could." Devs can make suggestions for future releases on the Google Maps APIs Issue Tracker.
Plane Finder maintains a database of all flights in the air around the world. Quick access to flight data may be the primary selling point of the app, but data accuracy is a key concern for Plane Finder’s user. Armstrong told Co.Labs: "The demand from our users was so great that we were left with no choice but to jump on the SDK the day that Google released it."
McKinlay told me he was eager to use Google’s SDK so he could continue to use Google’s Places API, which his app had been using to locate street addresses, business locations, and points of interest—data which was only available within Google’s own applications until the SDK came out. McKinlay believes Google’s location lookup services are unrivaled. He also says there’s a "perception among users that Google's maps are superior."
"From a developer’s perspective, Google Maps are superior to Apple’s in that the SDK supports 3-D buildings, and users have the ability to rotate and tilt the map view in the app—something Apple doesn’t currently support in MapKit," said McKinlay. He also noted that Google’s SDK offers better hybrid and satellite imagery, a particular advantage for developers using a lot of map overlays.
"Apple's satellite imagery is very variable in quality," said McKinlay. "Some regions of the world have quite good quality images, while others are very poor. For Tube Tamer, obviously we're concerned with London, and the quality of the images here are not great. Besides being ‘blurrier’ than the Google Maps equivalent, for some reason they are very dark and have little contrast, which makes it difficult to distinguish features clearly in shadowy areas. The other issue is the way roads are drawn in the ‘Hybrid’ view. The Google SDK and, in fact, the Apple Maps app draw semi-transparent roads so that the street layout is marked, but you can still see the images underneath. In MapKit, the roads are drawn opaque, which means it's often pretty difficult to see much of the imagery."
"Besides having sharper, clearer, and more consistent imagery, the way Google draws roads onto the Hybrid view is less intrusive," McKinlay says. Google maps shown at left; MapKit at Center; Apple’s Maps app at right.
McKinlay says that using the Google Maps for iOS SDK helps maintain consistency across platforms, and end users are recognized and are comfortable with the styling of Google Maps. The maps they see on their device look just like the maps they see when they use a desktop browser; lines, icons, labels, the color scheme are all the same.
Cross-platform consistency is one reason Andrew Forster says developers go with Google’s Maps. "A developer looking to provide a multi-platform app can provide the same quality and consistency across all platforms that their app runs" by choosing Google’s Maps. Apple has not announced any plans to bring its mapping frameworks to any other platform.
Developers who use Google’s SDK also have access to a variety of other web services that Google provides, including Directions, Geocoding, and Places. That’s something McKinlay says developers who have apps that rely on geosearch services need to consider. "Searching for simple addresses and postcodes works ‘okay’ with Apple's API, but for businesses and points of interest it does not compare to Google."
Google’s Maps SDK also seems to get better more quickly. In the short time the SDK has been available to developers, a number of popular features have ported over from the mature Google Maps web SDK. "Along with big wins like the ability to pan over the International Date Line, we also now have access to terrain view, which has never been formally made available via MapKit," says Armstrong.
The Google Maps iOS SDK has also implemented a robust camera system to allow developers to easily control things like viewing angle and bearing. While some of this is technologically achievable via MapKit, the ability to change camera heading is currently tied to GPS tracking (rather than controlled by the developer).
The Google Maps for iOS SDK isn’t all roses, however. McKinlay warns that Google applies usage limits and quotas to their Places Search API, so if your app gets too successful then you get "punished" for it.
"Google doesn’t currently charge for the Places API, but they do require a valid credit card for access—which gives you a quota of 100,000 daily requests. So you have to wonder if they plan to start charging sooner or later," McKinlay explains. "That 100,000 limit perhaps sounds reasonable, but each user session can generate many requests—particularly when using the ‘autocomplete’ feature of Tube Tamer—and some types of requests count for 10 times the quota each, so it can get used up pretty quickly."
The quote limit is a double-edged sword. Developers of free ad-supported apps like Tube Tamer need to have daily user numbers in the high tens or hundreds of thousands in order to make any serious money on a free mobile app. However, as McKinlay notes, "If you run out of quota they just start denying requests for the rest of the day, which breaks your app—which leads to angry users. You can of course ask them nicely and hope that they'll raise your quota—but all of this is stuff you don't need to worry about with the Apple API." Apple has no limits on access to their location search API.
He also says there are other drawback to think about. For example, working with the Google Maps SDK means developers have to add a third-party, non-open-source framework to their app. This increases the app’s download size. But Google tells me though the Google Maps SDK for iOS increases an application's stored size by approximately 6MB, depending on the features used by the application, it requires less than an additional 2MB to be sent to a user upon download and installation of the application. By contrast, MapKit produces negligibly sized apps because the framework is shipped as part of iOS.
"Subjectively, the current version of the [Google] SDK does not perform as well as MapKit," McKinlay says. "GMSMapView's frame rate is capped at 30fps, which is lower than typical for iOS and results in a slight but noticeable ‘jitter’ effect when panning and zooming the map. Drawing of labels and POIs sometimes lags behind if you pan quickly, even on a fast device like the iPhone 5."
That’s something Armstrong noticed in Plane Finder too when comparing a version of the app with Apple’s maps to a version with Google’s maps. "Overall the Apple maps feel nice and work really smoothly, even with thousands of planes plotted simultaneously."
Perhaps out of all the negatives the developers addressed were the features—or lack thereof—to do with map markers, polylines, and overlays. Tiled overlays are common in apps to display a layer of information, such as weather, crime, and even earthquake data, over a map.
"We can’t do some of our more advanced features in Plane Finder like gradient polylines, chart overlays, or smooth moving planes with animations," Armstrong says. "We have some complex tiled overlays in Plane Finder: These are aviation charts that actual pilots use. With the Google Maps SDK these tiled overlays are just not possible right now."
An example of tiled overlays in Apple’s Maps (which aren’t currently possible in Google’s SDK). In the Apple Maps version (right) of Plane Finder an aviation chart is overlaid directly on the map.
McKinlay agrees that the GMSPolyline and GMSGroundOverlay currently provided in Google’s SDK both offer very limited functionality and flexibility compared to MapKit's Overlays. "Overlays let you draw custom content over an arbitrary area of the map. Tube Tamer uses overlays to show walking routes, paths of buses, and paths of trains between stations, but developers can draw anything they like onto an overlay," he explains. "The ‘tiled’ part means that the Map SDK calls in to the app's code when the user navigates to a particular section of the map, so the app only needs to draw its content when it is needed. This is absolutely essential because when you have an overlay that covers a large geographic area, it would be impossible to draw all parts of the overlay at all possible zoom levels that the user can navigate to."
Something Armstrong also found lacking was support for gradient polylines. "This has been possible in MapKit since iOS 4.0 as Apple added the MKOverlay protocol. We color code the flight path behind the aircraft to give an indication of the height at a certain position." With the current Google Maps SDK it’s not an option.
Polylines in Plane Finder with Google Maps (left) and Apple Maps (right). Note the gradients made possible in the polylines in Apple’s Maps. Plane Finder uses them to show users the altitude of aircraft.
A final issue both developers had were markers in the Google SDK. Currently map markers cannot be animated (like Apple’s "pin drop" effect) or be drug around the map and markers must be configured in advance with Images, rather than UIViews "on demand" as in MapKit.
"This is less flexible and less efficient for apps with a large number of markers," McKinlay says. "In the Google SDK, you create GMSMarker instances which contain both an image and the geographic location for the marker. This means you need to have the image set up at the time you add the marker to the map. This contrasts to MapKit where you create MKAnnotations which contain just the geographic location and text for the marker—no image. When the user navigates to the area on the map which contains the marker, it calls back in to your code and you supply an MKAnnotationView. This can be an image, but it can also be a custom UIView which gives you much more flexibility."
But McKinlay does admit that for simple apps that just have a few markers, the Google approach doesn't make much difference, and it actually makes the programming model a bit simpler. Armstrong agrees, and also notes that in respect to markers, Google’s delegate system is more flexible. "While MapKit will make its delegate aware that an annotation has been selected or deselected, Google allow developers to follow the entire chain of interaction. We're alerted if a marker is tapped, but also when the user taps an empty map coordinate. The SDK also differentiates between taps and long-presses, offering the possibility of additional gesture-based interaction."
However, if an app has a large number of markers (for example, a custom marker, which may use different images for every bus stop in New York) Google’s approach becomes much less practical. "In this case it's much better if you can create the marker images on demand, when they are needed," McKinlay says.
Both McKinlay and Armstrong also say that since Google’s Maps SDK is so new the code is less mature, which means more bugs. "That said, Google are fixing any bugs we log into their bug tracker very quickly," notes Armstrong.
Armstrong points out that the community around a mature SDK is usually larger and more knowledgeable. "The MapKit maturity is important to us because there is a great resource of websites, forums, and peers to turn to if you have any issues. Because it is a very commonly used API there are a lot of people to turn to. We have used Apple themselves to help out with some issues. With Google Maps there are only a small numbers of developers pioneering implementation so we don’t get this."
McKinlay agrees: "Because it's built in to the iOS SDK, it's quick and easy to get up and running. Adding a map to an app can be as simple as dragging and dropping it into a view in Xcode's Interface builder. And because it's part of the iOS SDK, apps using MapKit will most likely keep working with future versions of iOS with little or no effort on the part of the developer."
That’s another point many developers note: longevity. When you stick with Apple’s frameworks you know they’ll be around in the future. There’s no need to rely on or hope that a third party will keep their frameworks up to date. For the most part, Apple’s Maps work across most iOS devices and iOS versions with little effort needed from the developer.
"The fact that annotations in MapKit are UIViews also means that animation and other effects can be applied easily using Core Animation, which isn't currently possible with the Google Maps SDK approach," McKinlay says. He also points out that MapKit has some other handy features that Google’s SDK currently lacks, like "Follow user location" and "Follow with heading" modes. "MapKit provides a button that automatically moves the map to follow the user's location, and rotates the map according to the compass heading. This is very helpful for pedestrian navigation. It is possible to implement this manually in Google’s SDK, but it adds extra development time/effort."
One obvious problem with MapKit is that improvements are tied to iOS releases, says Armstrong: "Developers won’t see any new features until the next iOS release, which is usually on a 12-month cycle." Google on the other hand has released three updates to its Maps for iOS SDK since it first launched to a limited developer pool in December.
Apple’s maps are also less complete than Google’s. Armstrong says there are still issues with small villages marked on maps when at city scale, making for a noisy image; in other instances, some airports still don’t show up. He says Apple has been responsive to user reports to fix these issues.
It’s not that simple. There are big problems with Apple Maps: poor quality satellite imagery—McKinlay calls the images of London "dark and washed out"—plus those intrusive overlays in hybrid view, plus search that feels like it’s alpha at best, and what you have is a very difficult decision between two seriously imperfect frameworks. And it matters which one you pick, because it matters to users: Miss on a crucial geo-feature and people are going to stop using your app. When it first launched, Apple Maps was the reason I almost left the iPhone all together.
Plane Finder uses a dual-mapping system in the app. Users can select which type of maps—Apple’s or Google’s—they want to view in the app and readily change back and forth between them. Armstrong says he doesn’t really recommend following suit.
"When we first started implementing the Google Maps SDK we thought it wouldn’t take long at all," says Armstrong. "It turns out we had to do a major refactor of the application to support both at the same time. Also if we implement a new feature with a new marker type we need to essentially write the code twice!"
To many developers this might sound crazy, but Armstrong explains that if you want all the benefits of the easy-to-use tools in MapKit and the data sets in Google’s Maps, you have to use both.
"There were a few reasons we chose to implement a dual mapping solution. The first was where we couldn’t do everything we needed on the Google Maps so had to keep Apple Maps, otherwise we would be removing features from our app (such as advanced overlays and gradient polylines)! The features we would have to remove would take our app back a year or so in development and we would also have a backlash from our user base," he says.
"The second reason was the stability and performance. As Google’s Maps for iOS is still a new framework it had a lot of crashing. This is getting better with each release but we needed a fallback to users contacting support. Apple Maps are also much faster as there are methods that allow geospatial queries to the map to get at certain data very quickly, these are not in Google Maps yet so there is a definite lag to the Google Map for us."
For Armstrong, dual-coding was a necessity to keep his users happy. With an existing app developers are stuck between a rock and a hard place. If you don’t dual-code you may have to compromise on features you would need both maps to implement. But especially if you’re building a new app, it can be defeating to have to do your maps features twice over, so which one should developers choose?
McKinlay and Armstrong both say that after a full account, Apple’s MapKit is the first choice—especially if you’re a beginner. But that hasn’t stopped either of these developers from implementing Google Maps.
"This is the simplest in terms of a drop-in solution and there are lots of tutorials on the Internet and books for getting started," says Armstrong. "At this point in time only pick Google if you or your user base will require Google Map tiles below." An example of an app that he says would require Google tiles is something like his other app, Ship Finder. Like Plane Finder, Ship Finder lets users track ships on their voyages. An app that tracks ships benefits from detailed images of the coast—a feature he says Google clearly wins at.
"Search is Google's forte and it's very obvious in this case," McKinlay says. Search is the reason he started playing around with the Google Maps SDK and why he wants to transition Tube Tamer over to it as soon as it’s feasible.
Note the heavily detailed coastline in Google’s Maps and shipping routes (left) versus Apple’s.
"I’m pretty eager to migrate Tube Tamer to the Google Maps SDK—both because it would allow us to significantly improve the location search feature, and because I think the majority of users do prefer Google Maps. But due to the limitations in the current version I am not able to migrate just yet, at least without a lot of sacrifices. I'm keeping a close eye on each new version of the Google Maps SDK and plan to integrate it as soon as the required features and fixes are there."
However, Armstrong adds that MapKit only wins for now: "Ask again in six months’ time and that opinion may have changed."
[Image: Flickr user Stefanie Seskin]