When I decided to start to learn Swift and iOS development it was the thought of developing really interesting geo-apps that gave me that push to do so. I already had a background in Geographic Information Systems (GIS) so I understood most of the theoretical aspects behind geo-services. But when it came to coding and knowing what services a developer had available to them that was a different story. When I started to research the topic there really seemed to be a lack of information about it. It existed, but it was disjointed, with no one source really giving me even a majority of the information I was looking for. This is why I decided to write this article, along with several future companion pieces. It is not meant to cover every little detail, but, it should offer enough of an overview that you know where you need to start and how to plan your course of attack in your own app!
This article is about understanding the frameworks and services that you as a developer have available to you. We will start by discussing Apple’s Core Location framework for location services which is the heart and soul of any geo app. Without an understanding of this framework you cannot build location based and geo-services into your app. From there I will move into Apple Maps and the MapKit framework which is what many people will use for integrating features such as maps, points of interest, and directions, into their apps. And then I will go over a number of 3rd party options for developers who need functionality or customization that is beyond, or different, from the scope of what Apple offers.
Core Location
All location based services and apps need to use core location. As the name implies it is the most central element in implementing that functionality. Whether it is accessing the users location, speed, heading, or a number of other key functions, the tasks that involve directly communicating with the users GPS will happen through core location. When you are creating a geo app, or one that will have some location based functionality, setting up core location is where you will start.
Now at the moment I will not go into a detailed example of how to use core location in your app. When I originally started writing this article I wanted to go into much greater detail; basically at the level of a tutorial. But to do it right is going to take more time then I had anticipated, and turning out to be much longer, so I will do a separate article going into greater detail at another date to make sure I address the subject properly. For now I have included links to what are the best tutorials I have currently come across online, at the moment. None of these are definitive but going through all 4 of them should give you a decent idea of what core location is all about.
- Ray Wenderlich: Core location – geofencing
- Hacking With Swift: Requesting location
- Techotopia: iOS 8 Location Application Example
- NSHipster: Core location in iOS8
You can also go to Apple’s Core Location Framework Reference to read up on all the fine grained, technical, details on what can be done with core location. In most cases your use of core location will be to set-up permissions, gain access to the users location, and some geocoding. The rest of what you do will primarily be through MapKit or a 3rd party service. So for today lets move on from core location and talk about Apple Maps.
When Apple released its Maps app in 2012 it was the start of what is still an ongoing project to create its own collection of geo-data and developer frameworks so that its native apps, and 3rd party apps, could more easily integrate mapping and geo-based elements into their projects. It had a bit of a rough start (I will discuss that later), but at this point it has matured enough that, for many developers, it is probably the most logical choice if their mapping and geo-service needs are relatively lightweight. I will start by talking about the MapKit framework and then follow up with a few points about the quality and drawbacks of the service.
The MapKit framework
Using the MapKit framework is no different then using any of the other frameworks. Let’s say you wanted to display a map that showed the users current location. You set up the capabilities for the use of Maps in your project, drag a MapKit view into your storyboard, hook up an outlet to that view controllers file, import MapKit, set the properties that you want to apply to the map, and that is it. Okay so that is a bit simplified but if you did some of the tutorials posted above then you know it is not a very complex process. For a simple task like adding a mapview it is perhaps a dozen lines of code and the bulk of your time will probably be spent working in the storyboard with auto-layout to get it to look just right within your scene.
Using a native Apple framework is obviously going to provide a lot of advantages. Not only is it relatively easy to implement, but for Swift developers they can feel comfortable knowing that Apple will provide all their documentation in Swift, so you won’t have to worry about deciphering Objective-C code to figure out how to make things work. It is also free. Whatever capabilities Apple offers with the MapKit framework you can use until your hearts content and not have to worry about how quickly you will run into a pay wall (there is a cost if your app gets really, really popular but if your app is so popular that it hits that point you should probably be happy your app made it to that level)!
And very recently, when Apple released the beta of tvOS 9.2 it was discovered that there is now going to be MapKit functionality for Apple TV apps! So knowing the MapKit framework in iOS will allow you to translate that knowledge to tvOS apps if you decide that is something that you want to implement. I can see a lot of people feeling rather “meh” about that development, but some people, like myself, are pretty excited for it. In that same vein the fact that there is also a limited amount of MapKit functionality with the Apple Watch, plus tight integration with Apple’s own iCloud offerings give the developer a lot of powerful tools to use maps in a seamless way across multiple Apple platforms. Lets not forget about Mac Apps either. And that is probably MapKit’s greatest strength. If your app is going to cross multiple platforms then having a consistent and very flexible framework for your location based service is a huge advantage to making it all work well.
When it comes to the features available to developers, what you see in the Apple Maps app is largely what you have access to, but there are some exceptions. You do not have access to turn by turn navigation, though you can still get directions. Search is particularly tough to integrate. When searching in the Maps app it will filter through suggestions with each keystroke but MapKit does not allow you to do this. Instead the user has to type their full search and then you can offer a list of suggestions. If you are looking to add a geo-search feature into your app then this could potentially have a negative impact on the users experience if not implemented well. You can also do fly-bys and have access to the 3D maps Apple has created for many cities around the world. I am not sure how many people will find this useful, I know I haven’t come up with a use case for it yet, but it is an option that is there. You also have access to address lookup, satellite imagery, and places of interest.
A few more considerations…
At this point I will address a bit of an elephant in the room about Apple Maps. When it was first released it got a lot of negative press about how mediocre it was relative to Google Maps, and the trouble people had when trying to get directions. Perhaps the most infamous example was when the Australian police discouraged the use of Apple Maps as “potentialy life threatening” due to some directions sending people out into the remote, hot desert when that was not even close to their intended destination. Of course the press went crazy every time someone got a set of these bad directions, in part because they create highly clickable headlines and were probably great for generating traffic to their sites.
Since then a lot of time and money has been spent to improve Apple Maps and the service is drastically better then it was at launch. Those headlines have all but disappeared and it is now just as valid an option as any other mapping service. In the end if you choose to adopt it, or even consider it, that is your choice. Ultimately you know what works best for your app, but for those that might have preconceived notions of Apple Maps I’d at least recommend giving it another look before you flat out dismiss it.
And finally lets talk about where Apple Maps and MapKit isn’t likely to be the right choice for you. If you are looking for enterprise solutions, or creating a project with a lot of custom data, or delivering real-time geodata from multiple sources, as a few examples, then a 3rd party option is where you should probably look. If you think about companies, such as Fed-Ex, DHL, airlines, or transit systems, to name a few, then you can immediately see that geo-data and location based services can quickly elevate to the level of being one of, if not “the” most important assets a company has. In those cases 3rd party options from companies who specialize in geo-data and geo-services are where you should go right from the start. But even less complex cases, such as simply needing to be able to customize the look of a map, or wanting to have direct access to some of the data they are displaying (such as traffic data), are reasons to really look at 3rd party options.
Given that there is a strong chance MapKit and Apple Maps will meet your needs, and since learning core location has put you right on the doorstop of the MapKit framework, there is really no reason not to try it, and see how it works for your application. In 6 months time WWDC will take place and there is a strong chance that they will push these services even further, especially for some of the more specialized aspects of location based services, such as improving indoor accuracy. Learning to use MapKit now means you can be in position to upgrade your applications functionality and be ahead of the curve when new features are released.
3rd Party mapping and geo-services options
There are a few things to note before discussing the 3rd party options individually. First, I have only mentioned the services that I have taken the time to properly read up on and investigate, and in a number of cases, tried out for some of my own applications. There are other options out there if you want to search further, but since I don’t have a lot of knowledge of them, in part because they didn’t seem suitable for my own development needs and where often too specialized, I won’t try to evaluate them. Also, when it comes to pricing details I talk about it as best I can but the pricing structures for many of these services can be complex, or not stated at all. If you do decide to use one of these services do your homework and contact a representative directly to make sure you are not going to find yourself getting hit with a massive bill if your apps usage suddenly skyrockets.
Before proceeding lets talk a bit about how these services monitor usage, and thus how they determine when and how much to charge. When you sign up for these services you register the application that will be using them. You are then assigned a unique “key” that is inserted within your code. This key identifies your app to the servers so that each time a request, or transaction, is made from your app, they can track it. Once you exceed a certain number of transactions (and this can vary from 2,500/day to about a million/month depending on the company and the specific service being used) then you will be billed. This also has impacts on app design, as reducing requests can have huge economic impacts, but that is a discussion well beyond the scope of this article.
Everyone knows Google Maps. It was the first leader in online maps and satellite imagery and has remained that way, so far. And up until the autumn of 2012 it was what iOS used for its mapping services. Developers can still easily download a Google Maps iOS SDK if they would rather integrate Google Map services into their app, so it is still a viable alternative for developers own apps.
The documentation for the Google Maps iOS SDK has been updated to include examples in Swift, so that is a definite plus. Overall, the documentation is detailed and thorough, but an intermediate level of knowledge of Swift and iOS development is probably needed to work through it without too much frustration (if you are a beginner in Swift then come prepared with a lot of patience). Additionaly, because the Google Maps iOS SDK has been used for many years there are other 3rd party resources on the internet that can be consulted when you start running into problems.
With the standard SDK you can add maps, satellite imagery, Streetview images, custom markers, and polylines. There are also additional APIs. The Google Places API provides information on millions of locations available in their database. Google Maps Directions API does just as you would expect, it provides directions. And Google Maps Geocoding is for converting an address into geographic coordinates. So there is a large set of tools available to developers.
Google Maps is however a commercial service so there can be costs associated with these features when your usage level increases. You can take a look at their pricing information webpage. It is not the easiest to decipher but here is a general guideline. If you just want access to their maps, and do very basic things such as showing your own points of interest or a users current location, then you should be able to get away with a standard/free plan, in the beginning at least. As your user base grows even those basic features will start to incur a cost. What that threshold is depends on how many transactions, or requests a user might make in a typical month. You will generally have enough notice that if you start hitting that threshold then you won’t incur any costs or throttling right away; you will have time to transition into a paid plan. In some cases you can increase your quota by setting up a verified credit card on your account. And for features in the Google Maps Places, Directions, and Geocoding APIs they typically only offer 2500 free requests a day so even a small user base could see you needing to pay for these features rather quickly.
From a technical perspective using Google Map APIs is not particularly difficult. But really do your homework on the potential costs and don’t be afraid to contact Google directly if their pricing matrix doesn’t make total sense or seem to fit into what you might have in mind. I have put a strong emphasis on the cost of Google not as a detriment but because so many people are use to thinking of Google services as being free, or very low cost and it might be a bit surprising to some that the Google Maps APIs are very much priced at the level any other professional, commercial mapping service is.
There is a good chance you have never heard of Here, but you have used their services at some point. Here is one of the largest commercial mapping and navigation companies in the world and whos products are used by automobile manufacturers, online retailers, and is the engine behind Bing and Facebook’s mapping services. So it is a true powerhouse and could be argued provides the greatest number of tools, APIs and services of any company out there.
When it comes to documentation showing how to use Swift to integrate their APIs into your projects there is not much. There is a small section that shows how to create boilerplate code to import the APIs into your project, but when you want to get into more specific details it is almost all in Objective-C. That is a big drawback if your only language is Swift and unless you are close to being an advanced Swift programmer I can see someone struggling to really utilize the Here API to its full potential. The documentation is detailed so for someone who does understand Objective-C, or is at least able to interpret it, you should have the resources you need to work successfully with the APIs.
For the iOS SDK “starter” package you get the standard set of tools…maps, satellite images, geocoding, directions and places, which is going to serve most people just fine. The premium package offers some pretty great features including traffic, augmented reality, turn by turn directions, and transit, to name a few. For developers who want to impliment really advanced features or are developing apps for private, in-house use, Here is almost certainly going to be able to meet your needs. Pricing for the iOS SDK is not mentioned on the site and requires you contact Here directly so I am not sure what you can expect to pay. The “starter” package is free for the first 3 months so you have an opportunity to try it before you start spending any significant amount of money.
Your options don’t stop there though. Here also has a set of REST APIs that can be used, and potentially at a lower cost then the iOS SDK (this is just my suspicion as I have not yet confirmed the pricing of REST relative to the iOS SDK). Without getting into a super technical explanation (you can find one here if you want to know more) REST APIs are utilized by fetching the data thru a URL call. The specific data you want is requested by modifying the URL string with a set of predefined constraints. From there you either display the data directly or, more likely, you will have to use a JSON parser to put the data into an array or dictionary, and then process or display it after that transformation. REST APIs therefore require more work on your end to create the code to process and display it so for a new developer this is probably not an ideal choice as using REST is definitely an advanced level topic, especially in the context of Geo-data. But using REST can not only be more economical but also provide you with more flexibility to use the data exactly how you want to. It is an option that you should at least be aware as your skills progress and needs in the future grow.
A slight deviation. As I was editing this article a tweet came across my timeline for this book, iOS Apps with REST APIs: Building Web Driven Apps in Swift by Christina Moulton. Given that I just learned of this book today I haven’t even had a chance to buy it, yet alone read it. But if you are interested in going the REST route then this is will be a valuable asset to Swift programmers.
These guys are the new kid on the block but they are making a big impression. Their key offerings include maps, directions, geocoding, satellite imagery, geospatial analysis and of course a collection of developer tools. Of all the services out there MapBox offers some of the best looking maps I’ve seen (in digital form at least). And with some pretty powerful customization tools you could create some really incredible and beautiful maps that are elevated to the level of art! Most people are not going to need that, but if you want the best looking maps for your app I don’t think there is a service out there that is better then this.
On the developer side they have made sure that Swift is well supported. It looks like most of the documentation has been updated to include examples in both Swift 1.2 and 2.0, and they really seem to be putting effort into continually improving it. A beginner to Swift might, understandably, have some trouble working their way through the API documents and examples, but someone with an intermediate level of Swift knowledge could probably work they way through process of getting a MapBox API into their app with little to no problems.
As far as pricing goes a small app with a user base of 1000 active users or less might be able to get away with using the service for free. But beyond that it will probably cost you to use it, as you can see on the MapBox pricing webpage. This is probably not an affordable option for most apps, which is why I haven’t gone into any further detail about it. And that is a bit of a shame because there a lot of things to like about MapBox, but quality isn’t cheap and geo-services are no exception.
Other 3rd party options
Lets start with Bing Maps. They are discontinuing their iOS SDK so that leaves only their REST APIs as an option for iOS developers now. I do not see any compelling reason to use Bing as you will have minimal support and their pricing structure is the most convoluted of all the services listed. After 15 minutes I still couldn’t figure out an approximate cost. So I wouldn’t recommend it, but it is a thing that exists, in case you wanted to know.
And remember MapQuest? Well it still exists and they seem like they are still paying some kind of attention to their services. The primary reason I mention them is that their APIs for traffic and directions seem relatively good, though outside of the United States I am not sure how extensive their traffic information is. I still take a look from time to time to see what they are up to. If you are developing an app that is focused on navigation or want to focus on traffic I would say take at least take a look. Documentation is not as good as other sites though so that probably makes it a poor option for someone who isn’t an advanced or at the very least an intermediate user. You can see their pricing structure here and they do make an effort to make it really easy to understand what services costs, at what usage levels.
So in conclusion…
Location based services keep growing, more apps are taking advantage of it, and it is only becoming easier for a developer to adopt them and use them in some really powerful ways. And as you grow as a developer you will very likely come to a point in your career where integrating these services, be it a simple map, or something far more complex, is required.
For most developers, using Apples own maps and MapKit framework is going to be sufficient, and in some cases could hugely enhance your application by allowing you take advantage of the use of the framework across multiple platforms with relative ease. For others, a 3rd party service is going to be a better option when customization of maps or the need to analyze or handle custom, and complex, geo-data are required. And though many people might actually want to use a 3rd party service for reasons as simple as making their maps look more beautiful, and to better fit into their UIs design, their is a cost associated with those services, where as, for most projects, using Apples services will be free.
As always if there are any other services you think are worth mentioning, or have other general comments about this post then you can send me a message on twitter to @ManitobaNinja or @Third_beach, or, leave a message on the Reddit thread for this post. These posts almost always have additions and edits based on feedback. If you are interested in additional resources on GeoApps then check out this course being put on by ESRI which is all about developing DIY GeoApps! For those that don’t know ESRI is a leader in GIS and have recently really started to push forward into the mobile scene. It is really worth checking out what they have to offer if you are looking to become serious about developing GeoApps.
Manitoba Ninja 