Privacy policy

Effective August 18, 2026 · AppGlance is made by Ludyem AS, Norway

Two kinds of people, two kinds of data

End users of apps that embed the AppGlance SDK, and developers who sign into the dashboard. Almost everything below is about the first group, because that's where analytics data comes from.

Who is responsible for what

For analytics data from apps, the developer who ships the app decides what is collected and why: in EU/EEA terms they are the data controller and we are a processor acting on their instructions. We don't decide what a developer's app sends, we don't inspect it, and we never use it for our own purposes - no profiling, no advertising, no training of any model, no combining data across different developers' apps. The contract that governs that relationship is our data processing agreement, which applies to every developer account automatically and lists our security measures and sub-processors in full.

That split matters if you are an end user of an app: your relationship is with that app's developer, who is the one who must answer you and who holds the delete button. We will pass any request we receive from you on to them.

For developer account data - the email you sign in with, your plan, your billing identifiers - we are the controller. That part is described under "Developer accounts" below.

What the SDK collects from apps

• A random install id. A UUID generated on the device the first time the app runs. It is not the advertising identifier (IDFA), not tied to an Apple ID, a phone number, or any account, and it means nothing outside that one app.
• Events. Named signals like session.start, install, or custom ones the developer tracks, with a timestamp.
• App context. The app version, the OS name and version, and which channel the build came from: the App Store or TestFlight on Apple platforms, Google Play or a Play testing track on Android.
• Country, optionally. Never GPS. By default it is the device's region setting (a locale like "US"), which the app sends and we store as-is. A developer may instead choose to have it resolved from the address their events arrive from: in that case our edge returns the two-letter country and that is all we receive or keep, the address itself is never stored, never logged, and never passed on. Developers can also turn country off entirely.
• Metadata. Small key-value strings a developer may attach to an event. Our documentation and our terms of use require that these never contain personal data, and the developer is responsible for what their app puts there - we have no way to know in advance.

Data a developer chooses to attach

The SDK has an optional identify call. If, and only if, a developer uses it, their app may attach labels to an install: a display name, an email address, the app's own user id, and custom key-value properties. These are stored per install alongside its events, are visible only to that developer in their dashboard, are never shared, and are erased with the app or with the individual user (the dashboard has a per-user delete). Developers who use this must declare it in their own App Store privacy answers as data linked to the user; the dashboard's setup page shows them exactly what to declare. If you are an end user and want an app's labels about you removed, ask the app's developer; they have the button.

What is never collected

• No names, emails, phone numbers, or account identifiers of app users, unless the app's developer chose to attach them as described above.
• No IDFA, no fingerprinting, no cross-app or cross-site tracking of any kind.
• No GPS. No IP-based location either, unless a developer switches their app to IP-derived country, in which case only the two-letter country is derived at our edge , the address itself is never stored, never logged, and never passed on.
• No contact lists, photos, health data, or anything else from the device.

About IP addresses

Like every internet service, our infrastructure (Cloudflare and Supabase) sees the IP address of incoming connections and may hold it briefly in operational logs. We never write IP addresses into the analytics database, never attach them to events, and never use them to identify anyone. The single exception is the country option above: where a developer has turned it on, our edge reads the address only far enough to derive the two-letter country, and the address goes no further.

Where data lives

Events are received by a Cloudflare Worker at the network edge and stored in a Postgres database hosted by Supabase in the EU (AWS eu-west-1, Ireland). Presence heartbeats, the pings behind "active right now", are deleted within the hour - only the rollups they feed ("active now", session length) are kept. Raw events are deleted automatically once they age past the plan's retention window: 90 days on Free, 180 days on Indie, 365 days on Studio and above. The aggregates derived from them - first seen dates, active days, session summaries - are kept for as long as the app exists in the dashboard, which is why lifetime stats stay correct after the raw events behind them are gone.

Some of our providers are global companies, so account and billing data (not analytics data) may be processed outside the EEA by Cloudflare and Stripe under their standard contractual clauses. We may change providers over time; when we do, we hold the replacement to the same standard and update this page.

Security, honestly

Data is encrypted in transit, the database enforces row-level security so one developer can never read another's rows, write keys can only write, and administrative access is limited to the people who run the service. We take this seriously and we build it the way we would want someone to build it for us.

That said: no service is perfectly secure, and we can't promise ours is. Software has bugs, providers have incidents, and a determined attacker is a real thing. We don't guarantee that data will never be accessed, altered, disclosed or lost, and the limits on what we're liable for if that happens are in the terms of use. If we ever discover a breach that affects personal data, we will notify affected developers and the relevant authority as the law requires.

Retention - and what we don't promise

We don't guarantee that data you send will be stored, retained, or remain available. Events past your plan's monthly quota aren't stored at all, event history is limited by plan, heartbeats go within the hour, and data belonging to closed, unpaid or long-inactive accounts may be removed. Our backups exist for our own disaster recovery; they are not a service to you, and we don't promise we can restore anything for you.

If you need to keep something, export it and keep your own copy. Section 5 of the terms spells this out.

Deletion

When a developer deletes an app from the dashboard, every event and label that app ever recorded is erased immediately and permanently; it is the same button as "delete my data". A single user (one install id) can be erased the same way from that user's page. Deleting your developer account (Security → Delete this account, in the dashboard) removes every app the same way, then the account itself.

This is genuinely permanent: there is no undo, no trash, no grace period, and nobody here can bring it back - not by request, not for a fee. That's the point of it, and it's also why you should be sure before you press it. The one qualifier is our own disaster-recovery backups, which are encrypted, are never read back into the live system, and age out within 90 days; the DPA states that in full.

If you are paying for a plan, cancel the subscription before you delete the account, so you are not left with a subscription still renewing against an account that no longer exists. A web subscription is cancelled in Plan & billing; an App Store one in Apple's subscription settings. Once it is set to end you can delete straight away - you do not have to wait for the paid period to run out.

Your rights

If you are in the EU/EEA or the UK you have the right to ask for access to your personal data, correction, deletion, a portable copy, restriction, and to object to certain processing. For developer account data, email support@appglance.app and we'll handle it. For data an app collected about you as an end user, the developer of that app is the one to ask - they hold the controls, and we'll forward anything that reaches us.

You can also complain to your data protection authority. Ours in Norway is Datatilsynet.

Children

AppGlance is a tool for developers and is not directed at children. Developers must not use it to collect data from children below the age of consent that applies to them, and must not use identify to attach a child's name, email or other identifier. If you believe an app has done that through us, tell us and we will work with that developer to remove it.

Developer accounts

The dashboard uses email + password sign-in, or Sign in with Apple / Google / GitHub (handled by Supabase Auth). We use your email to sign you in, confirm your address, reset your password, and send operational notices about your own account - things like usage approaching your plan's cap or a plan change - at most a few such messages a month, and no marketing. If you enable notifications in the AppGlance iPhone app, we also store that device's push token so we can deliver them; turning notifications off removes it. The dashboard sets no tracking cookies; your session token lives in your browser's local storage. We don't run third-party analytics or ads on this site.

Sharing

We never sell data and never share it with advertisers or data brokers. The only parties that touch it are our infrastructure providers: Cloudflare (event ingestion and site hosting) and Supabase (database and authentication). Each one, what it does and where it does it, is listed in Annex 3 of the data processing agreement - and we give developers 30 days' notice by email before adding or replacing any of them.

Webhook alerts are different, and it matters. If a developer turns one on, we send the matching events to a destination they chose, and how much goes with them depends on the format they picked. The Discord and ntfy formats send a one-line summary: the app, the signal names, and the first characters of the install id. The JSON format, which is the default, sends the matching events in full: the install id, the session id, the signal, app version, OS, environment, country, timestamp, any metadata the developer's own app attached to the event, and on install events a computed label saying whether the install looked new or predated the SDK's arrival in the app. That is the one route by which end-user records leave our infrastructure to somewhere we do not run, and the developer who switched it on chooses where that is and is responsible for it. The payload is written out in the webhook documentation.

If you buy a paid plan on the website, Stripe handles the payment as merchant of record and receives what a payment needs: your email address, billing details and card data. Card numbers never reach us - we only ever store Stripe's customer and subscription identifiers alongside your plan. Nobody on a free plan has any data at Stripe, and no analytics data - no events, no users, no app names - is ever sent there.

If you subscribe inside the iOS app instead, Apple bills you, and RevenueCat processes the purchase state for us: it receives your account id and the product you bought, and tells us whether the subscription is currently active. We store only that - the product, its status and when it renews or expires. Card data stays with Apple and never touches RevenueCat or us, and the same rule as Stripe applies: no analytics data ever goes there.

For your own privacy policy

If you ship an app with this SDK, tell your users you collect anonymous usage analytics. In App Store Connect terms, the default setup is "Data Not Linked to You" (Identifiers → User ID and Usage Data → Product Interaction) with tracking = No. In Google Play's Data safety form the same thing is Device or other IDs plus App interactions, collected but not shared, encrypted in transit, and deletable on request. If you use identify, add Contact Info and move everything to "Data Linked to You", and there is still no tracking. The dashboard's setup page hands you those exact answers for the options you enable, and the free App Privacy label tool does the same without an account.

Changes and contact

If this policy changes materially, the effective date above changes with it, and we'll make a reasonable effort to tell developers by email or in the dashboard. Your use of AppGlance is governed by the terms of use, which sit alongside this policy.

Questions, or a request to see or delete your data: email support@appglance.app. Please don't use a public GitHub issue for anything about your own data; mail reaches us privately. For questions about the code rather than your data, an issue at github.com/AppGlance/appglance-apple is fine.