Ownspend · Legal

Privacy Policy

Last updated: 22 September 2026

1. Two ways to use Ownspend

Ownspend has two modes, and they have very different privacy footprints:

You are in Solo mode unless you deliberately create or accept a Shared Wallet invite. You never see a sign-in screen until that moment.

2. Solo mode — no account, and none of your money leaves the device

Solo mode means no account and no sync of your finances. It does not mean the app is silent: a small amount of non-financial data is sent for crash reporting, notifications and product measurement, and it is itemised in sections 5 and 8. Nothing in any of it is a transaction, an amount, a note, a merchant, a category, a budget or a goal.

• No account creation, no sign-in, and no server contact for your financial data.
• Your transactions, categories, budgets, goals, and wallets are stored locally on your device using Apple’s SwiftData framework.
• The cloud sync services (Firebase Authentication, Firestore sync, Functions, Storage and Cloud Messaging) are not started for a solo user — they are loaded only the first time you opt into sharing. Crash reporting (section 5), the notification device record (section 8) and the product counters (section 5) are separate from sync and do run for everyone.
• There is no iCloud sync and no cross-device sync of your personal data. Your records stay on the device you entered them on; use the in-app CSV/JSON export if you want to move them yourself.

3. No bank linking, ever

Ownspend does not connect to your bank, does not use Plaid or any aggregator, and never asks for banking credentials or card numbers. You enter your transactions yourself. This is true in both Solo and Shared modes.

4. Shared Wallet — what the cloud receives

When (and only when) you create or accept a Shared Wallet, some data is sent to and stored in Google Cloud (Firebase) so that you and the one person you invite can co-manage the same records. This is what changes, and exactly what is involved.

4.1 Signing in

• Sharing needs real accounts so two people can be told apart and invited securely. You sign in with Sign in with Apple (primary on iPhone), or Sign in with Google.
• With Sign in with Apple you may use Hide My Email, in which case we receive Apple’s private relay address instead of your real one.
• Sign-in happens only when you start or accept a share. Solo users never sign in.

4.2 What data syncs to the cloud

For a shared wallet, the following is synced to Google Cloud Firestore:

• Shared financial records — the shared wallet and its transactions (amounts, notes, dates, income/expense flags), its categories, budgets, and goals. These are the records you and your partner intentionally share.
• Account identity — the user identifier created by Sign in with Apple or Google (a Firebase user ID), and the email address returned by your sign-in provider (which may be an Apple private-relay address). Used to authenticate you and manage who belongs to the share.
• Membership records — who the members of the share are, their roles (owner or member), display name, and when they joined.
• The place an expense happened, if you added one — a transaction can carry a place name and, if you tapped “Use my location”, the exact coordinates of where you were. On a shared wallet those sync to the other member along with the rest of the transaction, which is why the App Store label lists Precise Location as linked to you. See section 4.8 for how location works and how to avoid it entirely.
• Receipt photos in the shared wallet — if you attach a receipt photo to a shared expense, the image is uploaded to Firebase Storage so the other member can see it. Receipts on your personal wallets are never uploaded.
• Device notification token (optional) — if, and only if, you turn on “partner added a transaction” push notifications, a Firebase Cloud Messaging token is stored so we can deliver those notifications to your device. If you leave notifications off, no token is collected.

4.3 What stays on your device even with a Shared Wallet

• Your personal wallets and their transactions, categories, budgets, and goals — never uploaded.
• App settings, onboarding state, and streaks. (Your purchase status is not purely on-device — see section 7.)
• Receipt photos attached to expenses in your personal wallets. (A receipt attached to an expense in a shared wallet is uploaded to Firebase Storage so the other member can see it — see 4.2.)

The privacy boundary is at the wallet level: shared wallets sync; personal wallets do not.

4.4 Who your shared data is shared with

• The person you invite. The whole point of a Shared Wallet is that the one member you invite can see and edit the shared records. Do not share a wallet with anyone you would not want to see everything in it.
• Google (Firebase / Google Cloud), as our sub-processor. Google stores and transmits the shared data on our behalf so the feature can work. Google processes it under our instructions and its own security and privacy commitments; we do not authorize Google to use your shared-wallet content for its own purposes.
• We do not sell your data, and we do not share it with advertisers, data brokers, or anyone else. There are no advertising or tracking SDKs in the app.

Our sub-processors are listed in section 12.

4.5 Access control

• Only the invited members of a share can read or write its data, enforced by server-side security rules. A device cannot add itself to a share; only our server-side invite function can add a validated member.
• Invite links are single-use and expire after 72 hours.

4.6 Retention and deletion of shared data

• Shared records are retained while the share is active. When a wallet is deleted, or you delete your account, the affected data enters a 30-day recovery window and is then permanently deleted from our cloud by a scheduled process.
• Leaving a share: when you leave, you keep a local copy of the records you last synced; the cloud share continues for the remaining member unless it too is deleted.
• Deleting your account: Settings → delete account removes your membership from every share. If you are the sole owner of a share, that share is scheduled for deletion after the 30-day grace period.

4.7 Getting your data out (portability)

Either member can export the shared wallet’s records to CSV or JSON at any time, from within the app. A user can always walk away with a copy of any data they could see.

4.8 Location

Ownspend can tag an expense with where you spent, so you can see it on a map. This is entirely optional and never automatic:

• Location is requested only when you tap “Use my location” while adding an expense — never at launch, never in the background, and never speculatively. iOS asks your permission the first time you tap it.
• We ask for While Using the App permission only. We never ask for “Always”, and Ownspend cannot read your location when it is not open.
• We keep the exact coordinates, not an approximate area, because the point of the feature is to show the spot on a map. We also store a place name looked up from those coordinates.
• On a personal wallet the coordinates stay on your device, like the rest of your records. On a shared wallet they sync to the other member with the transaction — so treat tagging a shared expense as telling that person where you were.
• You can decline, and everything else keeps working: the place field is just a text box you can type into, and you can revoke the permission in iOS Settings at any time.
• One limitation, stated plainly: you can clear the place while you are entering an expense, but the app has no way to change a transaction’s place once it is saved, so removing a place from a saved transaction means deleting that transaction. (Other details can be edited after saving; the place cannot.) We intend to fix that; until we do, this is the honest position.

5. Analytics, crash reporting and product measurement

Crash reporting. Ownspend uses Firebase Crashlytics so that a crash on any device — solo or shared — can be diagnosed and fixed. A crash report contains a stack trace, your device model, the OS version and an app-generated installation identifier. It never contains your transactions, amounts, notes, categories, wallets, or anything you typed into the app.

Usage analytics. Firebase Analytics is present in the app but collection is switched off when the app launches and stays off unless it is enabled by a remote configuration flag. If it is ever switched on, it records anonymous events about how features are used — never your financial data, and never anything that identifies you personally. We do not build advertising or behavioral profiles.

Product measurement. Two small first-party counters write to our own Google Firestore project. Neither ever receives a transaction, amount, note, merchant, category, budget or goal.

• “More from us” counters. The Settings screen shows cards for our other apps. When those cards appear, when you tap one, and when the app later notices you installed one, we record which app was shown or tapped, where on screen, your install identifier (section 9), and your app version, build, OS version and language. This measures whether advertising our own apps works. It happens without any action from you beyond opening Settings, and it is why the App Store label lists Product Interaction. It is still not cross-app tracking in Apple’s sense: nothing is shared with another company and nothing is joined to data from anyone else’s apps.
• Feedback form. If you use Settings → Suggest a feature, we receive what you wrote and its category, whether you are a Pro user, what you indicated you would pay, your install identifier, and your device model, OS version and language. If you fill in the optional reply address, we receive that too, solely to answer you. This one is sent only when you choose to send it.

6. Advertising and tracking

There are no ads, no advertising SDKs, and no cross-app or cross-site tracking in Ownspend. We do not use the advertising identifier (IDFA), so the App Tracking Transparency prompt does not apply.

7. Purchases

Pro purchases — a one-time lifetime unlock, or a monthly or yearly subscription — are processed by Apple through the App Store using StoreKit 2, with RevenueCat managing entitlement status. We never see your card number or payment details; Apple handles payment.

Your purchase status does leave the device, so we should be exact about it. The RevenueCat SDK starts with the app for every user and checks whether this install has Pro. If you have signed in for Shared Wallet, RevenueCat also notifies our server when your entitlement changes, and we store the result against your account, because the shared-wallet features you get depend on it: whether you are entitled and to what tier, when it expires, which product it was, and whether the purchase was a real one or an Apple test purchase. What we store is the entitlement, never a card number, and never what you bought elsewhere. Your Pro flag is also included if you send feedback (section 5).

8. Notifications

• Local reminders (for example, budget reminders) are scheduled on your device by iOS and involve no server at all.
• Shared Wallet “partner added a transaction” push notifications are opt-in and delivered via Firebase Cloud Messaging. If you do not opt in, no Firebase token is collected (see 4.2).
• Reminders and app news from us. Ownspend registers a device record with Engagement Center, a notification service we run ourselves at engage.puzzpics.com — it is our own server, not an advertising network. It lets us send you an occasional nudge to log what you spent, or tell you about a new feature. The record holds: a randomly generated device identifier (section 9), the Apple push token, your platform, OS version, app version, language, time zone, whether you allowed notifications, and whether you opted in to marketing messages. It never contains your transactions, amounts, notes, merchants, categories, budgets, or anything you typed into the app, and no push we send ever carries a figure.
  
  To be exact about when this happens: the record is created when the app starts, not when you accept notifications. If you decline notifications, or are never asked, the record still exists — it simply carries no push token, and is marked as not authorised, so nothing can be sent to you. Allowing notifications adds the token that makes delivery possible. Turn notifications off in iOS Settings, or marketing messages off in the app, and we stop sending; email us (section 14) to have the record itself deleted.
  
  One related thing this sends: if you tap one of our notifications, the app tells Engagement Center that a notification was opened, with the device identifier, the time, and which message it was. That is how we know whether a message was worth sending. It carries nothing else, and nothing about your finances.

9. Device identifiers

We do not collect the advertising identifier (IDFA), and we do not use the device vendor identifier (IDFV) to track you. We do not track you across other companies’ apps or websites, and we never join your data with anyone else’s (section 6). The one thing worth naming, because “no cross-app anything” would overstate it: the “more from us” cards ask iOS whether our own other apps are installed on this device, so we do not advertise something you already have and can tell whether a recommendation worked. That is a yes/no question about our apps only. Several identifiers exist, and each is limited to one job. The ones we create and use directly are:

• Notification device identifier — a random identifier the app generates for itself the first time it registers with Engagement Center (section 8), and stores on your device. It is not derived from your hardware, your Apple ID, or any Apple identifier, and it is not shared with anyone. Because it persists and is how a notification reaches your particular device, we declare it on the App Store as a Device ID that is linked to you and used for developer marketing — even though we never join it to data from other companies. Deleting the app discards it.
• Install identifier — a second random identifier the app generates for itself and stores on your device. It accompanies the product counters and the feedback form described in section 5, so that a suggestion and the person who sent it can be matched to a reply, and so a count is not double-counted. It never touches your finances, and it is a different value from the notification identifier above. It is not anonymous in every case, though, and we would rather say so than imply otherwise: if you choose to put a reply address in the feedback form, that address and this identifier sit in the same record, which makes the other records carrying it associable with you. That is exactly why we declare it on the App Store as linked to your identity. Deleting the app discards it.
• Firebase user ID — account-derived, created when you sign in for Shared Wallet, and the identifier associated with your cloud data.
• Crash installation identifier — app-generated, carried by crash reports only, described in section 5.

Two more are created by services we use rather than by us. RevenueCat mints an app-user id when the app starts, so it can tell whether this install has Pro; it begins anonymous, but if you sign in for Shared Wallet the app links it to your account id, so from then on it is not anonymous. And if you turn on Shared Wallet notifications, Firebase Cloud Messaging issues a delivery token. Both are covered by those providers’ own terms, listed in section 12.

10. Children

Ownspend is rated 4+ but is a personal-finance tool that is not directed to children under 13. Shared Wallet requires an account and is intended for adults; see the age requirement in the Terms of Use.

11. Legal bases and your rights (GDPR / CCPA)

• Solo users: none of your financial data reaches a server, so for your transactions, budgets, wallets and goals there is genuinely nothing for us to access, correct or delete — they exist only on your device, and deleting the app deletes them. We do hold the limited non-financial records described in sections 5 and 8 (the notification device record, the product counters, any feedback you sent, and crash reports). Those are personal data, and the basis differs by purpose rather than being one blanket claim:
  • Consent for anything promotional. Notification permission is asked for in iOS, marketing messages are a separate switch inside the app, and turning either off withdraws that consent. Declining means nothing is ever sent to you. Note that the device record itself is created before any of those choices are offered, so we do not claim your notification permission as consent for storing it — that record exists because it is necessary for the notification feature to function at all, and you can have it deleted on request (section 14).
  • Legitimate interest for keeping the app working and knowing whether it is useful: crash reports, the “more from us” counters, and holding the device record itself so the notification feature can function. You have the right to object to anything we do on this basis — see the rights bullet below; if you object we will stop and delete the records.
  • Consent again for feedback, which exists only because you chose to send it.
  You can ask us to delete any of it by emailing us (section 14).
• Shared Wallet users, legal bases (GDPR): we process shared-wallet data to provide the sharing service you requested — the lawful basis is performance of a contract (delivering the Shared Wallet feature you signed up for) and, for optional push notifications, your consent. You may withdraw consent to notifications at any time in settings.
• Your rights: access, correction, deletion, portability, and — because some of the above rests on legitimate interest — the right to object to that processing, and to withdraw consent where consent is the basis. Deletion and export of your own records are available in-app (sections 4.6–4.7); for anything else, including objection and deletion of the device record or feedback, email us (section 14) and we will act on it.
• Controller/processor: for shared-wallet data, Moath Othman (the developer) is the data controller and Google (Firebase) acts as a processor / sub-processor under a data processing agreement.
• CCPA: we do not sell or “share” personal information as those terms are defined under California law, and we do not use it for cross-context behavioral advertising.

This section is a plain-language summary, not legal advice. Your statutory rights depend on where you live.

12. Sub-processors and third-party services

Apart from crash reporting (section 5) and notifications (section 8), solo mode uses only Apple frameworks on your device. The services below process data for Ownspend; all but Engagement Center are third parties operating under their own terms — Engagement Center is infrastructure we run ourselves.

Google’s handling of the data it processes for us is governed by the Google Cloud / Firebase Data Processing terms. Their privacy policies: Firebase, Apple, RevenueCat.

13. Changes to this policy

If we change what data is collected, we update the “Last updated” date and note it in the App Store release notes, and the App Store privacy label is updated in that same release. One honest exception to “only with an app update”: as section 5 describes, usage analytics are switched off at launch and could be switched on by a remote configuration flag without shipping a new build. If we ever turn that on we will say so here and in the label first.

14. Contact

Questions or requests (including data deletion or export help): email dark2torch@gmail.com. We usually reply within a business day or two.