What is stored on your phone

Version 2026-08-25. In force from 25 August 2026.

Older versions are kept and we will send you any of them if you ask at support@ya-habibi.co.uk. There is no archive inside the app yet, and saying there was one would be the kind of promise this document is trying not to make.

This is the document a website would call a cookie notice, for the phone app. Ya Habibi is an app and not a website, so there are no cookies, no browser, no tracking pixels and no tag manager. There is still information written onto your phone, and the law that covers cookies covers that too. This notice lists every single thing Ya Habibi stores on your device, says what each one is for, says honestly whether it is the kind of storage that needs your permission, and tells you how to get rid of it.

Ya Habibi also has two websites, ya-habibi.co.uk and app.ya-habibi.co.uk, and they are covered by a separate document, cookies.md. The short version is that neither of them sets a cookie and neither uses a third party analytics service. app.ya-habibi.co.uk is the same Flutter code as the phone app, so the measurement described below applies to it as well, and it writes the same two keys into your browser's local storage rather than into a phone's settings store.

This document was prepared for review. It is not legal advice, it is not a contract, and it has not been reviewed by a qualified solicitor.

Why this notice exists when there are no cookies

Article 5(3) of the ePrivacy Directive, which in the UK is regulation 6 of the Privacy and Electronic Communications (EC Directive) Regulations 2003, is not written about cookies. It is written about terminal equipment. It says that storing information on, or gaining access to information already stored in, a user's terminal equipment is only allowed if the user has been given clear information and has consented, unless one of two exemptions applies:

1. 1.the storage is for the sole purpose of carrying out the transmission of a communication over an electronic communications network, or
2. 2.the storage is strictly necessary for the provision of a service that the user has explicitly requested.

A phone is terminal equipment. A key written into the app's own preference store is information stored on it. So the same rule that makes a website ask you about cookies applies to what an app writes into your phone, and "we are an app, not a website" is not an answer to it. This notice is Ya Habibi's answer to it.

The rule changed on 5 February 2026, when the storage provisions of the Data (Use and Access) Act 2025 came into force, and the changes matter for this document because they resolve most of what the previous version of it left open.

• New exception: adapting the appearance or functions of the service in accordance with the user's preferences. That covers, cleanly and without argument, the theme, the Quran settings, the notification settings, the calculation settings and every other thing in this document that exists because you chose it.
• New exception: statistical purposes, where the sole purpose is collecting information about how the service is used with a view to improving it, and where clear information and a simple, free means to object are given.
• Statutory examples of "strictly necessary" were added, and automatic authentication is one of them, which settles the session token.
• The penalty band changed. The maximum fine for a regulation 6 breach went from £500,000 to £17.5 million or 4% of global turnover, whichever is higher. That is a reason to be precise about this, not a reason to add a banner nobody needs.

Two separate questions run through the whole of this document, and it is worth keeping them apart:

• The ePrivacy question: was Ya Habibi allowed to write this onto your phone at all, without asking first? That turns on strict necessity.
• The UK GDPR question: once something personal is in there, what is Ya Habibi allowed to do with it, on what lawful basis, and for how long? That is answered in the privacy policy, not here.

Where the app puts things

There are three places, and nothing else:

1. 1.The app's key and value store. On iOS this is NSUserDefaults, on Android it is SharedPreferences. It lives inside the app's private sandbox, so no other app on the phone can read it. Every key below is written through the same Flutter plugin, which namespaces them, so on disk they carry a flutter. prefix in front of the names given here.
2. 2.Two files in application support. These are the offline place database and its version stamp, described in their own section below. Application support was chosen rather than the documents folder because on iOS the documents folder can be exposed to the Files app, and this file has no business being visible there.
3. 3.The operating system's own alarm store. When prayer notifications are on, the scheduled alerts are held by iOS and Android themselves, not by Ya Habibi. This matters for clearing them and is covered below.

There is no keychain use and no cache directory of downloaded personal data. There is no third party analytics, crash reporting, advertising or attribution software development kit anywhere in the app, so nothing on your phone is written by somebody else's code: no Firebase, no Sentry, no Amplitude, no Mixpanel, no AppsFlyer, no Adjust, no Facebook kit, no PostHog. That was checked by searching the whole of the app source, the iOS project, the Android project and the server functions.

Ya Habibi does measure itself, and this document said until 25 August 2026 that it did not. Since migration 0175 the app has its own crash reporting and its own analytics, written by Ya Habibi, sending to Ya Habibi's own database and to no third party at all. That is a correction rather than a new feature, and section 4.11 of the Privacy Policy sets out in full what it holds, why, and the three things about it that are not right yet. What it puts on your device is two keys, listed in the table below: a pseudonymous identifier for the device, and your own opt-out flag. Neither is an advertising identifier, neither is shared with anybody, and neither leaves the phone except as the device identifier attached to Ya Habibi's own rows.

Every key, and what it is

The tables below are the complete list of everything Ya Habibi writes to your phone. "Strictly necessary" is Ya Habibi's own assessment against the Article 5(3) exemption, and the section after the tables explains where that assessment is comfortable and where it is a judgement call.

Prayer, place, Quran and the tracker

Everything in this group is worked out on the device from bundled data. None of it needs an account and none of it needs a network.

The prayer settings now have a server copy, and the previous version of this document said they did not. Since August 2026 the whole calc.* group, including your sect and your madhab, is mirrored to your account as one opaque blob so that the web version of Ya Habibi shows the same times as the app rather than a different school's defaults. The keys above are still on the phone and are still what the app reads. What changed is that they are no longer only on the phone.

That is a change in the other direction from most things in this document, so it is stated in the place somebody would look for it rather than only in the privacy policy. The sentence that used to appear in this notice, that both keys are on the device only and no server copy is made, was true when it was written and is not true now. Section 5.2 of the Privacy Policy explains what we rely on to hold that copy, and section 20 of it records that the server copy is not yet reached by the account erase, which is a gap rather than a design.

Notifications

Prayer alerts are local. They are scheduled by your phone from times worked out on your phone. There is no push provider behind them: no Firebase, no OneSignal, no push server of any kind. Ya Habibi is not told when one fires.

The account, your profile, and who you are

Everything in this group belongs to the account rather than to the phone, and all of it is removed when you sign out.

Messages

Ya Habibi's private messages are not end to end encrypted. Ya Habibi can read them on the server, and does when a conversation is reported. Separately from that, they are also cached on this phone, in the clear, inside the app sandbox.

Two things about attachments. A voice note you record is held by the operating system's own temporary storage only for as long as it takes to upload it, and it then lives with the message like any other attachment. And a photograph or video you are about to attach is handled by the system picker, which is outside this app's storage entirely.

The Ummah feed

Measuring the app

The switch that writes the second key is built and no screen offers it. That is stated here rather than left to be discovered: until it is on a settings screen, the free and simple way to object that the law requires does not exist in the interface, and the answer in the meantime is to write to support@ya-habibi.co.uk, which will stop it for your device. It is item 4 in section 12 of data-retention.md and it is named in section 4.11 of the Privacy Policy in the same words.

Files

Held by the phone rather than by Ya Habibi

The ones that are worth reading twice

Four things in the tables above surprise people, so they are stated plainly here.

Your messages are on the phone. Not just the last line of each conversation, though messages.v2 does hold that in full, but the actual bodies of the messages in every conversation you have opened, one key per conversation, in messages.thread.<conversation id>.v1. They sit unencrypted inside the app's private sandbox. Anyone who can unlock your phone and read that sandbox can read them. This is why signing out removes them.

The feed cache holds other people's posts. ummah.feed.cache.v1 is the first page of the server feed for up to eight views, and a page of the feed is made of posts other people wrote: their words, their names, their handles, their pictures. Ya Habibi keeps only the first page of each view, on purpose, so it is not an offline archive of the Ummah. It is still other people's content sitting on your phone until you sign out.

The notification ledger records whether you opened the app from a prayer alert. Most of that ledger is machinery: it exists so the same alert is not armed twice and so an alert whose time or wording changed gets re-armed. One field is not machinery. openedApp records that an alert was tapped and the app came up. It never leaves the phone, and it is deleted with the rest of its entry after 30 days, but it is a record of your behaviour and it is the one item in this document Ya Habibi will not claim is strictly necessary.

Several things deliberately survive sign out. The prayer tracker, the place you are using, your sect and madhab, your Quran reading position and reciter, your notification settings, the theme, and the one time prayer introduction are all kept when you sign out. This is not an oversight, it is a promise the app makes to you in writing before you sign out. The confirmation sheet says:

Prayer times, the Quran, qibla and your prayer tracker are worked out here from bundled data. They are untouched and they keep working signed out.

Your Ummah profile and your messages belong to the account. They leave this phone now, and they are there again when you sign back in.

The reasoning is that clearing those would be undoing a decision you made about this handset, rather than clearing an account's data off it. Your prayer tracker in particular has no server copy at all, so if sign out cleared it, it would be gone permanently. If you want those cleared as well, delete the app.

The 18MB place database

When Ya Habibi first needs to name a place, it copies an 18MB SQLite database out of the app bundle into application support and opens it read only. It is a gazetteer: 235,206 settlements from GeoNames, across 246 countries and 3,782 named subdivisions, with names, coordinates and time zones.

It matters for two reasons.

First, it is why Ya Habibi can tell you what town you are in without sending your position anywhere. Turning a coordinate into "Hemel Hempstead" is a network request in almost every app that does it. In Ya Habibi it is a local database lookup, so the position stays on the phone.

Second, it contains nothing about you. It is a fixed list of places on earth, identical on every install, shipped inside the app. It is a rebuildable cache: if you delete it, the app copies it back out of the bundle the next time it needs it, and the places.sqlite.version stamp is how it knows whether the copy on disk is current. It is stored in application support rather than the documents folder specifically so that it is not exposed through the iOS Files app.

Because the sign out sweep runs over the key and value store, these two files are not removed by signing out. That is intentional and it costs you nothing: there is no personal information in either of them.

Which of these actually need your consent

This is Ya Habibi's honest assessment, not a claim that a regulator would agree with every line of it.

Comfortably strictly necessary

The session token, the profile and identity keys, the circle membership keys, the place fix, the prayer calculation settings, the Quran settings and position, the notification settings, the theme, intro.seen, onboarding.v1, the prayer tracker, and the two gazetteer files.

Each of these is either something you set yourself, or something without which the thing you explicitly asked for cannot be delivered. You cannot have prayer times without a position and a calculation method. You cannot have prayer alerts without settings that say which alerts. You cannot stay signed in without a session token. The prayer tracker is not a record about the service, it is the service. These fall inside the second Article 5(3) exemption and no consent is required for storing them.

Several of them are also covered, independently and more comfortably, by the exception added in February 2026 for adapting the appearance or functions of a service to the user's preferences: the theme, the Quran display settings, the notification settings and the calculation settings are all things you chose.

Note separately that some of them, calc.sect and calc.madhab in particular, are information about religious belief, which is special category data under Article 9 of the UK GDPR. Regulation 6 is satisfied without consent because the storage is strictly necessary and because it reflects your own preference. That is a different question from whether the processing has an Article 9 condition, and the privacy policy is where that is dealt with. There is now a server copy of both keys, and section 5.2 of the Privacy Policy is where its lawful basis lives.

Judgement calls

The message caches (messages.v2, messages.v1, messages.thread.<id>.v1). The argument for necessity is that you explicitly asked for a messaging service and holding the conversation you are looking at is part of delivering one, and that the server holds the real history either way. The argument against is that the app would function without them, more slowly, and that a cache is a convenience rather than a requirement. Ya Habibi's position is that these are necessary for the service requested. It is a defensible position rather than an obvious one, and it is the one most likely to be argued with.

The feed caches (ummah.feed.cache.v1, feed.posts.v3, feed.comments.v1, feed.following.v2). The same argument, weaker, because what is cached is largely other people's content and the only thing it buys is that a tab opens on content instead of a spinner. Ya Habibi does not claim these are strictly necessary in the strong sense. What blunts the point is that they are used for nothing except drawing the screen you just opened: nothing is measured from them, nothing is profiled from them, and nothing in them ever leaves the phone.

The `openedApp` field in the notification ledger. Ya Habibi does not claim this one is strictly necessary. Everything else in that ledger prevents double arming and drives re-arming, which the alerts genuinely cannot work without. Whether you tapped an alert is proof of delivery, and proof of delivery is measurement.

This one now has a clean answer, which it did not have when this document was first written. The February 2026 statistical purposes exception permits storage whose sole purpose is collecting information about how the service is used with a view to improving it, provided clear information is given and there is a simple, free way to object. The information is this paragraph. What is missing is the switch.

The two measurement keys, `yh.analytics.device_id` and `yh.analytics.opt_out`, and this is the weakest item on this page. Neither is strictly necessary and Ya Habibi does not claim either is. The route available is the same February 2026 statistical purposes exception: the storage exists to collect information about how the service is used in order to improve it, it is first party, it carries no cross-site identifier, and the clear information the exception requires is section 4.11 of the Privacy Policy and the table above. The simple, free way to object is written and is on no screen, exactly as it is for the notification ledger, so the exception is not yet properly available and this is a stated shortfall rather than a defended position. The opt-out flag itself is different: storing the fact that you objected is the only way to honour the objection, and that is strictly necessary by any reading.

There is a prior question above all of this, and it is in section 12 of data-retention.md and section 27 of the Privacy Policy as a matter for a solicitor: whether a persistent identifier written into a phone's or a browser's storage for measurement purposes is caught by regulation 6 at all. If it is, consent is the first question and the retention period is the second.

What follows if the remaining judgement calls go the other way

If the message caches or the feed caches are held not to be strictly necessary, then regulation 6 requires clear information and consent before they are stored. Ya Habibi asks for no such consent today, because it asks for none at all. There are three possible answers:

1. 1.Remove the item.
2. 2.Put it behind a switch that is off until it is turned on, with this notice as the information given.
3. 3.Record a written assessment that it is strictly necessary for the service the user requested, and be prepared to defend it.

For the message caches the answer is (3). The written assessment is the paragraph about them in the section above, and it is written down here rather than assumed: the service you asked for is a messaging service, holding the conversation you are reading is part of delivering one, the server holds the history either way, and signing out removes every one of these keys from the phone.

For the feed caches the answer is (2), not (3). Ya Habibi does not claim the feed caches are strictly necessary, and something nobody claims is necessary should not be stored on the strength of an assessment that it is. They belong behind a switch that is off until you turn it on, with this notice as the information given. That switch is not built. Until it is, they are still written in the ordinary course of using the Ummah, each view's cached page being replaced every time the server answers for it, and this is a stated shortfall rather than a position this notice defends. The only control you have over them today is signing out, which clears all of them from the phone, or deleting the app.

If a solicitor decides that either of those answers is the wrong one, the fallback is (1), removing the item, rather than keeping it with neither consent nor an assessment behind it.

What is not in question either way: none of this storage is used for advertising, profiling or cross app tracking, by Ya Habibi or by anybody else. There is no advertising component anywhere in the app, nothing here is shared with a third party, nothing follows you to another app or another website, and there is nothing to sell to. The audience measurement that does exist is Ya Habibi's own, it writes to Ya Habibi's own database, and it is the two keys named above and nothing else on this page.

That paragraph used to end differently and the ending was wrong. Until 25 August 2026 it said there was no analytics, crash reporting, advertising or attribution component anywhere in the app, and that this had been verified by searching the entire codebase. The search was real and the sentence was true when it was written; migration 0175 and the client code beside it made it untrue and the document was not corrected at the time. It is corrected here, and the correction is recorded rather than made silently, because a document whose whole claim is accuracy has to say when it was inaccurate.

Reading measurement, which is not device storage

One thing that people reasonably expect to find in a notice like this is not on the phone at all, so it is cross referenced here rather than left out.

When a post is on your screen, either at least half of it or at least 220 pixels of it, for one second, Ya Habibi sends that post's id to the server and records that you saw it. It is one record per person per post per day, no matter how many times the post passes your screen. It is stored server side in app_private.post_views and is deleted after 90 days by a scheduled maintenance job.

That is a server side store, so Article 5(3) does not apply to it. It is processing of personal data under the UK GDPR and it is dealt with in the privacy policy, which is where its lawful basis and its retention period belong. It is mentioned here only so that nobody reads this notice, sees no view tracking in it, and concludes that nothing is measured.

How to clear what is on your phone

Signing out

Sign out is in the profile menu, and it shows a sheet telling you which half stays and which half goes before you confirm it.

Sign out removes: the Supabase session token, your cached profile and all identity keys, your gender flag, the staff flag, pending profile edits, the onboarding flag, your whole conversation list, every per conversation message cache, the feed cache, the local feed posts and replies, your following list, and your circle membership keys. It works by sweeping the key and value store and removing everything that is not on a short, deliberate keep list, so any store added to the app in future is cleared by default rather than by somebody remembering to add it.

Sign out keeps: the place fix, the prayer calculation settings including sect and madhab, the Quran settings and reading position, the notification settings and the delivery ledger, intro.seen, the theme, and the prayer tracker.

Sign out does not touch: the two gazetteer files in application support, or any prayer alarm your phone has already scheduled.

Turning notifications off

Turning prayer alerts off in the app cancels the alarms your phone is holding. The delivery ledger entries age out on their own after 30 days.

Deleting the app

Deleting Ya Habibi removes the entire app sandbox. That means everything in this document without exception: the keys sign out keeps, the prayer tracker, the gazetteer copy, and any scheduled alarms. Your prayer tracker has no server copy, so deleting the app deletes it permanently and it does not come back when you reinstall.

Deleting your account

That is a different action with a different effect, and it is described in the privacy policy. In short: "Delete my account" in the profile menu closes the account immediately and queues the erasure of your data on the server, each part of it at an independently randomised moment within 48 hours. It does not clear this phone. Sign out or delete the app for that.

What still needs a solicitor

These are the decisions in this document that a qualified solicitor has to make before Ya Habibi launches. They are not stylistic. Each one changes either what the app does or what this notice is allowed to say.

1. 1.The two remaining strict necessity judgement calls. A solicitor has to decide whether the message caches and the feed caches fall inside the regulation 6 "strictly necessary" exemption, or whether either requires consent before it is written. If consent is required, the app needs a consent step it does not currently have, or the item has to be dropped. This notice answers both, and the two answers are different: it defends the message caches as necessary for the service you asked for, and it does not defend the feed caches, which it says belong behind a switch that has not been built. The third judgement call, the openedApp field, now has a route that did not exist when this document was first written: the statistical purposes exception added in February 2026, which needs an objection switch that has not been built.

1. 1.Whether an app that stores nothing except strictly necessary items still needs a first run notice. Ya Habibi currently shows no storage notice at all. If everything above really is strictly necessary, none is required. If any item is not, one is. That decision cannot be made independently of point 1.

1. 1.The sign out keep list, in law rather than in design. Keeping the prayer tracker, the place fix and the sect and madhab setting on the device after sign out is a deliberate design promise made in writing in the app. A solicitor should confirm that continuing to hold religious belief information on a device after the account that set it has signed out is defensible, and whether the correct answer is instead to offer an explicit "clear everything on this phone" action alongside sign out. Note that the prayer tracker has no server copy, so any decision to clear it on sign out destroys data permanently.

1. 1.The interaction with the age position. A date of birth is now collected on the server and the Ummah is closed to under 18s by a server rule, but the field is not yet in the clients and existing accounts were never asked, so today a new account is created without one. Storage rules bite harder where children are involved, both under PECR and under the ICO's Age Appropriate Design Code, and a service that cannot say whether its users are children cannot say the Code does not apply to it. This is called out in the privacy policy, in the terms and in the community guidelines as well. It needs a build and a decision, not a document.

1. 1.Whether this notice has to be reachable before sign in. The whole app sits behind a sign in, including prayer times, the Quran and the qibla, which need no account and no network. Several of the keys in the first table are written by those features. A solicitor should say whether information about storage has to be available to somebody who has not yet created an account, and if so, where it has to appear: in the store listing, on a website, or on the sign in screen itself.

1. 1.Whether the `messages.thread.<id>.v1` caches need to be encrypted at rest rather than merely sandboxed. They hold private conversations in the clear. The sandbox protects them from other apps, not from someone holding an unlocked phone. This is a security decision with a data protection by design dimension under Article 25 of the UK GDPR, and it is a build decision as much as a legal one.

1. 1.The identity of the controller, which is now settled. The controller is DAPPER TRADING LTD, registered in England and Wales, company number 8800299, trading as Ya Habibi, at Oak House, Reeds Crescent, Watford, WD24 4QP, United Kingdom. That is stated in the footer of this notice, in section 1 of the Privacy Policy and in clause 1 of the Terms of Use. Three things behind it are still open, none of them is a drafting question, and each is answered here with the position as it stands rather than left blank. The ICO registration: Ya Habibi is not yet registered with the Information Commissioner's Office. Registration is being completed. A representative in the European Union under Article 27, which on the face of it is required: Ya Habibi has not yet appointed a representative in the European Union under Article 27. Until it does, people in the EU should write to support@ya-habibi.co.uk. Whether there should be a contact point for data protection questions separate from support@ya-habibi.co.uk, which is still the only address in the app: Data protection enquiries go to support@ya-habibi.co.uk.

1. 1.The two websites. cookies.md takes the position that neither ya-habibi.co.uk nor app.ya-habibi.co.uk needs a consent mechanism, because nothing on either of them falls outside the exceptions. That is a separate assessment from this one and it should be confirmed separately, because the penalty band for getting a regulation 6 question wrong changed in February 2026. The two positions no longer agree, and the disagreement is new to this version. This notice now says the feed caches fall outside the exceptions and belong behind a switch, while cookies.md says nothing on either website falls outside them. app.ya-habibi.co.uk is the phone app's own Flutter code compiled for a browser, so an answer that is right for those caches on a phone is the same answer in a browser, and cookies.md neither lists those keys nor accounts for them. Reconciling the two is part of this decision rather than a separate one.

Version history

2026-08-25. The version in force.

2026-08-14. Superseded.

Who publishes this document

Ya Habibi is a trading name of DAPPER TRADING LTD, a company registered in England and Wales, company number 8800299. Registered office, which is also the address for service of any legal notice: Oak House, Reeds Crescent, Watford, WD24 4QP, United Kingdom. VAT number 190396586. Ya Habibi is part of the Webmasters LDN group, webmastersldn.com, which is also a trading name of the same company.

Contact: support@ya-habibi.co.uk, or in writing to the registered office above.

*Prepared 25 August 2026 for review by a qualified solicitor. Not legal advice.*