How to Implement Geolocation Without Draining Your User’s Battery

Geolocation is a process that, if done incorrectly, can cause a major strain on a device’s battery. If your application is unnecessarily caustic to battery life your user will become dissatisfied, leading to uninstalls and bad reviews. Conversely, minimizing battery usage will give users more time on their device, which also increases the amount of time your app can be used.

Metova has experience building hundreds of mobile applications. Through this experience we have developed our own battery usage threshold process for geolocation. This guide describes how to make the best of device battery life while maintaining the level of accuracy you need for your location-based mobile app.



Defining Usage Thresholds for Geolocation Services

Identify Your Use Cases for Geolocation

Define How Accurate Your App Needs To Be

Different mobile applications are going to have different use cases. For example, an app that makes restaurant recommendations can probably get by with an accuracy of 200 meters to a few kilometers. An app that helps you find nearby friends, however, should likely have an accuracy within 10-20 meters.

The more precise your location accuracy requirements, the more battery power your application will consume. High accuracy geolocation requires frequent use of the GPS radio to determine location, whereas low accuracy geolocation may get by just fine with occasional GPS polling or network-based location services. If you need to poll for GPS coordinates every 60 seconds, you will quickly drain the phone’s battery.

Even if you have high accuracy requirements, setting appropriate action thresholds will help you maintain a relatively small impact on the device’s battery life. For example, if a user is near nothing of interest, there may be no reason to gain a high-accuracy read of their location. Tactics for high-accuracy low-energy geolocation are described in detail below.

Set Hard Limits For Battery Usage

Ideally, the biggest impact your application has on battery life will be the energy required to power the screen. If a user’s phone loses more than 10% battery power with an hour of moderate to heavy use, they will start asking questions.

Long-running automated tests can track how much energy is consumed on a device while your application is running. Identify your target devices and determine what battery usage is acceptable for you and your users. Mobile app developers can run automated tests against specific device models and report their findings. If you find that your application requires more power than desired, you will need to adjust your action thresholds.


Set Action Thresholds

Recognize When The Device Is At Rest

Monitor whether the device has made a significant change in location. This can be accomplished in a few ways:

  • While regularly polling for the GPS-reported location, record the last few reported locations. If the device location has not changed for several minutes, begin polling less frequently until a location change is detected.
  • Also while polling for the GPS-reported location, analyze the reported speed of the device. If a user is in a car, you can make simple calculations using GPS-reported speed to determine how frequently or infrequently to poll. You could, for example, decide to increase polling frequency as a car accelerates to ensure you maintain a location accuracy between a few hundred meters and a couple of kilometers.


  • If the device has connected to a WiFi network, there will be no significant location change until the device disconnects from the network. There are some edge cases, such as city-wide WiFi networks, but WiFi state changes are generally useful for detecting movement within a few hundred meters.
    • Note that a WiFi signal strength change is a terrible indicator of device movement. Simply rotating a device or moving it a few inches can oftentimes result in a significant signal strength change.
  • Determine if the device has connected to a different cell tower ID. Depending on where your user is located, this may allow you to detect movement within a few city blocks or within a few miles.
  • Determine if the device is charging and otherwise idle. While a charging battery is typically a great time to demand more energy usage from a smartphone, detecting location changes while the phone is sitting on a night stand may not prove useful.
  • You can provide options in your app to allow advanced users to adjust geolocation strategies. For example, users can specify times of day, polling frequency, and other attributes. A user might specify that connecting to a Bluetooth A2DP radio in their car should increase the GPS polling frequency, because it’s safe to assume the device is typically moving if connected to the car.
  • Finally, you can gather analytics on user behavior. You may find that users are getting the most value from your app in unexpected ways, or that certain geographic areas have more or less device movement than anticipated. Perhaps even the time of day, you might find, should cause you to adjust how frequently you poll for location updates.

Recognize When Other Apps Are Doing The Work For You

Most major mobile platforms will share geolocation information at the operating system level, meaning any application that is listening can receive location updates requested by other applications. You may find that other applications on your users’ devices are already polling for geolocation data. Using this shared passive source of geolocation information will minimize battery drain.

Back Off When The Battery Is Low

Even if your app is causing significant battery drain, you don’t want to be the app that causes the phone to shut off. Have your app check for location updates less frequently — or not at all — if the battery level falls below 30%. Once the operating system starts notifying the user of a low battery (which typically happens between 15-20%), the user will blame the drain on any app that continues to run full-throttle.

Consider Non-GPS Alternatives for Low Accuracy Requirements

Some mobile applications only care about a user’s rough location: something on the order of “am I currently near Chicago?” For such a low accuracy geolocation requirement, GPS polling can be overkill. WiFi location or cell tower location can work for this type of use case.

In some cases, Internet Protocol (IP) address geocoding — the process of mapping a device’s IP address to a real-world location — will be good enough for finding the coarse location of most users. In the event that it is not, your application can provide a way for users to override the reported location with a location of their choice.

Consider Short-Range Communication For High Accuracy Requirements

For extremely high accuracy geolocation requirements, you’ll need to look beyond GPS and the other aforementioned geolocation methods.

If your application needs to detect a user’s location within a few meters, Bluetooth Low Energy (BLE) is an option on most new smartphones. Bluetooth LE beacons (or iBeacons) are small low-cost devices which broadcast a small amount of information to any listening mobile devices, making them accurate indicators of a user’s location. Companies like BKON provide not only Bluetooth beacon hardware but also a platform for managing and interacting with beacons.

Near-field communication (NFC) is a possibility if you need to identify the exact location of a device. NFC radios typically have a range of a few centimeters, making them ideal for secure payments and other applications which have strict requirements around the exact physical location of a mobile device. Other NFC applications include using a smartphone to unlock doors or desktop computers, sharing information securely between two phones, and triggering other application behaviors when a phone is placed directly on top of an NFC tag.


What GPS Usage Thresholds Are Right For You?

The above technologies and behaviors can apply to a variety of mobile application use cases. Metova can help guide you through setting your application’s action thresholds.


Dave Lane
Dave Lane