Naam How it works

Privacy Policy

What Naam collects, why, and what never leaves your device.

← Back to naamjap.pro

Effective: October 2026 Last updated: October 2026

Naam is a devotional practice app for iPhone. This policy explains what the app keeps on your device, the small amount it sends off your device, who receives it, and what you can do about it.

We have written it to be read, not skimmed past. If anything here is unclear, write to us at team.slowpress+privacy@gmail.com.

1. Who is responsible for your data

Rahul M ("we", "us") is the data controller for the personal data described in this policy.

2. The short version

Your practice never leaves your device. Your japs, your mantras, your streaks, your coin balance, your age, and the apps, categories and websites you choose to shield are stored only on your iPhone. We never receive them, and neither does anyone else.

That is a precise claim, not a claim about the whole app. Naam is not an entirely offline product. Six things do leave your device, and each has its own section below:

We do not sell your personal data. We do not use it to track you across other companies' apps and websites. There is no account to create and no password to remember.

3. There is no account

Naam has no sign-up, no login, and no user profile on our servers. We never ask for your name, email address, phone number, or postal address, and there is nothing for you to log into. Your subscription, if you buy one, is tied to your Apple Account by Apple — not to an account with us.

One consequence worth stating plainly: because we hold no account, we usually cannot identify you from a support email alone. Section 12 explains what that means when you want to exercise your privacy rights.

4. What stays on your device, and only on your device

The following never leaves your iPhone. It is written to your device's own storage and to a private app group shared with Naam's own iOS extensions. It is not uploaded, not backed up to us, and not visible to us in any form:

If you delete Naam, this data is deleted with it. We cannot restore it, because we never had it.

5. What leaves your device

5.1 Advertising — free tier only (Google AdMob)

Naam shows a rewarded video ad at exactly one moment, and only if you are not a subscriber: when you start a scroll break. Choosing what your shield covers — an app, a category or a website — is free of ads for everyone, every time. Ads never appear during mala or dhyaan practice.

When an ad is requested, Google's advertising SDK receives and processes:

Naam requests non-personalized ads on every single ad request, without exception. This is not a setting we toggle based on your answers; it is fixed in the app's code. We also disable Google's publisher first-party identifier, run no ad mediation, send no custom targeting or content signals, and cap ad content at Google's most restrictive "G" rating. Google may still use device identifiers for limited purposes such as frequency capping, fraud prevention, and aggregate reporting, which is why identifiers appear in this section at all.

Subscribers are never shown ads and never trigger ad requests.

Reporting an ad. If an ad you were shown was inappropriate, go to Profile → About → Report an ad. The report is an email you send us. Nothing the app writes into it describes the ad itself — no screenshot, no ad content, no creative, no advertiser.

What the app writes depends on whether it still holds a record of the last ad it showed. That record is kept in memory only: it does not survive the app being closed, and it never exists at all for someone who has not been shown an ad since the app started.

In both cases the app writes the message into your own mail app and nothing is sent unless you send it, so what actually reaches us is whatever you chose to send: the fields above, anything you added or removed, and — because it is an email — your email address. Section 5.7 covers what we do with it.

Companies other than Google are involved in advertising, and we should say how. Two mechanisms reach companies this policy does not name one by one. We describe the mechanism rather than print a list, because the lists are long, they change without us, and a name in a table you cannot act on is not disclosure.

Google's handling of this data is governed by its own policies:

5.2 Purchases and subscriptions (Apple and RevenueCat)

If you buy a subscription, the transaction is handled by Apple. We never see your payment card, billing address, or Apple Account credentials.

We use RevenueCat to validate your purchase receipt and to keep track of whether your subscription is active. RevenueCat receives purchase and subscription events and a device-scoped identifier. It does not receive your name or payment details.

5.3 Product analytics and session recordings (PostHog)

We use PostHog to understand how people move through the app so we can improve it. PostHog's servers used by Naam are located in the United States.

Events. Naam sends a deliberately small, fixed set of events. We have switched off PostHog's automatic screen-view capture, application lifecycle capture, element interaction capture, in-app surveys, and rage-click capture, so nothing is collected beyond the events we chose. Those events cover:

None of the last three ever includes which app, category or website was involved.

Each event carries your App Store storefront country. Events never carry the content of a practice session.

What PostHog adds on top of our events. Alongside the events we choose, PostHog's SDK attaches a device-scoped identifier — a random value generated the first time you open Naam, stored on your device, and sent with everything afterwards so that events from one installation can be counted as one person's journey rather than as unrelated fragments. It is not your name, your email, your Apple ID, or your device's advertising identifier, and it is not shared with anyone else. Deleting the app and reinstalling produces a new one. The SDK also attaches standard technical context with each event: your device model, iOS version, the Naam version and build, and a session identifier. We do not use any of this to identify you personally; we use it to tell a crash on one iOS version from a crash on another, and a first-day drop-off from a fiftieth-day one.

Session recordings. PostHog also records app sessions so we can watch where the interface goes wrong.

Recording is on unless you turn it off, and you can turn it off in the app. Open Profile → About → Privacy settings and switch off Session analytics. Doing so stops the recording that is running at that moment, and the choice is remembered: every later launch starts with recording switched off, and the recording component is not started at all. Turning it back on is the same switch. Resetting your Naam data does not turn recording back on — only that switch does.

What a recording contains. A recording is a reconstruction of what the app's screens looked like and how they were used, captured while Naam is open and on screen:

How much is recorded. Naam applies no sampling of its own: it does not record only a fraction of sessions. Every session in which recording is switched on is eligible to be recorded, subject only to the settings of our PostHog project. If we begin sampling, this paragraph will change with it.

If you would prefer not to be recorded at all and would rather we deleted what has already been collected, use the switch above and then write to team.slowpress+privacy@gmail.com.

5.4 Crash and performance diagnostics (Apple MetricKit)

Naam uses Apple's built-in MetricKit for crash and performance reports. This is Apple's own framework with no third-party SDK involved, and the data is aggregated and delivered by Apple under Apple's privacy terms. Apple provides it to us only if you have agreed to share analytics with app developers in your iOS settings.

5.5 Notifications

Naam schedules local notifications on your device for practice reminders and break expiry. It does not register for push notifications, holds no push token, and operates no notification server. Nothing about your notifications is transmitted anywhere.

5.6 One true/false value, to your own iCloud

This is the last thing Naam itself puts anywhere outside your iPhone — and it does not come to us. (Section 5.7 below is not the app putting anything anywhere: it is you sending us a message, which nothing happens to until you press send.)

Naam may show you a one-time discounted offer on Naam Pro, once. When it has been shown to you, Naam records that fact, and only that fact, in your own iCloud key-value storage. It is a single true/false value. It exists so the offer appears once for you rather than once for each time you install the app. It says nothing about your practice, your coins, your streak, your age or the apps you shield.

It is your iCloud, not ours — but Naam does write it, and we should say so plainly. We have no server, no account for you, and the value never reaches us: there is no copy of it anywhere we hold, and nobody here can look it up. What we should not claim is that we "cannot" touch it, because the app on your phone is ours, and it is Naam that writes this value when the offer is shown and Naam that reads it back so the offer is not shown again. Never receiving something is not the same as being unable to reach it, and only the first of those is true here. Apple's handling of what sits in your account is governed by Apple's own privacy policy, not by this one.

On some iPhones this does not happen at all. Naam checks whether it can reach iCloud. If it cannot — most commonly because the iPhone is signed into no iCloud account — the app carries on without it, and then nothing about you leaves your device by this route: the record is kept on your iPhone and nowhere else. That is a supported way to run Naam, not a fault.

Deleting the app does not remove the iCloud copy, and no route in the app removes it. That is deliberate — it is what makes "this offer appears once" true for a person rather than for an installation — and because the value sits in your own iCloud rather than with us, removing it is something you can do through Apple and we cannot do for you. The Terms of Use says the same thing at more length.

5.7 When you write to us

Two rows in the app offer to contact us — Profile → About → Support and Profile → About → Report an ad — and both work the same way: the app composes a message in your own mail app and stops there. It cannot send mail, and it does not try to. You see the message, you can change every word of it, and nothing reaches us unless you press send.

If you do send it, we receive an ordinary email, which means we receive your email address along with it. That is how email works and not something we can switch off from our side; it is also why this is the one place in Naam where something that can identify you directly reaches us. We receive it because you chose to write, not because the app collected it.

We receive whatever you wrote. If you describe a problem, quote a screen, or paste something in, we have that too. Please do not send anything you would not want us to hold — in particular, we never need your payment details, and we cannot do anything useful with them.

We use these messages only to answer you and to fix what you reported. We do not add them to analytics, we do not upload them to any of the providers in section 14, and we do not use them for advertising. We hold no account for you, so a support email usually cannot be matched to anything else in this policy — see section 3, and section 12 for what that means when you are exercising a privacy right.

The mailbox is a Gmail address, so Google processes these messages as our email provider. How long we keep them is in section 11.

5.8 Install attribution (Meta)

Naam uses Meta's SDK to measure which ads brought people to install the app — nothing else. There is no Facebook login inside Naam and nothing in the app shares to Facebook.

This channel has a switch of its own, and where you are decides which way it starts. That is the first thing to know about it. The control is Profile → About → Privacy settings → Install attribution, and it is never on before we can say why it is on.

When it is on, three things are sent:

What identifies you here, precisely. Two different things get called an "identifier", and the honest answer differs between them.

What this does not cover. Sending an event to Meta's servers necessarily also reveals your IP address and standard technical details about your device and the request, the way any network connection does — that is inherent to how a network request works, not something Naam adds on top of the three items above.

6. What we never collect

To be explicit, because the absence of something is easy to overlook. Naam never asks for, and never collects, any of the following:

The one exception, stated here so the list above is not read as wider than it is: if you choose to email us, we receive your email address and what you wrote, because that is what sending an email does. Naam neither asks for that nor collects it — you supply it by writing to us, and only if you do. Section 5.7 sets out what happens to it. Nothing else in this list has an exception: no route in the app, and no message it composes, carries your payment details, your location, your contacts, photos, microphone, camera, health data, or your practice data.

7. Screen Time and what you choose to shield — the strongest statement in this policy

Naam's shield uses Apple's Screen Time (Family Controls) framework, which you authorize explicitly the first time it is needed.

When you choose what to shield — individual apps, whole categories of apps, or websites — iOS does not give Naam their names. Apple hands the app opaque tokens — values that are meaningless outside your own device and that Naam cannot resolve into an app name, a bundle identifier, a web address, or an icon. Those tokens are stored on your device only.

Your selections are never transmitted to us or to anyone else, in any form, at any time. That is true of every kind alike — apps, categories and websites. They do not appear in analytics, they do not appear in session recordings, they are never attached to an ad request, and they are never included in enforcement telemetry — the shield events described in section 5.3 deliberately record only how the machinery behaved (whether a re-shield succeeded and how long it took; whether a background timer the shield relies on failed to arm, and what the app did next; that you removed some number of items and whether coins were charged), never what was shielded or what was removed.

8. Consent in the EEA, the UK, and Switzerland

If you are in the European Economic Area, the United Kingdom, or Switzerland, Naam shows you a consent form from Google's User Messaging Platform before serving any ad. You can consent, manage individual options, or decline. To know whether your region needs this form, the app asks that service at each launch, wherever you are; that check shows no form.

9. Legal bases for processing (UK GDPR and EU GDPR)

Where the GDPR or UK GDPR applies, we rely on:

Purpose Legal basis
Serving ads on the free tier Consent (Article 6(1)(a)), collected through the consent form described in section 8
Session recordings and product analytics Consent where required, otherwise legitimate interests (Article 6(1)(f)) in understanding and improving the app
Processing your subscription and restoring purchases Performance of a contract (Article 6(1)(b))
Crash and performance diagnostics; fraud and abuse prevention Legitimate interests (Article 6(1)(f)) in keeping the app working and secure
Reading and answering an email you send us, including a report about an ad (section 5.7) Legitimate interests (Article 6(1)(f)) in answering people who write to us and fixing what they report
Install attribution and ad-campaign events sent to Meta (section 5.8) Consent (Article 6(1)(a)), given through the Install attribution switch in section 12 before Meta's SDK is started, and separately from the advertising consent in section 8
Recording in your own iCloud that the one-time offer has been shown (section 5.6) Legitimate interests (Article 6(1)(f)) in showing an offer once per person rather than once per installation, and in not showing you the same offer again — one true/false value, written by the app on your device into storage that belongs to you, and never sent to us

A note on the Meta row, because it was a placeholder until recently and the reason it stopped being one is a change to the app rather than a change of mind.

Section 8's consent form is Google's User Messaging Platform, shown before an ad is served, and it does not extend to Meta's SDK. For a time nothing in the app gated the install-attribution and purchase events at all, so no basis in this table honestly covered them and the row said so rather than guessing. Naam now has its own control for this channel — the Install attribution switch described in section 12 — and the SDK is not started, and no event is sent, unless that switch resolves to on. Where consent is the required basis the switch is off until you turn it on, so consent precedes the processing rather than following it. That is what makes consent the honest entry in the row above.

The iCloud row. We should be precise about who does what here, because it is easy to describe this in a way that flatters us. The value lives in storage that belongs to you, under your Apple ID; it never reaches us, we operate no server, and there is no copy of it anywhere we can see. But the app on your phone is ours: it is Naam that writes the value when the offer is shown and Naam that reads it back to decide not to show the offer again. We decided that it should happen and we decided how. That makes us responsible for it under the GDPR even though we never receive it, and it would be wrong to imply that being unable to see the value means it is not ours.

So the basis is legitimate interests, and the interest is small and plain: an offer we said appears once should appear once, and you should not be shown the same discount over and over. It is a single true/false value. It says nothing about your practice, your coins, your streak, your age or the apps you shield, it is not combined with anything, it is not used to profile you, and it does not travel outside your own Apple account. If you would rather it were not there, section 12 tells you what you can and cannot do about it, and we have tried not to overstate either.

The iCloud row above used to be a placeholder too, and the difference between the two is why it no longer is. The section 5.6 value never leaves your own Apple account, and once we stopped describing it as something we "cannot" touch — our own app writes and reads it — the controllership question stopped being hard enough to need a lawyer, and we answered it. The events in section 5.8 were not like that: they reach another company, and before the switch in section 12 governed them they would do so whatever your answer to section 8's form. One of the two was inert while it waited for an answer and the other was not, which is why 5.8 was the row that could not simply be reasoned out. It stopped waiting when the app changed rather than when we thought harder — the section 12 switch is what made consent available as an honest answer. Both rows are answered now, and neither is a placeholder.

Where we rely on legitimate interests, we have weighed those interests against your rights and have limited what we collect accordingly — the bucketing, masking, and exclusions described throughout section 5 are the result of that balancing. You may object to processing based on legitimate interests; see section 12.

9.1 Naam is a devotional app, and we have thought about what that implies

Naam is built for Hindu devotional practice. Data that reveals religious or philosophical belief is treated as a special category under Article 9 of the UK and EU GDPR, and that protection has been read to reach information from which such a belief can be worked out indirectly, not only information that states it outright. The fact that a person uses an app like this one is capable of saying something about them, so we would rather set out where we stand than leave it unmentioned.

What we do about it, in order of how much it matters:

What we are not going to claim. We are not going to tell you that Article 9 definitely does not apply here. There is a real argument that it does not — installing an app is not the same as holding a belief, and nothing we send names a mantra or a practice — but that argument is ours to make and it would be self-serving to present it to you as settled. We have instead built the app so that the question matters as little as possible: the material that would most clearly be special-category data never leaves your phone at all, and the channels that do leave it ask your permission where permission is what the law requires.

10. International transfers

We are based in India. Our providers process data outside your country, including in the United States (PostHog, Google, RevenueCat, Meta).

Where personal data is transferred out of the EEA, the UK, or Switzerland, the transfer relies on the European Commission's Standard Contractual Clauses and the UK Addendum, together with each provider's own transfer safeguards, and on additional technical measures where appropriate. You may request further detail at team.slowpress+privacy@gmail.com.

11. How long we keep things

12. Your rights

Depending on where you live, you may have the right to access your personal data, correct it, delete it, restrict or object to how it is processed, receive it in a portable format, withdraw consent you previously gave, and complain to a regulator.

In the EEA / UK / Switzerland, you can lodge a complaint with your local supervisory authority. In the UK this is the Information Commissioner's Office (ico.org.uk).

In Canada, PIPEDA gives you rights of access and correction, and you may complain to the Office of the Privacy Commissioner of Canada (priv.gc.ca).

In US states with comprehensive privacy laws (including California, Colorado, Connecticut, Virginia, and others), you may have rights of access, deletion, correction, and portability, and the right to opt out of targeted advertising and of the "sale" or "sharing" of personal information. We do not sell your personal information for money. These statutes use "sale" and "sharing" more broadly than that, though, so the flat sentence that used to sit here was doing more reassuring than it had earned. What we actually do, channel by channel, is below.

Whether anything Naam does amounts to "cross-context behavioural advertising", a "sale", or "sharing" under these laws is not one question, so we have answered it channel by channel rather than in a single reassuring sentence.

So you can opt out, and here is where. Open Profile → About → Privacy settings and find Install attribution. Switching it off stops the events the app sends explicitly straight away, and stops the SDK starting at all on later launches. It is not a request you have to send us and we do not need to identify you to honour it — the switch is the opt-out. You can also write to team.slowpress+privacy@gmail.com if you would rather, though the switch is faster and more certain.

In some places that switch starts off rather than on, because where consent is the required basis we do not start the channel until you have said yes. If it is already off, there is nothing you need to do — nothing is being shared.

We do not sell your personal information for money, and we never have. These statutes use "sale" more broadly than that, which is why the paragraph above says what it says.

We will not discriminate against you for exercising any right.

How to exercise a right. Write to team.slowpress+privacy@gmail.com. Please note the practical limit described in section 3: we hold no account for you, so for most requests there is no record on our side to retrieve, correct, or delete, and we may be unable to link a request to any specific data. The exception is correspondence you have already sent us (section 5.7): a message in our mailbox is a record we hold and can find, because your own message identifies it, so a request to see or delete what you have written to us is one we can act on. Where we can act, we will respond within the period required by the applicable law.

Three things you can do yourself, immediately, without contacting us:

13. Children

Naam is not directed to children. It is designed for adults maintaining a devotional practice, and we do not knowingly collect personal data from children under 13 (or the equivalent age under your local law).

If you believe a child has provided us with personal data, write to team.slowpress+privacy@gmail.com and we will delete what we can.

14. Who receives data, in one table

Recipient What they receive When Their policy
Google (AdMob) Device advertising identifier, IP-derived coarse location, ad interaction data, ad SDK diagnostics Free tier only, when an ad is requested https://policies.google.com/privacy
Google (User Messaging Platform) Your consent choice and related consent state A consent-status check on every launch, everywhere; your consent choice only in the EEA, the UK and Switzerland https://policies.google.com/privacy
PostHog The fixed event set in section 5.3, storefront country, a device-scoped identifier, device model / iOS version / app version / session identifier, masked session recordings unless you switch Session analytics off (section 5.3) Whenever the app has events to send https://posthog.com/privacy
RevenueCat Purchase and subscription events, a device-scoped identifier Only if you subscribe or restore https://www.revenuecat.com/privacy/
Apple Payment processing, subscription management, crash diagnostics; and, in your own iCloud rather than in any account of ours, the single true/false value in section 5.6 Purchases; diagnostics if you opted in; the iCloud value when the one-time offer has been shown and your iPhone can reach iCloud https://www.apple.com/legal/privacy/
Google (Gmail), as our email provider Any email you choose to send us, including your email address and what you wrote (section 5.7) Only when you send us one https://policies.google.com/privacy
Meta Install and app-open signals, an onboarding-completion signal standing in for account creation, purchase amount and currency on a genuine fresh charge, and an identifier for this installation of the app — no cross-app advertising identifier (section 5.8) Only while Install attribution is on; off until you turn it on in the EEA, the UK and Switzerland, and on from your first session elsewhere once consent is established as not required (section 5.8) https://www.facebook.com/privacy/policy/

The table above is what leaves your device to a company because Naam sends it. We also receive one thing directly, and only when you send it: the email in section 5.7.

Two mechanisms described in section 5.1 reach companies the table does not name row by row, and the sentence below is written to be true of them rather than around them. Google's common ad partners can receive ad-request data when an ad is served, under the consent form in section 8 — that form names them and lets you choose. And Apple sends an SKAdNetwork postback, carrying no identifier for you or your device, to whichever advertising network an install is attributed to. We never receive those, and we do not send them — though as section 5.1 explains, a value inside one can be set from within the app.

Beyond the table above and those two mechanisms, we do not share your data with anyone else — and we do not sell it, to anyone, ever.

15. Security

Data stored on your device is protected by iOS file protection and is unavailable until you have unlocked your device after a restart. Data in transit to the providers above is encrypted with TLS. No system is perfectly secure, but because we operate no user accounts and hold no directly identifying information, there is very little about you for anyone to take from us.

16. Changes to this policy

If we change this policy in a way that materially affects you, we will update the "Last updated" date above and, where the change is significant, tell you in the app before it takes effect. The current version always lives at https://naamjap.pro/privacy/.

17. Contact

Rahul M team.slowpress+privacy@gmail.com TC-22/669(1), Swathi, Chiramukku, Attukal, Manacaud, Thiruvananthapuram, Kerala 695009, India

Terms of Use: https://naamjap.pro/terms/