The business model determines the architecture
Most "free" apps are not actually free. They are exchanges: your attention and personal data for features. The ad SDK is not an afterthought — it is the product. Every session in the app is an opportunity to build a profile, target an ad, and optimise for engagement rather than outcome.
Mobile Squad's apps are not that. The business model is software: you pay once (or use the free tier) and you get the app. There is no advertiser to report to, no engagement metric that matters to revenue, and no incentive to keep you in the app longer than the workout actually takes. This is not primarily an ethical stance — it is a consequence of monetising software rather than attention. The architecture follows the business model.
What "no tracking" actually means in code
Privacy policies are easy to write. Architecture is harder to fake. Here is what the absence of tracking looks like at the code level in Mobile Squad apps:
No third-party ad SDKs
Ad SDKs (AdMob, Meta Audience Network, ironSource, etc.) don't just show ads — they fingerprint the device, read installed app lists where permitted, build cross-app profiles, and report this data to their networks. Including an ad SDK means including its data collection behaviour regardless of what your privacy policy says. Mobile Squad apps contain no third-party ad SDKs. If you decompile the APK, you will not find AdMob, Meta, or any equivalent dependency.
No analytics that identify individual users
Firebase Analytics, Mixpanel, Amplitude, and similar tools typically assign a persistent user identifier and log behavioural events tied to that ID. That data profile — what you tapped, when, how many times, in what order — is owned by the analytics vendor and subject to their terms, not yours. Mobile Squad apps do not include user-level analytics SDKs. The studio uses Firebase Crashlytics for crash reporting (which collects minimal device metadata for debugging) but not Firebase Analytics or equivalent behavioural tracking.
Local-first data storage
Your workout logs, rehab session data, and video clips are stored in your app's private local storage — not on a Mobile Squad server by default. The data architecture makes surveillance structurally difficult rather than just policy-prohibited: you cannot leak data from a server that does not receive it. On Android, this means Room database (SQLite) in the app's private data directory, inaccessible to other apps without root access. Cloud sync, where it exists, is explicitly opt-in and uses end-to-end encryption.
What Google Play requires
Publishing on Google Play does require some interaction with Google's infrastructure — play billing, in-app review APIs, and the Play Core library. These are platform-level services that are impossible to avoid on Android without sideloading. They are documented in each app's Google Play privacy policy, which is linked from the store listing. This is the minimal necessary surface area. There is no Mobile Squad analytics layer on top of it.
Why offline-first matters for privacy
Apps that require a network connection to function have a structural incentive to collect data: if the app must talk to a server to load your plan, show your history, or complete a session, that server sees your usage patterns. Offline-first design removes this incentive. When Personal Trainer, Tennis Elbow Oracle, and Golf Elbow Oracle load plans from local storage and save sets to a local database, there is no server interaction to log.
This is not just a privacy feature — it also makes the apps faster, more reliable in dead zones, and immune to server outages. The privacy benefit is a byproduct of a better architecture. Good design and good privacy often coincide when the business model aligns them.
The pay-once model and what it prevents
Subscription and ad-supported models share a structural problem: they require continuous engagement to justify recurring cost. A user who achieves their goal and stops using the app is a churn statistic or a lost impression. This misaligns developer incentives with user outcomes: you want your app to work so well that users stop needing it; the subscription model wants users who keep paying indefinitely.
The pay-once model eliminates this tension. Once you've paid for VIP, the developer's interest is that the app works well and is worth recommending — not that it keeps you engaged. The features in the app are there because they improve outcomes, not because they increase session length or open rate. This alignment also shapes what data gets collected: if engagement metrics don't drive revenue, there is no reason to instrument them.
What we do collect
Transparency requires stating what does happen, not just what doesn't:
- Firebase Crashlytics — when the app crashes, a report including the stack trace, device model, OS version, and app version is sent to Firebase. This report does not include your workout data or personal information. It is used exclusively for debugging. You can opt out on Android via the device's data collection settings.
- Google Play billing — when you make an in-app purchase, Google Play processes the transaction. Mobile Squad receives confirmation that a purchase was made and its type. Payment details remain with Google.
- Optional cloud sync — if you opt in to cloud backup (available in Personal Trainer), your workout data is encrypted before leaving your device and stored in Firebase Cloud Firestore under your account. This is entirely optional and disabled by default. You can delete your cloud data from within the app.
- This website — mobile-squad.com uses Google Analytics (GA4) for aggregate page view data. No user-level profiling is done with this data. Cookie consent is not required because no cross-site tracking identifiers are set.
The enforcement problem — and why architecture beats policy
Privacy policies are legally binding documents, but they are enforced after a breach, not before. A policy that says "we don't sell your data" can be changed, violated, or made irrelevant by an acquisition. Architecture that never collects the data cannot leak it. This is the principle of privacy by design rather than privacy by policy.
When a user asks "how do I know you're not tracking me?", the honest answer is: look at the code. The APK is decompilable. The dependency list is auditable. There is no obfuscated AdMob call, no analytics ping to a third-party endpoint, no background process phoning home. The architectural constraint makes the policy claim credible in a way that a policy alone cannot.
What privacy-first means for the future of Mobile Squad
Privacy-first is a constraint that compounds. Once you build an offline-first, no-tracking architecture, every future feature gets evaluated against it. Adding a leaderboard means building local comparison rather than server-side ranking. Adding AI features means running models on-device or being explicit about what leaves the device. The constraint is not a burden — it narrows the design space in useful ways and creates a product identity that is genuinely differentiated in a market where most apps make the opposite choice.
The users who choose Mobile Squad apps tend to value this explicitly. They are the ones who turned off Google account sync on their phone years ago, who read privacy policies, who notice the absence of an "allow notifications?" prompt on first launch. Building for this user makes the product better for everyone.
Apps built on these principles
- Personal Trainer — offline gym tracker. All workout data stored locally. Optional encrypted cloud backup.
- ReplayR — sideline replay camera. All video stored on-device. No cloud upload, no account required.
- Tennis Elbow Oracle — lateral epicondylitis rehab. All session data local. No account required.
- Golf Elbow Oracle — medial epicondylitis rehab. All session data local. No account required.
- Firepulse — Firebase monitoring. Reads-only from your Firebase project via your credentials. No data stored on Mobile Squad servers.
More detail on the specific commitments per app is at Mobile Squad's Privacy Commitment.