Privacy Policy

Privacy Policy

Effective date: June 10, 2026 · Last updated: August 30, 2026

Private by design. Your photos never leave your iPhone, there is no Pastport account and no sign-in, and trip detection and Pastport's Search run on your device. We keep no copy of your trips. Some things do leave the phone. Apple receives the coordinates already inside your photos, the trip and stop locations worked out from them, and anything you type or pin in the optional Home City Search, so it can return place names and map tiles. From version 2.0.1 onward, our analytics provider receives product-usage events about how the app is used, and Apple's attribution service tells us whether this install came from one of our ads. Each of these is described below.

Which version this applies to

Usage data is not sent by every version of Pastport, so this page describes each one separately. Check your version in Settings, at the bottom of the screen.

Who we are

Pastport is built and maintained by Venkat Akkinepally, an independent developer based in the United States. Pastport is offered free, and this version contains no in-app purchases.

Contact: support@getpastport.app. We reply to privacy questions and to requests about your data at that address.

The one thing to know

Pastport is built around a single principle: your photos never leave your iPhone, and we keep no copy of your trips. No one at Pastport has ever seen your photos or your trip history, and no one can, because Pastport operates no server that stores them and there is no account tied to you. There is no crash-reporting SDK in the app. What Pastport does send, and to whom, is set out under The network calls Pastport makes below.

What we do, and what we don't

We do

• Read photo dates (EXIF DateTimeOriginal) and locations (EXIF GPS coordinates) directly from photos in your camera roll, on your device, to detect when you were on a trip.
• Store your detected trip history in a local database on your device. iOS encrypts this database at rest when your device is locked.
• Reverse-geocode the coordinates we already found in your photos into a city and country using Apple's Core Location services. Apple receives those coordinates for the lookup; Pastport does not run its own server. The same is true if you open a trip whose photos live in iCloud Photos: Apple's PhotoKit may pull originals under your existing iCloud session, but Pastport never touches that traffic.
• From version 2.0.1, send product-usage events to our analytics provider, unless you turn that off. See Usage data.

We do not

• Upload your photos, ever, or keep a copy of your trip history on a Pastport server.
• Access or track your live location. Pastport holds no location permission. The coordinates it works with are the ones already embedded in photos you took, the trip and stop locations worked out from them, and any place you search for or pin yourself in the optional Home City Search.
• Send your trip names, your place names, or your Pastport Search text to our analytics provider. Usage data is about how the app is used, not about what is in it.
• Collect crash reports. There is no third-party crash-reporting SDK in Pastport.
• Sell your data, or share it with advertisers or data brokers. Pastport shows no ads and contains no third-party ad-network SDK.
• Use your photos or trip data to train AI models.
• Operate a Pastport account system, login, or cloud sync. (Cloud sync may be added in a future version, opt-in.)
• Track you across other apps or websites. Pastport builds no advertising profile, does not read the device's advertising identifier (IDFA), and shows no App Tracking Transparency prompt.

Permissions we ask for

Usage data

Applies to Pastport 2.0.1 and later. Pastport sends product-usage events so we can see which parts of the app work and which do not. It is on when you install Pastport, and you can turn it off at any time in Settings, under Privacy & Data, on the row called "Share usage data".

What is sent. The events include app opens, daily activity, permission, import, scan, chooser and sharing outcomes: whether an import or a scan finished or stopped and roughly how many photos it looked at, how long an import took, the technical reason a scan ended and how warm the device got, and whether you generated or shared a trip card. Every event also carries app version and build; device model and architecture; operating system, orientation and screen dimensions; language, locale, region, time zone, layout direction and colour scheme; SDK version and run context; event time; a session identifier; and the pseudonymous identifier described below.

What our analytics provider never receives. Your photos. Your coordinates. The names of your trips or of the places in them. The text you type into Pastport's Search, which runs entirely on your phone.

What it is used for. Understanding how the app is used, so we can fix what is broken and decide what to build, and measuring whether our own App Store ads bring installs. It is not used to build an advertising profile, it is not combined with data from other companies, and it is not shared with a data broker.

SDK-generated session fields we disabled. Our analytics provider's software offers to attach six session-history fields to every event: the date of your first session, your total session count, your average and previous session length, how many distinct days you have used the app, and how many in the last month. Pastport switches all six off. To be clear about what that does and does not mean: events like "the app was opened" and "the app was used today" still travel under the identifier described below, so return-use can still be analysed. The six fields above are simply not sent.

Who receives it. TelemetryDeck, our analytics provider, receives the events on servers in the EU. TelemetryDeck states that it does not store IP addresses in its databases or logs, and describes the infrastructure providers it uses in its own documentation. We do not sell this data.

The identifier, stated precisely. Each event carries a hashed identifier. Where iOS gives us an identifier for this device, that value is hashed with SHA-256 and the result stays the same for as long as Pastport is installed, which is what lets us group events from one install into a measure like "how many people came back the next day". Because that device identifier is scoped to the device rather than to one installation, the hash will generally be the same again if you delete Pastport and reinstall it. We do not add a secret of our own before hashing. Where iOS does not give us an identifier, our analytics provider's software hashes a placeholder made from your iOS version and our build number instead; that value is shared by everyone on the same versions and it changes when either is updated. Neither form is tied to a name, an email address, or a Pastport account, because Pastport has none of those. We call this data pseudonymous, deliberately, because it does link one install's events to each other.

Apple Ads. Pastport makes up to three attribution attempts per install. Each one asks Apple's attribution service whether this install came from one of our Apple Ads campaigns. Only the three-case attribution result, yes, no, or unavailable, is sent to TelemetryDeck. Pastport decodes only the attribution Boolean from Apple's reply; the campaign, ad group and keyword fields are never read. We learn that an ad brought an install, never which ad. Pastport uses Apple's AdServices framework for this first-party attribution request and contains no third-party ad-network SDK.

Crash reporting. There is no third-party crash-reporting SDK in Pastport. Pastport does subscribe to Apple's MetricKit, which is part of iOS, and reads the aggregate performance reports iOS produces, writing a short summary to the log on your device. Those summaries are never sent anywhere.

Turning it off. Settings, then Privacy & Data, then the "Share usage data" row. Turning it off stops Pastport from creating new events. Events created before you turned it off may remain queued on your device, or may already be in flight, and may still be sent. Turning it off does not delete events TelemetryDeck has already received; to ask about those, see Your rights.

If we change any of this, we will update this page and the App Store privacy label before the version that changes it ships.

The network calls Pastport makes

For full transparency, here are the network calls Pastport's own code initiates:

• Apple's reverse-geocoding (CLGeocoder): Apple receives the EXIF coordinates already embedded in your photos, and the trip and stop locations worked out from them, and returns a city + country label.
• Apple's MapKit: to render map tiles for the globe and trip-detail maps.
• Apple's place search (MKLocalSearch): to match your photo coordinates to nearby place and point-of-interest names. Apple receives the coordinates already in your photos; Pastport runs no server for this.
• Apple's place-search suggestions (MKLocalSearchCompleter): if you use the optional Home City Search, Apple receives the text you type, as you type it, and returns matching places. When you pick one of those suggestions, Apple receives that selection to return the full place. If you drop a pin instead of searching, Apple receives that coordinate to return a place name.
• TelemetryDeck (analytics), from version 2.0.1: the product-usage events described under Usage data, sent to our analytics provider's EU servers while "Share usage data" is on.
• Apple's AdServices attribution, from version 2.0.1: up to three attempts per install. Each attempt asks iOS for an attribution token and, when it receives one, sends it to Apple, which replies whether the install came from one of our ads. Only the three-case result is sent to TelemetryDeck.
• Apple Maps, when you ask for it: tapping "Open in Maps" on a stop hands that stop's location, and its place name where we have one, to the Maps app.
• This page (and our Terms of Use): when you tap "Privacy Policy" or "Terms of Use" in Settings, an in-app web view loads the page from our static hosting at getpastport.app. These pages carry no cookies, no analytics script and no third-party scripts of any kind; the only outbound request they make is to Google Fonts (fonts.googleapis.com / fonts.gstatic.com) to fetch the page's typefaces. This happens only when you ask for it.
• Apple's PhotoKit: if you open a trip whose originals live in iCloud Photos, PhotoKit may pull them from Apple under your existing iCloud session. Pastport never touches that traffic; it is between Apple and your iCloud account.

Pastport has no crash-reporting SDK, no advertising network, no data broker, and nothing that follows you into other companies' apps.

This website

This section is about the website you are reading, not the app. getpastport.app is a static site. It sets no cookies, runs no analytics script, embeds no third-party trackers, and has no forms. Loading it, and the Google Fonts it embeds, involves the normal web requests any site makes, which our host and Google process in order to deliver the page, subject to their own policies. Web analytics is switched off on our hosting and we do not turn it on without updating this page first.

Children's privacy

Pastport is not directed at children under 13, and we do not knowingly collect data from them. Pastport asks for no name, no email and no account. Photos stay in the user's photo library and Pastport keeps no copy of a user's trip records on a Pastport-operated server; Apple receives the coordinates described above for place lookup. Deleting Pastport removes its local trip database and the references it holds to photos, and does not delete anything from the photo library. Usage events are grouped under a pseudonymous identifier and include app and device metadata; they do not contain a name, an email address, or a Pastport account.

We do not sell or share your personal information

For California residents under the CCPA/CPRA, and for the same posture worldwide: Pastport does not sell, share, or disclose your personal information to third parties for monetary or other valuable consideration, and does not engage in cross-context behavioral advertising. No "Do Not Sell or Share My Personal Information" link is required because we do neither.

Your rights

Your photos and your trip records live on your device only, so you control those directly:

• Delete a trip: open the trip, then use its menu to delete it.
• Delete everything local: Settings, then Reset Pastport, wipes the local database.
• Turn off usage data: Settings, then Privacy & Data, then "Share usage data".
• Uninstall Pastport: removes the app and its sandboxed data. Your photos in the Photos app are never touched.

If you want a copy of, correction to, or deletion of data relating to you, email support@getpastport.app. Pastport holds no name, email address or account for you. Usage events are grouped under a pseudonymous device identifier, so we will assess any request under applicable law and may need to ask you for information that lets us establish whether particular records relate to your installation. Because there is no account, identifying one installation's records is not always possible. Turning "Share usage data" off in Settings stops new events from being recorded; events already recorded before you turned it off may remain queued or already be in flight, and may still be sent.

Data retention

On your device: Pastport keeps your trip data until you delete it or uninstall the app. We do not auto-expire it.

Off your device, the usage events described above are retained by TelemetryDeck, not on a Pastport-operated server. On our current plan, recent events stay queryable for three months. Events older than that are not deleted. They move to cold storage, where they are no longer queryable by us but continue to exist, and they would become queryable again if we raised our plan. TelemetryDeck's privacy documentation states that deletion from cold storage follows no fixed schedule and estimates seven to ten years without guaranteeing it, and that closing our developer account with them does not delete analytics data already collected. We are not going to describe that as deletion, because it is not.

Requests Pastport makes to Apple's mapping, geocoding and attribution services are handled under Apple's own policies, not ours.

Security

Pastport's local data benefits from iOS's standard on-device security, including Data Protection (encryption at rest when the device is locked) and the iOS sandbox. Most of Pastport's features run with no network connection at all.

Changes to this policy

If we change this policy materially, we will update the effective date above and, where relevant, prompt you on the next app launch. Continued use of the app after a change indicates acceptance of the updated policy.

Governing law

This policy is governed by the laws of the State of California, United States, without regard to its conflict-of-laws principles. Nothing in this policy waives any consumer-protection rights you have under your local jurisdiction.