Overland for iOS: a background GPS logger you point at your own server
📌 GPS logger for iOS devices
At a glance
- What is it?
- Overland records location, motion state, steps and battery in the background on iOS, queues the data locally while offline and posts it in batches to an HTTP endpoint of your choosing. Its most interesting setting is the send interval, which can be as coarse as 30 minutes or switched off entirely.
- Who is it for?
- Adopt Overland if you want to record your own movement history and control where the data goes, since the app works with eight named backends including self-hosted ones and a batched send interval that handles offline periods. Keep away if you need turn-by-turn navigation or satellite imagery, because the scope is logging and nothing else.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Objective-C, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A logger that batches to a server you choose
Overland is a GPS logger for iOS that tracks your location in the background and sends the data to a server of your choosing. The description of what it tracks is a short list: GPS location, motion state with walking, running, driving, cycling and stationary, steps, and battery level.
The batching behaviour is the feature that makes it usable rather than merely interesting. The app gathers data even when the phone is offline, and the data is sent to the server in a batch at an interval set by the user. That is the right architecture for a tracker, because a phone in a rural area or on a flight will not have a connection, and a logger that dropped points when the network was down would be useless.
The transport is plain HTTP to an endpoint you configure, and the README lists eight services the app works with. Compass is a self-hosted PHP app built by the same author specifically to save and review data from this app. Wayfinder is a self-hosted app for Overland. Dawarich is a self-hosted alternative to Google Location History. Reitti is a self-hosted personal location tracking and analysis application. PureTrack is a service for tracking lightweight planes and gliders. Open Humans is a service for tracking your data and sharing it for research purposes. Geomanic is a free hosted service with country statistics, travel analytics and tax residency day counts. And Home Assistant is supported through its OwnTracks format.
That list is the interesting part of the design. Only Compass is built by the same author, and the rest are either self-hosted or third party, which means the app is deliberately not tied to one backend.
The project is Apache-2.0 licensed, the primary language is Objective-C, the default branch is main, the last push was on 2026-10-19, and the single tagged release is v1.3 from 2024-05-13.
The Tracker screen is a status readout, not a map
The Tracker screen is where you control whether the app is active, and it shows some basic statistics about what the app is doing. It is also where you start and stop trips.
The readouts are worth reading individually, because they tell you what the app is doing rather than what the map shows. Age is the age of the last location point reported by the operating system, which gives a sense of how much data you are recording. Location shows the latitude and longitude, the accuracy and the altitude of the last update. Speed shows the speed of the last update, and below it the activity type, such as stationary or driving. Duration and Distance appear when a trip is active, and Icon indicates the mode of transport that will be written for the trip record.
Two of the readouts are about the queue rather than the position. Queued shows how many location points are stored in the internal database and not yet sent. Last Sent shows how long ago the last batch was successfully sent to the server. And Send Now is a button that sends the queued data immediately.
The trip model is simple. Start starts a trip record and Stop stops it, and after stopping, the trip record is written to the database and sent to the server along with the location points. So a trip is a labelled span of location data that becomes its own record once ended, rather than something the server has to infer from gaps in the points.
The screenshots in the repository are of the Tracker screen and the Settings screen, so this is a data tool rather than a visual one. There is no map in the feature set at all, which is a deliberate narrowing of scope that a lot of trackers do not make.
The send interval is a battery control, not a politeness setting
The Send Interval slider controls the interval at which the app sends data to the server, and the range is from 1 second to 30 minutes, with the rightmost option being off, which disables sending entirely.
The reasoning the README gives is about power. Using the network connection is a huge source of battery drain, so you can save battery by sending infrequently. And the off setting is useful when you know you do not have a network connection, such as during flights, because the data is queued up and will be sent once you enable sending later.
This is a well designed control, and the reason it matters is that it separates two concerns that usually get tangled. How often the phone records a location is governed by the CoreLocation settings, and how often it talks to the network is governed by this slider. A user on a long trip who wants detailed tracks can record every point and upload once an hour, and a user who cares about battery can record rarely and upload often.
The two other tracker-level settings are on the Settings screen. Server URL is where you set the endpoint the app sends data to, and you can also configure a device ID which is included in each record and an access token which is sent in the HTTP Authorization header. That access token is the mechanism for authenticating against your own server, and the device ID is what lets the backend tell one phone from another.
Tracking Enabled is a global switch. When it is off, the app stops requesting location updates and does not record or send any more data, which is the setting to reach for when you want the app installed but dormant.
Continuous, significant, or both, and what each costs
The iOS Settings section is where the app exposes the CoreLocation API, and the README is explicit that these are meant to give you direct control over how you want the operating system to deliver data to the app. The app ships with an Objective-C implementation and a Podfile, and the point of the settings section is that you do not have to accept Apple's defaults.
Continuous Tracking Mode has three options. Standard requests continuous location updates in the background, and the README says to use it if you want to be able to draw detailed tracks of your travels. Significant Location registers for significant location changes, which are triggered for example when you move to a new cell tower or when your nearby visible wifi access points change. The README is candid that it is not an exact science and may be triggered more or less often than you expect. The result is much less data collected and barely any noticeable battery use. Both requests both types of updates.
That contrast is the single most consequential decision in the app, and the framing in the README is right: the difference between Standard and Significant is not a quality slider, it is an order of magnitude in data volume and battery.
Visit Tracking enables visit tracking, which records an update when the phone gets to a new location after about 3 minutes, which is a good middle ground for a coarse record of where you have been.
Desired Accuracy sets the desiredAccuracy property of the location manager, and the README stresses that it is only a request for the general level of accuracy and not a guarantee. Best uses the most battery and gives the highest accuracy. Setting it to 3km saves the most battery and results in infrequent location updates.
Activity Type is a cue the location manager uses to determine when location updates may be automatically paused, and the Boat option is only available on iOS 27 and later.
The background indicator setting, and the repository layout
The last CoreLocation setting has a specific purpose. Show Background Location Indicator, set to Always, causes the location indicator in your iOS menu bar to be activated whenever the app is tracking your location. The README links a post on the Apple forums explaining why: with the visible indicator, your app is more likely to continue to receive data in the background.
That is a workaround for an operating system behaviour rather than a feature, and the fact that the app surfaces it as a setting is a good sign of how closely it tracks iOS behaviour.
The repository layout shows an Xcode project with a few things worth pointing out. There is an Overland.entitlements file, which is where the background location modes are declared, and an OverlandLiveActivity directory, which means the app has a Live Activity implementation for showing trip state on the lock screen. There is a GPSLogger directory, which is likely the shared framework holding the location logic, a Fonts directory, an Images directory, a Screenshots directory and a ci_scripts directory for continuous integration.
There is also a Podfile and a Podfile.lock, so the project uses CocoaPods, and a PURCHASES.md file, which suggests in-app purchase handling for features beyond the free tier.
On the iOS side, the app is a native Objective-C project rather than a cross platform build, and the Android version is a separate project at the same website. So the two platforms share a protocol and a backend ecosystem rather than a codebase.
Where Overland for iOS is the wrong choice
The first wrong case is a user who wants a map. There is no map in the feature list, no route planning, no geofencing interface, and no place search. The app records and uploads, and reviewing the result is somebody else's job, whether that is the Compass dashboard, Dawarich, Reitti or your own server. If you want to look at your track on your phone, this is not the app.
The second is a backend you have not chosen yet. The app needs a server, and while eight are named, using one of them means your location history lives on someone else's server, and several of those are small projects with their own stability. Geomanic and PureTrack are services, and the self-hosted ones are software you have to run, patch and secure. The app is half of a system and the other half is your problem.
The third is a device that does not meet the requirements. The activity type option Boat needs iOS 27 or later, and the whole app depends on background location delivery, which iOS restricts aggressively. An older device, or one with aggressive battery settings, will not record what you expect, and the Age and Last Sent readouts are how you find that out after the fact rather than before.
The fourth is a team that needs a shared or enterprise arrangement. This is a personal tracker, with a single device ID and a single access token configured in settings, and the trip model is one user's trips. There is no user model, no shared vault, no retention policy and no audit trail. If your requirement involves other people or an employer's data, you need something built for that, and the licensing and operational questions are different.
The alternative worth weighing is the OwnTracks format, which Home Assistant already supports and which the app's data is compatible with. If you already run Home Assistant, that integration may be all you need, and it gives you history storage and a map in one place without running a separate backend.
Editorial conclusion
Adopt Overland if you want to record your own movement history and control where the data goes, since the app works with eight named backends including self-hosted ones and a batched send interval that handles offline periods. Keep away if you need turn-by-turn navigation or satellite imagery, because the scope is logging and nothing else. Before you set it up, read the Continuous Tracking Mode section in the README, because Standard and Significant Location differ by an order of magnitude in data volume and battery use, and note that the app requires iOS 27 for the Boat activity type option while the last tagged release is v1.3 from 2024-05-13 and the last push was on 2026-10-19.
Frequently asked questions
What does the Overland iOS app track and where does it send the data?
It tracks GPS location, motion state such as walking, running, driving, cycling and stationary, steps and battery level, and sends the data to an HTTP endpoint you configure. The README names eight compatible backends, including the self-hosted Compass, Wayfinder, Dawarich and Reitti, plus PureTrack, Open Humans, Geomanic and Home Assistant through the OwnTracks format.
How does Overland handle being offline?
The app gathers data even when the phone is offline and stores it in an internal database, and the Queued readout on the Tracker screen shows how many points are not yet sent. The data is posted in a batch at an interval you set, and the Send Interval slider can be set to off, which is useful during flights, with the queued data going out once you enable sending again.
What is the difference between Standard and Significant Location in Overland?
Standard requests continuous background location updates, which is what you want for detailed tracks of your travels. Significant Location registers for significant location changes, such as moving to a new cell tower or nearby wifi access points changing, and the README says it results in much less data collected and barely any noticeable battery use, though it is not an exact science.
How do I set up Overland to send to my own server?
In Settings, tap Server URL to set the endpoint the app sends data to, and you can also configure a device ID which is included in each record and an access token which is sent in the HTTP Authorization header. A self-hosted backend such as Compass, built by the same author, is one option, or you can write your own that accepts the same HTTP payload.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/aaronpk-overland-ios)Was this useful?