The short answer
A local-first weight tracker keeps its working database on your device and does not require a vendor account or proprietary server to perform its core job. That is stronger and more specific than simply saying an app “cares about privacy.”
Weight history deserves a clear data boundary
Body-weight records are sensitive, health-adjacent personal information. A useful privacy explanation should identify the boundary around that information rather than relying on a broad promise.
For WeekScale, the boundary is the mobile device and the platform services the device owner has enabled. There is no WeekScale account or WeekScale-operated cloud database.
What offline really means
“Offline” is only meaningful when it is specific. For a weight tracker it should mean a handful of concrete behaviors:
- The app can do its core job without any server.
- No account is required to use it.
- No analytics, advertising, or AI service receives your data.
- The network permissions and SDKs match the privacy promise.
WeekScale is built to those four points. It is a local-first app, which is a stronger and more specific claim than simply saying it “cares about privacy.”
WeekScale's data map
| Data or action | Where it goes |
|---|---|
| Weight entries | The app's private database on the device. |
| Units, week start, graph, and reminder settings | Private preferences on the device. |
| Android internet access | Not granted — the app has no internet permission. |
| iOS network requests | None. No direct network requests and no third-party runtime dependencies. |
| CSV import | Read on the device from a file the user selects. |
| CSV export | Created only after a user action, then shared with an app the user chooses. |
| Reminder scheduling | Handled through local mobile operating-system facilities. |
| Android system backup or device transfer | Potentially handled by Android and the user's selected backup provider. |
| Apple device or iCloud Backup | May include the iOS app's private data, depending on the user's Apple backup settings. |
No account, analytics, advertising, or AI processing
WeekScale does not need an identity profile to calculate an average. The iOS and Android apps have no account system, advertising SDK, analytics SDK, remote crash-reporting SDK, proprietary synchronization service, or AI model.
Android does not grant WeekScale internet permission. That is an operating-system-enforced constraint. The iOS app makes no direct network requests and contains no third-party runtime dependencies, but iOS does not offer an equivalent general internet permission that an app can decline.
The iOS app stores entries with SwiftData and explicitly disables CloudKit app synchronization. It does not access HealthKit or other sensitive device data.
Local-first does not mean “never included in a backup”
Offline is a boundary, not a magic promise. WeekScale keeps the boundary strong; what you do with your own data is up to you.
Android system backup and device transfer are intentionally enabled. Depending on the device, Android version, account settings, and backup transport, the app database and preferences may be copied through an Android-managed service.
That is not WeekScale cloud synchronization, but it is still a way data can leave the physical device. A credible privacy statement should disclose the distinction. Android documents the platform mechanism in its Auto Backup guidance.
On iOS, Apple-managed device or iCloud Backup may include the private SwiftData store and preferences. CloudKit app synchronization remains disabled. Apple explains how users control this separately in its iPhone backup guidance.
Mobile platforms also sandbox applications to restrict access to each app's private data. Apple describes its platform-level approach in the Apple Platform Security guide.
Your history should not be trapped
Local storage is only one part of ownership. WeekScale can import common CSV, TSV, and text files, and can export the complete recorded history as CSV through the system share sheet.
An export is sensitive because it contains weight history outside the app's private database. Once shared to another application, drive, email account, or person, that destination's privacy practices apply. The benefit is that the choice remains explicit and user initiated.
The honest tradeoffs of local-only storage
- There is no WeekScale password to reset and no vendor account to recover.
- There is also no WeekScale server that can restore history after data loss.
- Automatic multi-device synchronization is not available.
- Users are responsible for platform backup settings and optional CSV copies.
- Support cannot inspect or repair a private weight database remotely.
Those constraints are deliberate. They reduce convenience in exchange for a smaller data footprint and a much simpler trust model.
A privacy checklist for any weight tracker
- Is an account required?Ask whether the feature actually needs identity or cloud storage.
- Where is the working database?Look for a concrete answer such as private on-device storage.
- Which network permissions and SDKs are present?Analytics, ads, crash reporting, and AI services can each create another data path.
- Can you export everything?A complete, readable export reduces lock-in.
- What does the operating-system backup do?Local apps can still participate in system-managed cloud backup or device transfer.
- Does the privacy claim match the implementation?Specific technical constraints are more meaningful than slogans.
For the implementation-specific version of these answers, read the WeekScale privacy notice.
A deliberately small data footprint
Track the trend, not the user.
No WeekScale account. No proprietary cloud. No advertising, analytics, or AI.
Join the WeekScale beta