It wasn’t many years ago that, finding yourself with a hankering for a curry in an unfamiliar city you’d two choices; trudging the streets or waylaying a local. Today, with almost any smartphone you can quickly locate nearby eateries, see reviews and ratings, make a choice, and get guided to your meal with turn-by-turn navigation.
Location-based services are an important, integral part of the smartphone experience. The desire to offer users ‘the best’ mapping experience was graphically illustrated in 2012 when Apple launched its own map offering. Enabling developers to take advantage of and extend a platform’s location data is a vital part of the ‘location’ value proposition.
I’ve been asking myself, what’s the state of play when it comes to creating location-based apps? Has the technology reached a maturity where all platforms are equal? If you’re starting with your first location based app, which platform offers you the best tools and the most opportunity to differentiate?
The first question: which platforms? The big three seem obvious: Android, iOS, and Windows Phone. The other major thread in platforms would seem to be HTML5 ─ not only do we have the browser options, both native and third-party on the ‘big three,’ but potentially interesting developments with the likes of Tizen and Firefox OS offering ‘native’ HTML5 apps. So I’ve thrown that into the mix.
Now, having set the scope, let’s find out what’s available.
The foundation of all location-based apps and services is the ability to determine where the user is located. Then, for applications such as navigation and augmented reality, direction of travel or the direction the user is facing are vital pieces of information as well.
1.1. Location technology
Most smartphones offer a GPS chip, usually with the addition of Assisted GPS (A-GPS) to improve the time to a first fix when initially requesting location details. In some platforms GPS-based location acquisition may be augmented with techniques based on mobile network cells and WiFi hot spots. These technologies help improve the accuracy of location information in cities, where buildings may obscure the signals from GPS satellites.
GPS also provides heading information, but only when the user is moving. The need for heading, or more particularly information on the direction the user is facing, is provided by magnetometers and gyroscope sensors.
The key feature of the APIs provided by all the major platforms is that they insulate you from the underlying technology used to acquire location/direction information. As might be expected, given this is the core enabling technology for location based apps and services, the features offered across the main platforms are fairly uniform, as shown in the following table:
|iOS (7)||Android (4.x)||Windows Phone 8||HTML5|
|Location providers||GPS and GPS/Cell/WiFi||GPS and Cell/WiFi||GPS/Cell/WiFi||Platform specific, mainly GPS|
|Direction of travel||Yes||Yes||Yes||Yes|
|Direction facing||Yes||Yes, sensor API||Yes, sensor API||Yes, Orientation API|
|Background tracking||Yes||Yes||Yes||Platform dependent|
All the three main smartphone platforms provide similar location and orientation APIs, in addition to geocoding capabilities. While iOS and Android provide you with explicit access to the GPS location, Windows phone provides location based on a desired accuracy and fix time, which can be manipulated to ensure a GPS location is provided.
iOS is the only platform that incorporates information on heading/facing within the location API; the other platforms rely on separate sensor APIs.
In HTML5 the orientation API may create challenges due to variations in coordinate reporting by various browsers 1. Compared to the ‘big three’ HTML5 has two main limitations: Lack of a ‘native’ geocoding API, for this feature you would have to rely on the mapping service used. The ability to track location in the background is the second difference and varies depending on the platforms’ ability to run HTML5 apps in the background.
It is worth noting that Google also offers some additional location related APIs through its Google Play services (in the Google Android Location API), notably:
- to determine the user’s current mode of locomotion (still, walking, cycling, or in a vehicle)
- geofence feature, which can trigger an event when the user goes outside a defined area.
1.3. Indoor navigation
One of the general limitations of GPS is that it doesn’t work well within buildings. A number of technologies have been investigated to overcome this issue, the principal options are WiFi and Bluetooth based. The advantage of WiFi-based systems is that WiFi hot spots are already common. Bluetooth based systems, such as iBeacon from Apple — which are based on Low Energy Bluetooth (BLE), also known as Bluetooth 4.0 or Bluetooth Smart — offer an interesting alternative, but it is likely to be sometime before there is sufficiently dense, widespread coverage to provide a universal solution. In addition, these Bluetooth-based technologies are not yet integrated into the platforms’ location frameworks, so they aren’t transparent to the location APIs. However, they offer you an interesting avenue for differentiation.
2. Mapping Services
Having obtained your location and orientation information the next step is to add a visualization. The most obvious of these is a map, or closely related representation, such as a satellite or street view.
2.1. The big three
Each of the big three smartphone platform providers have their own mapping solutions for native apps: Apple has MapKit, Android has Google Maps, and Windows Phone HERE Maps (BING Maps was deprecated in Windows Phone 8). Google and HERE also offer their maps for other platforms, in addition to several third-party map providers, more on this later.
2.1.1. Map and related APIs
There is a lot of common ground between the Map APIs provided and the features available for the maps you can display in your apps, detailed in the table below.
There are two main areas of difference between the platform offerings:
- the routing information provided, however in most use cases you will want to pass off routes handling to a navigation app anyway (see the discussion on extended services below).
- offline maps. While this doesn’t directly impact on you as a developer, it could affect your users’ experience when the phone goes offline and is no longer able to obtain updates to map data. While HERE Maps offers users the ability to download maps country by country, Google does it by displayed area and Apple appears not to offer an offline option.
Google has now made its Android APIs for maps a Google Play service. So, if you wish to make use of alternative stores, either to target devices such as Amazon’s Kindle or simply take advantage of other outlets, you need to use another mapping solution. This ‘other’ solution could be the HTML5 Google Maps, a vendor offering such as Amazon Maps API for Kindle, or a third-party offering.
|Apple MapKit||Android (Google Maps)||Windows Phone (HERE Maps)|
|Indoor maps||No||Yes||Not available programmatically|
|Pan and zoom||Yes||Yes||Yes|
|Pitching/Camera (2.5D view)||Yes||Yes||Yes|
|Route details||Multiple routes for walking or driving, with expected travel time and trip advisory notices.||Yes (Google Maps API Direction Services), single route for driving, bicycle, public transport, or walking.||Single route for walking or driving.|
|Offline access||No||Yes – by area||Yes – by country|
|Restrictions||Depends on developer program||Only available as a Google Play API, no Navigation, Autonomous Vehicle Control, or Enterprise Applications, map call limits||Apps for businesses, some API limits|
As an alternative to embedding maps within your apps, you can pass location details to the platform’s Map app to display the user a map. This approach could be ideal where your app has a simple map use case. You can also use the same method to open StreetView on Android devices from your app.
2.1.2. Terms of Service
Apple MapKit appears to be the most flexible offering, with no apparent limitations on the applications you can create using the APIs nor on the volume of map data. Data use is ‘managed by the framework’, but there is no indication that this has created any practical restrictions. The only control is on app types through the Apple Developer programs, if you want to create apps for private distribution to company employees you need to enroll in the more expensive iOS Developer Enterprise Program.
Both Google and Microsoft place similar restrictions on the types of applications that can make free use of map data. If you want to create apps designed purely for use within a business and some specific types of apps (such as those for business asset tracking, fleet management, or dispatch) you’ll need to obtain licences through either the Google Maps for Business or HERE for business service.
In addition, Google only permits free use of its maps in free apps or paid apps that are available in an online store and are “downloadable to a mobile device that can access the online store”.
When it comes to the volume of use, both companies apply similar restrictions.
When using Google Maps you may have to pay, either through a Google console option or the business program, for additional traffic the app generates over 25,000 map loads or more each day, for more than 90 consecutive days.
For HERE Maps on Windows Phone the restriction is on routing and geo-coding requests, where there is a limit of 25,000 within 24 hours from any one app. More than that and you will need to contact the business service.
2.2. Extended map related services
The inter-app communications that enable you to pass a location to the platform’s map app, can also be used to open other location-based apps, such as those for navigation or transit routing. The various options are shown below:
|Guided or assisted navigation:|
2.2.1. Third-party alternatives and options for HTML5 apps
With integrated support for maps in the main platforms it’s perhaps surprising how wide a range of third-party offerings is available. If you are creating a location-based app for HTML5, you will be using one of these offerings. An exhaustive review of the available programs is beyond this articles scope, but here is a list of some of those available:
|Provider||Features||iOS||Android||Windows Phone||HTML5||Pricing (Maps)2|
|Nutiteq||Offline maps, 3D views, map projections for GIS||n/a||Yes||n/a||n/a||Free for OSM data, costs on request|
|Trimble/Spime||Geocoding, POIs, routing, voice guided navigation, overlays, native app access (contacts, calendar, e-mail), monetization||n/a||Yes||n/a||n/a||On request|
|mapIT||Geocoding, POIs, routing, indoor maps, search, geo-marketing analysis tools, traffic (from Tom Tom)||Yes||Yes||n/a||Yes||On request|
You may wonder why I haven’t included Open Street Map in the list. While this service provides tiles, its open source/donation supported status means it may block your app if it breaks the ‘heavy use’ tile download policy. Therefore, the most practical way to use Open Street Map data is either to host it on your own server or use the free Open Street Map data provided by a third-party, such as Nutiteq or mapquest.
3. Augmented Reality
Location apps are increasingly moving away from the map, through the medium of Augmented Reality (AR). With applications, such as HERE City Lens, users are no longer required to figure out what all those lines and pins are telling them, they can simply point their phone’s camera at a scene and have it annotated with relevant information.
In addition to the need for location and heading information, AR requires the ability to paint over a display of the camera viewfinder and project POIs into the viewfinder. With the exception of POI projection in HTML5, all the platforms provide native APIs to enable the creation of AR apps.
In addition there are several third-party tools for creating location-based AR app, these include:
|ARLab – AR Browser||Yes||Yes||n/a||n/a||€199 per platform|
|ARPA SDK||Yes||Yes||n/a||n/a||On request|
|GART – Geo Augmented Reality Toolkit||n/a||n/a||Yes||n/a||Open source|
|Layar Geo SDK||Yes||Yes||n/a||n/a||€7500 per year|
|Wikitude SDK||Yes||Yes||n/a||Yes||Free with watermark, € 99 to € 1499|
With minor variations, developing apps for the main platforms (iOS, Android, and Windows Phone) brings similar features and capabilities to your location-based apps. Only iOS, however, leaves you free to create whatever app you want, free from additional licensing costs.
In most cases the development process, from coding to store, is straightforward. The exception is where you want to target devices based on the Android Open Source Project, such as the Kindle, which use a store other than Google Play. The resulting need to use alternative (non-Android Google Maps) APIs will be something of an annoyance, at least.
Developing for HTML5 adds additional complexity, as a choice needs to be made of a third-party location/mapping service, but achieving similar results to those seen in native apps is entirely possible.
As I mentioned at the start, location–based apps and services are a key value-proposition for mobile devices. Their importance will only increase as the technology powering mobile devices starts to transition beyond phones and tablets into watches, cars, and a range of other smart mobile devices. This, combined with the competition between platforms, means that additional capabilities will continue to be added to the features available to apps, such as the ability to include and manipulate traffic data, and create embed and customize navigation.
- Firefox and Chrome does not handle the coordinates the same way.
- Vendors may offer separate pricing for geocoding, routing, navigation or other services.