I wanted to know exactly when I was in a city. I wanted to remember which parts of it I had explored, which photos belonged to that visit, and how one stop connected to the next. More than anything, I wanted one place that could hold this history without asking me to record every trip manually.

I tried a few different solutions. Some travel apps let me mark countries and cities manually. They produced a nice map, but they did not really show anything more than a list of places I have visited. Apple Photos came closer because it already had my pictures, their dates, and often their locations. Its trip grouping, however, was a bit hit or miss. I sometimes found trips that were missing, split, or joined together in ways that did not match what happened.

For a while, one of the most accurate records of my travels came from Revolut (yes, the neobank). It would track payments made in other countries and estimate when I had traveled. I liked the presentation, but a banking app is not the right place, nor the right tool to keep a record of your life. What if you pay cash? What if you use a card from another bank? What if they remove the feature at some point? You really don’t need many reasons to realize that this is a bad idea.

Each option had some piece of what I wanted. None of them had the whole thing.

This led me to build Travel Log, a private travel journal for iPhone. It receives occasional location updates in the background, figures out the places where I stayed, groups those stays into trips, and builds a map of the places I have explored. It can also go through the metadata of my photos to infer places that I have visited and reconstruct trips from before the app was even installed.

The app is currently in beta for iOS 26 or newer. It works best on Apple Intelligence enabled devices (iPhone 15 Pro or newer), but it can work on any iOS 26 supported device. If you would like to test it yourself, you can join the TestFlight beta. It requires “Always” location access for its main features. Photo access, calendar access, notifications, and iCloud sync are optional. In fact, the app does not require an internet connection and almost all of the features were designed to work primarily offline.

Starting with an imperfect signal

The simplest version of a location journal would record GPS coordinates all day. That would give us very accurate location data, but it comes with two major problems: it drains your battery and iOS requires the app to show a blue location arrow in the Dynamic Island.

Travel Log uses a different part of Core Location called Significant Location Change (SLC). Instead of keeping the app alive and asking for a constant stream of location updates, it registers with iOS and lets the operating system decide when the phone has moved far enough to send an update (Apple says >500 meters, >5 min from the last update, but that’s a minimum. Updates could come less often).

This system enables the most important feature of the app: you truly set it and forget it. There is no start button, no manual recording of trips, no requirement to keep the app open, no visible indicator, no nothing. You install the app, finish the setup, force close it, and go on with your day. In my own testing, the app keeps receiving SLC updates even after a device reboot, without any interaction from the user.

iOS is still in control of background activity and there is no guarantee that this will keep working forever. You can ultimately choose to disable background app refresh, or iOS may decide to stop delivering updates if the app is not used at all.

With that in mind, we end up with an app that gets sparse location updates rather than a detailed route. It may know that I was near my home, later near the airport, and later in another city. It will not necessarily know every road I took between them. That limitation shaped almost every decision that followed.

When iOS sends a location update, the app first checks whether it is usable. Old readings are ignored. Readings with extremely poor accuracy are also ignored. A reading that appears to come from high altitude can be discarded when the altitude itself looks trustworthy. This helps with photos and location updates recorded during flights, although it’s not perfect.

The remaining location is saved as a ping. A ping is simply one observation: a time, a pair of coordinates, an accuracy value, and a few details about where it came from. The app also places it inside one of the hexagon shaped areas used by Uber’s H3 hexagonal grid. Those hexagons later become the exploration map.

Turning pings into places

A single ping does not tell us much. It only means that the phone was there at one moment in time. Travel Log needs to join nearby pings together before they become useful.

The app reads unprocessed pings in the order they arrived and builds what it calls a stay. A stay is a period spent in roughly the same area. If a new ping is more than 3 kilometers from the center of the current stay, a new stay begins. The same thing happens when more than 4 hours have passed since the previous ping. The center of a stay is simply the running average of all the pings that make up that stay.

An important realization is that a lack of pings usually means that the user has not moved to a new location. When you go back to your hotel in the evening for example, Travel Log may receive a location update, but throughout the night it does not receive any new updates. The next update may arrive in the morning when you are already leaving.

When that happens, the app extends your hotel stay halfway into the quiet period, but never by more than 12 hours. That limit matters even more for photo imports, where gaps can be much longer and the app cannot know whether you stayed in one place or simply stopped taking geotagged photos.

At this point the app has turned pings into stays, but it still hasn’t constructed a single trip.

Home is not a circle

Home is the reference point for the entire trip system. A trip begins when you leave your home area and ends when you return. If that area is too small, an ordinary visit to work or the gym becomes a trip. If it is too large, a real journey disappears into home.

My first version used a circle around the location the user marked as home. That sounds reasonable until you look at a real city. Daily life is not circular. In my case, a circle large enough to include the places I regularly visit around Athens also included the airport. A smaller circle excluded parts of the city while still failing to describe its actual shape.

Travel Log now starts with the measured boundary of the built up city that contains the user’s home. The boundary comes from the geographic database already included with the app. If the app cannot find a city boundary, the home area begins as a small circle around the chosen location.

The area can then learn from the user’s routine. A place can become part of home after at least three qualifying returns within twelve months. Each visit must involve meaningful time at the place and a return home on the same day. Airport stops and other transit do not count. This lets an office, a weekly market, or a relative’s house become part of ordinary life without allowing a frequently visited holiday destination to become home.

This learned area is not permanent. If the return pattern disappears for long enough, that place eventually stops counting as home. The area can therefore expand as a routine develops and shrink after the routine ends.

The user remains the final authority. A missed nearby journey can be marked as a trip. A false trip can be marked as part of home. Learned places are visible in Settings and can be removed. Travel Log also keeps homes tied to time, so moving to a new city does not change how an older trip is interpreted.

Working out what belongs to a trip

The user tells Travel Log where home is and can optionally add routine places such as an office or a gym. A stay inside one of those areas is easy to understand. It is classified immediately and it doesn’t get any further attention.

The difficult stays are the ones in between. Three hours near an airport could be a layover. Three hours in a small town could be a lunch stop on a road trip, or it could be the main reason for the journey. Duration alone is not enough. Distance from home is not enough. The places before and after a stay matter a lot.

For these cases, Travel Log can use the on device large language model that Apple provides on compatible devices through the Foundation Models framework. The model receives a short list of stays with their places, times, durations, distance from home, and nearby airports. It then labels each stay as either a destination or transit.

The output has a fixed shape:

@Generable
struct SingleStayClassification {
    var stayIndex: Int

    @Guide(.anyOf(["destination", "transit"]))
    var category: String
}

This avoids asking the model for a block of text and then trying to parse it. The result must contain a stay number and one of two allowed categories.

I deliberately give the model very little authority. It can offer an opinion about an unclear stay. It cannot decide where a trip begins or ends.

Trip boundaries use a much simpler rule: a trip starts when the user leaves their home and ends when they come back home. If there is no home stay between two travel stays, they remain part of the same trip. This handles journeys with several destinations without having to understand the entire structure of a trip.

(This works great for most trips, but it doesn’t properly handle some specific cases. Imagine studying abroad for a semester and going back home for a weekend. The semester gets cut in half and becomes two separate trips. The opposite happens if you take a weekend trip to another city: because you never return to your actual home, the app treats it as part of the larger study abroad trip. This can be fixed with “temporary homes”: places that are still travel destinations, but can also act as the start and end of separate, “nested” trips. This will come in an update soon™).

There are also ordinary rules around the model. A very short stay is usually transit. A short airport stay is usually transit. A stay lasting several days should not remain classified as transit just because the model made a poor decision. If the user corrects a stay manually, the app treats that correction as final.

Apple Intelligence is not available on every device that can run iOS 26. It can also be turned off or still be downloading. When the model is unavailable, Travel Log uses a smaller set of normal rules. The result may be less subtle, but the main app still works.

The limitations of a 3B parameter model

Classification was not the only place where I used the model. I also wanted short trip titles. A trip that says “Boston & NYC” is easier to process than “Boston, Cambridge, Brooklyn, Queens, and every other place recorded during the trip.”

Early results showed why these smaller models need very carefully crafted prompts. I was giving the model way too much information and that led to it adding the capital of the country to the title of each trip. Mallorca became “Mallorca & Madrid” and Thessaloniki became “Thessaloniki & Athens”.

I tried improving the prompt, but prompts alone did not make the result trustworthy. The real fix was a validator. Every important word in the title must now come from the actual places stored in the trip, or from a small list of allowed joining words. If the model names a place that is not present, the title is rejected.

Transit places are also removed from the context given to the model. An eight hour connection at Heathrow repeatedly encouraged the model to put London in the title of a trip to Los Angeles. Removing the airport stay from the prompt worked better than repeatedly telling the model to ignore it.

The app gives the model two attempts before building a simple title from the main destinations.

Giving coordinates a name

“37.1° N, 25.38° E” doesn’t tell you much, but this is what the app has been working with up until now. A travel journal needs to turn coordinates into names such as “Naxos, Greece.” This process is called reverse geocoding.

Apple provides a service for it, and it works well when an app uses it occasionally. Travel Log may need to process tens of thousands of old photos in one import. Sending each location through an online service would be slow, would depend on the network, and would get rate limited.

I decided to include a geographic database inside the app. It is a read only SQLite file of about 125 MB, built from GeoNames, Natural Earth, GHS-FUA, GHS-UCDB, and OpenStreetMap, with Wikidata cross-references for islands. The app also bundles airport data from OurAirports for transit detection.

The database can answer several questions for one coordinate. It can find a nearby city, a neighborhood, an island, a larger metropolitan area, a region, and a country. The app can show the specific place on a stay while using the larger city name for a trip title.

There is a cost here: a larger app download. I think it is massively outweighed by the speed, throughput, and privacy of local lookups. They happen offline and are never rate limited, while Apple’s geocoder remains available as a fallback.

Reconstructing trips from photos

Passive tracking solves current and future trips. It does nothing for the years before the app existed.

Your photo library most likely contains much of that history. Photos usually come with a timestamp and location data. Travel Log can read that information, create historical pings, and send them through the same stay and trip pipeline used for live tracking.

The importer works in small batches and remembers its progress, so it can stop and continue later without losing photos or creating duplicates.

The importer ignores screenshots, photos without a useful location, impossible dates, very inaccurate coordinates, and some high altitude photos that were probably taken from a plane. It also skips shared photos.

Exploring the world but not the sky

The exploration map is the part of the app where I spend the most time. Each accepted location contributes to an H3 hexagon. Over time, the map fills and you see a hexagonal grid that changes color based on how many times you have visited each hexagon.

My first attempt hid every area that belonged only to transit. The intention was reasonable. A location update from a plane should not make it look as though I explored the country below it.

Then a road trip disappeared from the map.

Road trips can produce a chain of single-ping stays along the way. Many are too short to look like destinations, so my first rule could hide the drive in exactly the same way it hid a flight.

The current rule looks for evidence of air travel instead of hiding transit in general. A long distance, an airport near one end, and a speed that is not realistic on the ground can identify a likely flight. Areas connected only to flying or airport stops can be hidden. Drives and ferry journeys remain visible.

The map and the statistics screen use the same function to decide whether an area counts. This matters more than it sounds. Two parts of a personal journal should not disagree about how much of the world the user has explored.

Keeping the data safe

A detailed travel history is sensitive. I would certainly not want to send my entire location history over the years to some random guy’s server.

Travel Log has no account system and no server of its own. The main database stays on device, while place name lookup, trip building, search, and model requests all happen there. There are no advertising tools or analytics.

iCloud sync is optional and uses the user’s private CloudKit database. WeatherKit and the rare online place name lookup send requests directly from the device to Apple services.

As I said before, Travel Log works perfectly offline because it was built with privacy in mind.

What the app still gets wrong

Travel Log receives snapshots of your daily life, not a precise record of every movement. Significant Location Change is occasional and controlled by iOS. A short visit may produce no useful update. A route may have gaps. A location received during a flight may sometimes survive the filters because the phone did not report a reliable altitude.

Photo import depends on the information stored with the photos. Images without a location cannot create places. A sparse library may reconstruct the broad shape of a trip while missing some stops or estimating dates imperfectly.

The language model can also make poor decisions. The app limits where those decisions matter, but I still expect many issues to surface as more people test the app. People who live near a border, move between several homes, work at an airport, or travel for long periods are especially valuable testers because their lives challenge simple rules.

The app currently requires iOS 26 or newer. The model features need a device where Apple Intelligence is available, although the rest of the travel pipeline has normal fallbacks.

I have not made the app open source. I may publish smaller parts later, but I do not want that decision to delay the beta.

What now?

I’ve been using the app while building it over the past ~6 months. It has worked well on my phone and with my travel history. That does not mean it will work well for everybody, even though I’d hope it does.

If what you read fascinates you, if you travel a lot, if you’d like to try something new, or if it just sounds interesting, you can join the Travel Log TestFlight beta. Feedback can be sent through TestFlight or by email at travellog@kfragkoulis.com.

This is still a beta. It is not perfect, and some of its guesses will be wrong. I try to ship updates as frequently as possible. The App Store release should come in a few days/weeks.