On Monday Location Labs announced the initial release of our Geofence Library for the iPhone platform in private beta.  In many ways we believe this solution will set the standard both for how geofencing services are provided on the iPhone and other smartphone platforms, and more generally how location data streams will be derived from the mobile device.

Wikipedia defines a geofence as a “virtual perimeter for a real-world geographic area”.  In the mobile context, when a mobile device enters or exits the geographic area, the relevant caller (typically a mobile-resident or network-based application) is notified.  Sounds simple enough, but of course the devil is in the details.

There are two key factors that complicate the implementation of a geofence solution in a mobile context.  The first is location technology.  Deriving location from a mobile device is not a new problem, dating back at least to the FCC E911 mandate, and as it turns out there is no single one-size-fits-all solution to this problem.  As with many important engineering problems, there are trade-offs.  The second, and related factor is battery consumption.  For example, GPS, an important enabling technology for mobile location, is a battery hog, typically drawing 300-350 mA on a modern smartphone device (as reference, typical smartphone batteries have a capacity in the 1,200-1,500 mA hour range.)

On Monday, Apple released its latest version of the iPhone operating system, iOS4.  One of the important advances Apple provided as part of this release is the ability to support background processes.  This rectified an important deficiency in the iPhone platform, as other modern competing platforms have supported this for some time (Android, RIM/Blackberry, Symbian, etc.)  It is also essential for supporting a geofencing capability.

The iPhone provides two separate capabilities relevant to the problem of background location access and geofencing.  The first option, available in all versions of the iPhone operating system, is the standard location service.  This is a callback-based API that will notify the caller when location changes based on configurable accuracy and distance change filters.  The particular location technology used by the underlying OS is determined by Apple, and may involve GPS, WiFi triangulation or cell/sector triangulation.  The second option is the newly introduced “significant change location service”, which is a low-battery consumption option that presumably updates only on cell/cell-sector change, and will report even if the application has been suspended.

As it turns out, the iPhone significant change location service is simply not adequate for geofencing applications.  In in-house testing on 3G and 3Gs devices, we see notification delays of up to multiple hours.  It appears that Apple is too conservative here in terms of battery consumption.

A second, extreme approach would be to run GPS continuously (this can be accomplished using the standard location service with optimal accuracy settings.)  Of course, if GPS runs continuously, you can trigger notifications very promptly when a geographic boundary is crossed.  Along with this extremely low trigger latency behavior comes dramatic battery consumption which renders the battery drained within less than six hours, depending on the health of the battery and other service use.

Location Labs has taken a significantly more sophisticated approach.  With the iPhone, we employ a combination of techniques and heuristics involving both the standard and significant change location services, intelligent interaction with the iPhone backgrounding and suspending logic as well as local awareness of proximity to the geofence boundaries.  Together these allow us to offer a high quality firing latency guarantee (measured in minutes) while keeping impact on battery life to a minimum.

The release of our Geofence Library for iPhone is available in private beta, follow this link for details on participating.

- @sahotes