Privacy policy

Who we are

Viewpoint is built and operated by Marcos Barbero, based in the Netherlands, who is the data controller for your personal data.

Contact for any privacy question, request, or complaint: [email protected].

The short version

On the Offline plan, if you don’t sign in, we store nothing about you on our servers. Your spots, photos, and notes stay out of our hands, your subscription is handled entirely by the store you bought it from (Apple on iPhone and iPad, Google Play on Android), and you can capture, browse, and plan as a guest — we never see any of it.

“We never see it” is not the same as “it never leaves your phone”, and you should see the difference up front. On the Offline plan your library is copied to your own cloud account by the platform, not by us — through your iCloud on iPhone and iPad (that is how the Offline plan syncs your spots and photos between your devices), and through Android’s Auto Backup into your Google Drive on Android. In both cases the copy sits under your account, your storage, and your control; we have no access to it. Android adds one more thing that is the platform’s and not ours: Google’s own services register every Android install at first launch, before you sign in and whether or not you ever turn notifications on. The detail is in What we store about you and in Providers and sub-processors.

The Online plan (server-backed sync, live weather and condition alerts, backup, and sharing) requires a Viewpoint account, so signing in is part of starting it; the Offline plan never needs one.

Once you sign in, Viewpoint collects what it needs to do that job (your account, your spots, your photos, your subscription state) and nothing else. Analytics is opt-in and behavior-only — it never includes your photos, GPS coordinates, names of spots, or anything you typed, though it does reach Mixpanel with your IP address so events can be attributed to a country (see Analytics). We don’t sell data and we don’t show you ads. We do share with the platform services your device already runs on — Apple’s on iPhone and iPad, Google’s on Android (sign-in, payments, push, maps, and location) — and with the named providers below, which include a small number outside the EU.

What we store about you

Only if you sign in. Everything in this section applies once you create an account by signing in. As a guest (not signed in) none of it reaches us: there is no account, and your spots, photos, maps, plans, and watches live only in the app’s local database on your phone.

Two caveats, and neither is ours.

On iPhone and iPad, the Offline plan keeps your devices in step through your own iCloud: the app writes your spots, maps, plans, watches and the captured photo files into the private CloudKit database of your Apple account. It is your iCloud storage and your data; we cannot read it, and no Viewpoint server is involved. Photo files are uploaded only over Wi-Fi. Turn it off by signing out of iCloud for the app in iOS Settings → your name → iCloud.

On Android, the operating system’s own Auto Backup is enabled for the app, so it may copy the app’s local data — including that database and the photos it stores — to your Google Drive backup, under your Google account’s storage and your control. We never see it. Turn it off in Android Settings → Google → Backup, or per-app in your device’s backup settings.

Weather lookups still work as a guest — they send only the latitude/longitude you’re checking, never an identity (see Providers and sub-processors → Open-Meteo) — and your subscription is verified directly with the store (Apple or Google Play), so we don’t see it either.

• Your account — email address, a display name, and the opaque identifier returned by Sign in with Apple or Sign in with Google if you sign in that way. The display name is whatever Apple or Google hands us at your first sign-in — with Sign in with Apple that is the name you chose to share on the consent screen, and if you shared nothing we derive one from your email address instead. We never ask you for your real name.

• Your spots, photos, maps, plans, and watches — the data you create in the app. Captured photos are stored in our own object storage; the rest lives in a PostgreSQL database. Both run on owner-operated infrastructure in the EU. Every photo you upload to our servers is put through an automated safety check for illegal and adult imagery before it can appear anywhere public. That check runs on the same servers as everything else — the image is never sent to a third party for it. It happens on every upload, not only on photos you choose to publish. See Trust and safety for why the check exists.

  (An earlier version of this policy said the safety check was performed by Hugging Face, an inference provider outside the EU, and that photographs were sent there. That is no longer true: the check now runs on our own hardware and no photograph you upload leaves our infrastructure. Hugging Face is no longer a recipient of anything.)

• Publicly-shared spots — if you explicitly publish a spot, its location, name, photos, composition notes, and access info become visible to other Viewpoint users via the public-spots surface. Private notes and per-account state (favorites, sync timestamps) never become public, regardless of the spot’s sharing state. Publishing is opt-in, friction-bearing (a confirmation sheet spells out what gets exposed before you confirm), and reversible — see Sharing a spot publicly for the full mechanics + the wildlife-protection safeguard.
• Subscription state — whether you’re on the free trial or a paid subscription, and which plan and billing period (Offline or Online; monthly or yearly). The actual payment is handled by your store — Apple’s StoreKit on iPhone and iPad, Google Play Billing on Android — and we never see your card details. On both platforms, buying while signed in passes your Viewpoint account identifier to the store so the subscription can be matched back to your account — to Apple as the purchase’s appAccountToken, to Google Play as its obfuscated account id. Buying as a guest passes no identifier of ours on either store. The two differ only in how the subscription’s state then reaches us: on iPhone and iPad the app sends Apple’s signed receipt to our server; on Android, Google reports it to our server directly.
• Push notification token — an opaque identifier for your device so we can deliver condition alerts: Apple’s APNs token on iPhone and iPad, a Firebase Cloud Messaging (Google) registration token on Android, and — if you switch browser notifications on in the web app — a push subscription whose address is minted by your own browser’s push service (Mozilla’s for Firefox, Google’s for Chrome, Apple’s for Safari). We store it only once you’re signed in, and it is invalidated server-side immediately when you sign out (the device stops receiving alerts for the signed-out account immediately). On Android the token exists before we ask for it: Google’s Firebase libraries register the install with Google at first launch — see Providers and sub-processors → Google. Signing out invalidates our copy; only uninstalling the app (or clearing its data) removes Google’s.
• Analytics events (only if you turn analytics on) — see the next section.
• Crash reports — no third-party crash-reporting service is involved on either platform; each platform’s own reporting is what we use.
  • On iPhone and iPad, Apple’s on-device MetricKit framework produces a diagnostic (stack trace, exception/signal codes, device model + OS version, app version). Crashes are visible to us through Apple’s standard developer crash reporting (App Store Connect), and a summary is also sent to a Viewpoint server so we get a timely heads-up.
  • On Android, the app ships no crash-reporting code at all. Crashes and ANRs reach us only through Google Play Console’s standard reporting, which the operating system collects; nothing is sent to a Viewpoint server. Whether that collection happens is governed by your device’s own usage-and-diagnostics setting, not by the app.

  Either way: never your photos, GPS, notes, email, real name, or spot / map / plan content. Default is on (legitimate interest under GDPR Art. 6(1)(f) — knowing the app crashes is necessary to keep it working for you).

How location is used

Location is requested and used only in the context of the Map and capture features, to place and find spots. Almost everywhere, the app asks the operating system for a single fix at the moment you need one, and nothing runs when the app is closed.

One feature is the exception, and it is on iPhone and iPad only. Suggest watches when I travel (Settings → Travel) notices when you have arrived somewhere new and offers to set up a watch there. To do that it needs iOS’s “Always” location permission, and iOS will only grant it if you say yes to a dialog it shows you by name. Until you do, nothing runs in the background; if you grant it, iOS wakes the app on a significant change of location, the app works out whether you have arrived somewhere worth suggesting, and that is the whole of it — the position is used on your device and in the reverse-geocoding lookup described below, and it is never sent to us. Turn the setting off, or revoke Always in iOS Settings → Privacy → Location Services, and the monitoring stops. Android has no background-location feature at all and asks for no background-location permission.

The map itself belongs to your platform, and that platform sees it. Viewpoint does not draw its own map tiles, so panning the map, opening street-level imagery, searching for a place by name, turning a coordinate into a place name, or taking a position fix are all requests to your platform’s map and location services:

• On iPhone and iPad that is Apple — MapKit for tiles, Look Around for street-level imagery, Core Location for the position fix, MapKit place search for typed searches, and MapKit’s geocoder for turning a coordinate into a place name.
• On Android that is Google — the Google Maps SDK for tiles, the Street View panorama for street-level imagery, Android’s system geocoder for both directions of place lookup, and Google Play services’ fused location provider for the position fix, which uses nearby Wi-Fi and cell signals as well as GPS.
• In the web app that is Google — the Google Maps JavaScript API for tiles, Places Autocomplete for typed searches, Street View for street-level imagery, and the Static Maps API for the small map images on a spot page and on a shared plan card.

Place lookup runs in both directions, and they send different things:

• Searching by name sends the text you type. Every keystroke in a place-search field goes to Apple (on iPhone and iPad) or Google (on Android and the web) as you type, together with a rough map region so the results are nearby.
• Reverse geocoding sends a coordinate. To label a spot with a place name, or to work out which timezone a spot is in, the app sends the coordinate to the platform’s geocoder and gets a name back. On iPhone and iPad this runs for spots that don’t yet have a label, in the background, a batch at a time — so over the life of your library, the coordinates of the spots you have saved are sent to Apple’s geocoder. On Android the one place this happens is the shareable plan card, and the coordinate is deliberately blurred before it is sent — snapped to a 0.05° grid, roughly 5.5 km, so what leaves the device is the neighbourhood and not the viewpoint.

In every case the coordinates and search text go to the platform, not through our servers, and are handled under that platform’s own privacy policy. We never send your account identity along with them.

Our own servers also send coordinates onward. Some features are answered by asking a third party about a place, always with a coordinate or an area and never with anything that identifies you: weather from Open-Meteo, map and landmark facts from OpenStreetMap’s Overpass service, Wikidata and Wikimedia Commons, a street-level preview image from Google, terrain elevation tiles from an Amazon Web Services open-data bucket (a tile covers about a 10 km square, so what AWS sees is the tile, not your position), and — for the assisted mode of Find your viewpoint only — the subject you are planning around, including its coordinate, to OpenAI. Each is named in Providers and sub-processors.

Analytics — opt-in

Analytics is OFF by default. Turn it on from Settings → Privacy → Share usage analytics. When it’s on:

• We forward behavioral events (e.g., “user viewed Explore tab”, “user captured a spot”, “trial converted to paid”) to Mixpanel via an EU-resident ingest endpoint (api-eu.mixpanel.com).
• Each event carries your user UUID (the same one in our database) and a fixed set of allow-listed properties — closed enums or booleans, never free-text from your spots, maps, or photos.
• Your IP address is forwarded with each event, so that Mixpanel can attribute it to a country and city rather than to our server’s location. That is coarse, network-derived location — not your GPS position, which is never sent. If you would rather not have it sent, leave analytics off.
• Beyond that: name, email, GPS coordinates, EXIF, your spot/map/plan names, anything you typed — none of it is ever included in analytics. The backend enforces this with a closed allow-list on the event-ingest path; events that try to carry disallowed properties are rejected at the edge.
• You can turn analytics off any time. The pipeline stops immediately. Deleting your account also queues a deletion request to Mixpanel that purges your historical events.

Full breakdown: How analytics work.

Providers and sub-processors

Viewpoint relies on the following providers. None of them have access to your unencrypted account or data beyond what their service requires. Which of them your copy of the app talks to depends on the platform you’re on, so each entry says so explicitly.

Most of these are inside the EU or are your own platform’s services. Two are not, and they are the ones worth reading closely: OpenAI receives what you type into Find your viewpoint and the coordinate of the subject you are planning around, and Mixpanel receives your IP address with each analytics event if you have opted in.

No provider on this list receives your photographs. The automated safety check that reads every uploaded image runs on our own servers.

Our own infrastructure (both platforms)

• Self-hosted infrastructure — the API server, the PostgreSQL database, the object storage that holds your captured photos, and the automated safety check that reads every uploaded image all run on owner-operated infrastructure located in the EU. No third-party cloud host stores your account data or photos, and your photographs are never sent anywhere outside that infrastructure.
• Cloudflare — provides the secure network tunnel and DNS that route traffic to the backend (TLS terminates here in transit; Cloudflare does not store your account data or photos).

Apple — iPhone and iPad, plus sign-in on the web

• Sign in with Apple — on iPhone, iPad and the web app, and only if you choose that sign-in method. On the web this loads Apple’s sign-in script into the page.
• StoreKit — payments and subscription management. Apple, not us, takes the money and holds the payment details.
• APNs — push delivery for condition alerts. Registered only after you sign in and grant notification permission; if you decline, no push identifier is created.
• App Store Connect + MetricKit — crash and hang diagnostics.
• MapKit, Look Around, Core Location — map tiles, street-level imagery, place search, reverse geocoding, and position fixes (see How location is used).
• iCloud (CloudKit) — Offline plan only, and it is your own iCloud. The app mirrors your spots, maps, plans, watches and captured photos into the private database of your Apple account so your devices stay in step without a Viewpoint account. This is the largest amount of your content that leaves the device on the Offline plan — and it goes to your storage, not ours. We have no access to it, and no Viewpoint server is involved. Photo files upload over Wi-Fi only.
• SKAdNetwork — Apple’s privacy-preserving install attribution. When you first launch the app, and again if you start a subscription, iOS sends an aggregated, anonymous postback to the ad network that showed you the ad — see Meta below. There is no advertising identifier (no IDFA), no tracking permission prompt, and no advertising SDK in the app; Apple is the sender and it tells the network only that an install or subscription happened, never that you did.

Google — most of it Android-only, two items on both

• Sign in with Google — on iPhone, iPad, Android and the web app, and only if you choose that sign-in method. On the web this loads Google’s sign-in script into the page.
• Street View Static imagery — on all surfaces, including iPhone and iPad. When a spot has no photo of its own, we fetch a street-level preview for it, and that request goes to Google carrying the spot’s coordinates. It is made by our backend, not by your phone, so Google sees the coordinates and our server’s request — never your account, and never your device’s address. The same is true of the street-level preview in the web app.
• Static map images — the web app is different, and it is worth knowing. The small map picture on a shared plan card in the web app is loaded by your browser directly from Google, not proxied through us, and the coordinate is in the image’s address. So for that one, unlike the preview imagery above, Google sees the coordinate together with your IP address and browser. The same is true of the interactive maps the web app draws, which are Google’s and run in your browser. The iPhone, iPad and Android apps render their own maps instead.
• Firebase Cloud Messaging + Firebase Installations — Android only, and this one is not conditional. Google’s Firebase libraries start with the app and register the install with Google at first launch — before any sign-in, before the onboarding screens, and whether or not you ever allow notifications. Google receives an install identifier for the app on your device plus the usual technical details of such a request (app and library version, device model, OS version, IP address). It does not carry your account, your email, your spots, or your location. We only store the resulting token, and only once you’re signed in; when you sign out we invalidate our copy, but Google’s registration lives until you uninstall the app or clear its data.
• Google Play Billing — Android only. Payments and subscription management on Android are Google’s, not Apple’s. If you’re signed in when you buy, your Viewpoint account identifier is passed to Google Play with the purchase so the subscription can be matched to your account, and Google reports the subscription’s state to our server. Buying as a guest passes no identifier of ours.
• Google Maps SDK, Street View, Android’s geocoder, and Google Play services’ fused location provider — Android only. Map tiles, street-level imagery, place searches (the text you type), reverse geocoding of a deliberately blurred coordinate, and position fixes go to Google. See How location is used.
• Google Maps JavaScript API, Places Autocomplete, Street View and Static Maps — web app only. The browser loads these from Google directly, so Google sees your IP address along with the map region, the coordinate, or the text you typed. See How location is used.
• Google Fonts — the web app and our website; not the phone apps. Our two typefaces are loaded from Google’s font CDN rather than served by us, so Google sees the request — your IP address, your browser, and the page you came from. That happens on every page of the web app, on every page of getviewpoint.app including this one, and again inside the assistant panel when you open it. Be aware of the timing: unlike the analytics above, the font request is not behind the cookie banner — it fires as the page loads, whether you go on to accept or decline. No account data is involved and nothing is stored; it is a hosting choice rather than a tracking one, and self-hosting the font files would remove it.
• Google Play Console — Android only. Crashes and ANRs on Android reach us through Play’s standard OS-collected reporting; the app itself contains no crash-reporting code.
• Google Play Developer API — Android only, server side. To confirm a subscription is real, our server sends the purchase token back to Google for verification.
• Not used on any platform: Google Analytics / Firebase Analytics, Google advertising, Google’s advertising identifier, and Google’s attribution SDKs. The Android app deliberately ships Firebase messaging only.

Meta — iPhone and iPad only, and only in the aggregate

• We advertise Viewpoint on Instagram and Facebook, so we need to know whether those ads work. On iPhone and iPad that measurement runs entirely through Apple’s SKAdNetwork: when the app first launches, and again if you start a subscription, Apple — not the app — sends Meta an anonymous, aggregated postback saying an install or a subscription happened. There is no Meta SDK in the app, no advertising identifier, no tracking permission prompt, and nothing that links the event to you, your device, or your account. Apple deliberately delays and coarsens these postbacks so they cannot be traced back to an individual. Nothing equivalent runs on Android or the web.

Everyone else (both platforms)

• Mixpanel — analytics (only if you opt in; EU-resident endpoint). In the apps — iPhone, iPad, Android and the web app — there is no Mixpanel SDK on your device: events go to our own server first and we forward them. Each forwarded event carries your user UUID and your IP address, which Mixpanel resolves to an approximate country and city. Nothing else identifying goes with it — see Analytics. Our website is the exception, and it works the other way round. getviewpoint.app does load Mixpanel’s own script into your browser — but only after you accept the cookie banner, and it is configured to tell Mixpanel not to record your IP address. Decline the banner and the script is never loaded at all.
• Open-Meteo — weather forecasts. Calls go through our backend; your account identity is never sent to Open-Meteo, only the latitude/longitude of the location you’re checking.

• OpenAI — reached from two places, always through our backend and never from your device.

  1. The assisted mode of Find your viewpoint. Two calls happen there and they send different things. Reading your request sends the words you type (up to 2,000 characters), which OpenAI turns into a structured query — which landmark, which body, what time window. Proposing vantage points then sends the subject you are planning around: its name and its coordinate (to about a metre), plus the alignment and time window you asked for, so the model can suggest places to shoot from. If you started the feature from one of your own spots, that spot is the subject — so its name, which you wrote, and its location go with the request. Your account identity is not sent, and none of your other spots are. The deterministic mode of the same feature makes no call at all.

  2. The assistant on our website. Every page of getviewpoint.app — including this one — carries a small chat button, the Viewpoint Assistant. Whatever you type into it is sent through our backend to OpenAI, both to find the relevant documentation and to write the answer. Type nothing into it and nothing is sent. It has no idea who you are; it is not connected to your account, and it is available to anyone reading the site.

  (An earlier version of this policy said coordinates and saved spots were never sent to OpenAI, and that OpenAI was reached only from Find your viewpoint. Both were wrong, and this entry corrects them.)

• Wikimedia (Commons, Wikidata) and OpenStreetMap’s Overpass service — used to find an existing public photo and place name for a spot that has none of its own, and to look up landmarks and legal-access boundaries while planning. Called by our backend with the spot’s coordinates, or an area around them; no account identity is sent.
• Amazon Web Services — terrain elevation tiles from a public open-data bucket, used to work out what the horizon and the skyline look like from a spot. Our backend requests the tile covering the coordinate; a tile spans roughly a 10 km square, so AWS sees the tile, not your position. No account identity is sent.
• Esri (ArcGIS) and the European Environment Agency — protected-area boundaries used to warn you when a viewpoint falls inside a nature reserve or a national park. Our backend sends a bounding box around the area you are looking at; no account identity is sent. These feeds are optional and off unless configured; when they are off, no request reaches either.
• Your browser’s push service — web app only, and only if you turn browser notifications on. The address your browser hands us belongs to whoever makes your browser (Mozilla for Firefox, Google for Chrome and Edge, Apple for Safari), and that service delivers the alert to you. It can see that a notification was sent to your browser instance, and when — the contents are encrypted with a key only your browser holds, so the service cannot read the alert.
• Slack — a private channel Marcos reads. Two things reach it. Support messages: when you write from Settings (Talk to Marcos on iPhone and iPad, Message support on Android, and the same on the web app), your message goes there with your account UUID, your plan, and your app version and device model — plus your email address only if you tick the opt-in box, which is off by default and labelled with the address it would send. Server error alerts: when something fails on our side, the error line is posted there too, so a fault gets noticed rather than sitting in a log. Those alerts carry the technical failure and where in the code it happened — and, on iPhone and iPad, a summary of a crash your device reported. They do not carry your photos, your coordinates, your notes, or your email.

What we don’t do

• No ads inside Viewpoint — no banners, no interstitials, no advertising SDK in any of the apps. (We do buy ads elsewhere to tell people the app exists, and on iPhone and iPad Apple sends the ad network an anonymous, aggregated result — see Meta.)
• No cross-app tracking — no advertising identifier on either platform, no tracking-permission prompt because there is nothing to ask for, no fingerprinting.
• No data sale — your data isn’t a revenue stream and never will be.
• No third-party crash or analytics SDK in the apps — on iPhone, iPad, Android and the web app the only analytics is ours, opt-in, and forwarded from our own server. (Our website is separate: it loads Mixpanel’s script in your browser once you accept its cookie banner. See Mixpanel under Providers and sub-processors.)

Your rights (GDPR — including Article 17, Apple Guideline 5.1.1(v), and Google Play’s User Data policy)

Viewpoint launches in the EU; the EU General Data Protection Regulation applies.

• The right to erasure (Article 17). Every platform’s Settings has a Delete account action — iPhone, iPad, and Android alike. Triggering it permanently deletes your profile from our servers and every record that depends on it — spots, photos, maps, plans, routes, watches, device tokens, sessions, subscriptions and purchases. Captured photos in our object storage are scrubbed by a background job within minutes. Mixpanel events are queued for deletion via Mixpanel’s GDPR-erasure endpoint. The library already stored on your own device is deliberately left in place, the same as on sign-out, so deleting the account doesn’t take your captures with it. You do not need the app installed to do this — see Delete your account for the web request path, the full list of what is erased, and what is retained and for how long.
• Access and portability. Self-service export isn’t built yet. Email [email protected] and we’ll send a JSON dump of everything tied to your account.
• Withdrawing consent. For analytics, toggle Settings → Privacy → Share usage analytics. The change is immediate — the next event your phone would have sent is the first one suppressed. See How analytics work for the full picture.
• Objection, rectification, restriction. Email [email protected] for any GDPR rights request not covered by the in-app surfaces above. We will respond within 30 days.
• Cancel your subscription through the store that bills you, using its own instructions: Apple or Google Play. Cancellation is independent of account deletion — if you cancel without deleting your account, your data stays; if you delete your account without cancelling, the subscription keeps billing until you cancel it in the store, because only the store can stop the billing.

Changes to this policy

If we change this policy in a way that affects you, the Last updated date at the top of this page reflects when. Material changes (new sub-processors, broader data collection, change in operating entity) will be announced in-app and via the email associated with your account before they take effect.

Contact

For any privacy question, request, or complaint: [email protected].