Geofencing

Update August 28, 2015: I had some trouble regarding those geofences later down the road. I wrote it down here.

If you follow me on Twitter you might have noticed, that lately Cat Noone and I talked about an app we’re developing called Iris. Iris is our new project, based on an idea Cat came up with earlier this year. I don’t want to share too much about the app’s purpose at this point. What I’d rather do, is talk about a few observations I have made so far.

Iris is a heavily location-based app. It needs to know when the user enters or leaves certain places. Those places are not hard-coded or in any database that we own. It would simply not be feasible to maintain such a database of our own. So we decided to give a few providers a shot.

The first ones that came to mind were Apple’s own map services and, of course, Google. When we started this, Google did not offer the venue database without actually using their maps as well. This kicked them out immediately. (I believe this has changed since.)

Apple’s own service would do the the trick nicely, we thought. So I implemented the location detection based on MapKit and MKLocalSearch. Which works as good as their mapping services in general — There are places it finds that are correct, others that are basically non-existent (anymore), and others that are just a wrong category. So we decided try a different data provider, namely Foursquare.

They have their own API to search for business information in a certain area. Because we designed our approach manager to be easily replaceable, I only needed to implement a few functions to get this up and running. From what we’ve tested so far, this reliably finds the venues we’re interested in.

Once we’ve found one of those locations, we need to figure out if a user is actually there. In the beginning, I wasn’t sure which approach to follow. After a bit of research (not enough research—more on that in a minute) I figured that it would be easiest if I implemented that on my own. Somehow I instantly dismissed the idea of using the geofencing APIs CoreLocation offers.

So, what I came up with used a CLLocationManager configured to only monitor for major location changes. Only when it detected on of our venues after one of those location changes within a certain range, it would switch to the more precise monitoring. When a user got as close as a few meters, the app would consider this visit a check-in and would change the monitoring mode so that it would only check the location precisely every few minutes to verify if the user is still there.

This worked actually pretty well. But when I implemented it, I didn’t realize that this a) is pretty much what geofencing does and b) that geofencing would actually work for us, as suggested by fellow developer before I began. I was somehow convinced that the geofences would need to be set up upfront and that it wasn’t feasible to set them up on demand. Turns out, I was pretty wrong here.

Of course you can create those geofences on demand. There is an in-depth blog post describing the entire process over on raywenderlich.com. Works like a charm.

I think it’s a good idea to — whenever possible — use those out-of-box frameworks. I was able to delete a bunch of code and clean up our project. Less code means less bugs. I still have to verify that everything does still work as expected, but for now I’m happy I gave it a shot.

If you’re interested in this topic or the app feel free to drop me a line.