Effective date: 2026-06-21 Last updated: 2026-06-21
This page describes how the Sudoku mobile app
(com.catpawprint.sudoku, published by CatPawPrint) handles your
information.
Plain summary: the game itself runs entirely offline — your puzzles, times, and progress live only on your device. The app does send a limited stream of diagnostic (crash) data and a small set of anonymous product-usage events to Google so we can measure stability, fix bugs, and see which features get used, and it shows rewarded ads through Google AdMob if you choose to watch them. We do not ask for your name, email, contacts, photos, or location, and we do not build a profile of you that can be linked back to your real identity.
To remember your progress between sessions, the app writes the following to a local database on your device. None of this is uploaded to our servers or to anyone else:
| Storage key | What it contains |
|---|---|
sudoku_autosave_v1 |
Current puzzle in progress, elapsed time, mistake count |
sudoku_daily_v1 |
Daily Challenge history (date, completion, time) |
sudoku_stats_v1 |
Wins per difficulty, best times, streak counters |
sudoku_settings_v1 |
Theme, sound / haptics toggles, hint-confirm preference |
sudoku_compute_v1 |
In-game energy balance + lifetime earn / spend totals |
sudoku_first_launch_v1 |
Whether the onboarding tutorial has been shown |
You can erase all of the above at any time:
The app uses three Google services. All three operate on a device-scoped pseudonymous identifier — none receive your name, email, phone, contacts, or any directly identifying information, and none are linked to your other devices or your Google account.
If the app crashes, it sends a stack trace plus device model / OS version / app version to help us reproduce and fix the bug. The report uses a pseudonymous identifier; no PII is captured. Reports are accessible only to the development team and are retained for 90 days.
Reads a small set of feature-flag values from Google’s servers
(currently one: sudoku_ads_enabled — see section 3). This is a
one-way fetch — the app pulls config; nothing about you is sent.
The app records a small set of product-usage events so we can see which features are used and improve the game — for example, how many players finish the tutorial, which difficulty levels get solved, whether the optional helper / hints are used, and whether a “shared puzzle” gift is opened. We log only four custom events (onboarding finished, puzzle solved, rewarded-ad watched, gift shared / opened) plus the standard session and retention counts that Firebase collects automatically. Each event is tied to a device-scoped pseudonymous app-instance identifier — not your name, email, or any directly identifying information — and is not used to track you across other apps or websites. Analytics runs only in released builds; developer test runs are excluded.
When the weather greeting is enabled, the app requests current conditions from our weather endpoint. The request’s IP address is used transiently, at our edge to estimate an approximate, city-level location so the reading roughly matches where you are. We do not use device GPS, we do not store your IP or location, and the rounded coordinates we forward to our weather-data provider (MET Norway) carry no identifier. If the feature is off or the request fails, the app shows a time-of-day icon instead and makes no such request. Weather data is © the Norwegian Meteorological Institute (MET Norway / Yr), used under CC BY 4.0.
The game-over screen and the “out of energy” sheet offer an optional “Watch ad” button that lets you earn extra in-game energy by watching a rewarded video ad. Ads are served by Google AdMob; you only see one when you tap that button, and the rest of the app contains no ads (no banners, no interstitials, no between-screen ads).
To deliver ads, the AdMob SDK may collect:
This data is governed by Google’s privacy policy.
On the first launch after onboarding, iOS asks whether you want to allow tracking. This is Apple’s standard App Tracking Transparency prompt.
You can change your choice at any time via iOS Settings → Privacy & Security → Tracking.
If you never tap “Watch ad”, no ad is ever shown and AdMob does not collect anything from your device. We also operate a server-side kill-switch (Firebase Remote Config); if we need to pull the entire ad system offline globally, the buttons disappear without an app update.
The app does not request any of these:
The app does request network access — required for the crash-reporting, remote-config, and ad services above.
The app is not directed at children under 13. We do not knowingly collect personal information from anyone, including children. The Firebase and AdMob SDKs receive only the pseudonymous identifiers described above; we do not link them to any real-world identity.
If you are a parent or guardian and believe your child has been shown personalised ads or that an identifier tied to your child has been collected, please contact us using section 9 and we will work with Google to delete the associated data.
Depending on where you live, you may have rights to access, correct, port, or delete the limited information described above:
To exercise any of these rights, email us (section 9) with the request. Because the app stores data on your device under a pseudonymous identifier we cannot map back to a person, we may ask for the device’s advertising ID and app install date to locate the relevant records on the Google side.
Local data is sandboxed by the OS and not readable by other apps. Data sent to Google travels over HTTPS. Google operates the backing systems and is contractually bound to the standards described in its own policies.
Aside from the optional weather endpoint described above — which processes the request IP transiently at the edge to estimate a coarse location and stores nothing — we do not run servers of our own; nothing else in the app passes through CatPawPrint infrastructure.
We may update this policy from time to time. The effective date at the top of this page will be revised, and any material change (new SDK, new data category, new third-party recipient) will be flagged in the app’s release notes before the relevant build ships.
Continued use of the app after a change indicates acceptance of the updated policy.
Questions, concerns, or data-related requests — including the GDPR / CCPA rights above:
We aim to respond within 7 business days.