App privacy policy.

Last updated: 3 November 2026

SwipeLess helps you interrupt endless feeds. To recognise a feed it has to look at what’s on your screen, and that’s the part you should be able to check rather than take on trust. This page says exactly what SwipeLess reads, what it keeps, and what it sends. Blocking and Work run on your phone. Your account can back up settings, game progress and daily totals to the SwipeLess server. Account sign-in uses Firebase Authentication. Optional purchases use Google Play; lifetime codes and recovery use the SwipeLess server, described below.

This is a test build. For support or a privacy/account-deletion request, contact getswipeless@gmail.com. The account-deletion steps and limits are explained below.

Phone access during setup

The first introduction explains blocking access, optional Android screen time and optional SwipeLess notifications one step at a time. Nothing is enabled by viewing the explanation. You choose whether to allow each access in Android, and the app checks the current status when you return. Not now skips a step without changing Android access. The accessibility explanation and Agree remain a separate step before opening Android's accessibility settings. You can read this policy from setup. Account backup is described separately from local blocking observations. Notification-reading, Do Not Disturb and scheduled-alarm access are requested only with their own features; they are not part of this initial setup.

The opening animation uses bundled, generated photos and fictional calls, posts and messages. It does not read contacts, messages, notifications or other apps to make those illustrations. Its bundled sounds combine original notification tones and short generated spoken phrases. After a quiet pause, a bundled female synthetic voice explains Blocks, Work mode and Stats. Playback is local; it does not use a microphone, speech service or voice download. Sound plays when the phone has normal audible media, with no call or other music already playing. The ringtone's silent/vibrate setting does not mute the tour; the media volume and mute setting do. Only Android's current audio-mode, media-active and volume/mute status are checked for that choice; these values are not stored or sent. SwipeLess stops the chaotic sounds at the quiet scene, then starts the separate explanation. Pausing, leaving or losing focus stops its own sounds and narration. It does not change the phone's volume, mute other apps or start them again. Reduced motion uses a quiet manual introduction. Temporarily hidden status/navigation bars return after the opening; Android's Home and Back gestures remain available.

Optional app PIN

You can protect the SwipeLess interface with a four-digit PIN in Settings. It is off by default and stays on this installation. A salted PIN verifier and limited failed-attempt counter are stored locally in an encrypted file with an Android Keystore key. The PIN is not stored as readable text, logged, sent to our server or included in account backups. Entering the background or changing account locks the interface again; blocking and Work continue independently. While the app lock is on, the main interface is protected from screenshots and recent-app previews. Temporary files you explicitly share remain governed by the sharing section below.

Before enabling a new PIN, link recovery to your verified SwipeLess account and confirm that account again with Google or its password. The server stores an opaque account/installation binding, short-lived recovery challenges and an opaque verifier identifier, not your PIN, PIN digest or locally stored PIN verifier. The identifier does not contain your PIN.

If you forget the PIN, SwipeLess can email a one-time 8-digit code to the verified email address of the linked account. The address comes from your verified sign-in at that moment and is used only to send that email through Brevo, an email service based in France. Our server does not store the address. It keeps a keyed hash of the code, its 15-minute expiry, the number of attempts (at most five) and whether it was sent, linked to the opaque binding. A correct code lets this installation choose a new PIN; it does not turn protection off in between. Signing in again, your phone PIN, pattern or biometric, or a friend cannot reset the SwipeLess PIN.

If you can't receive that email, you can ask SwipeLess support from the locked app while the linked account is signed in. The app shows a support code; the server keeps only a keyed hash of it with the request status and times, and emails a short notice to the account address. After verifying your account, support can approve a short-lived recovery authorization. The app checks for it and applies it when valid. This does not guarantee a support response time. Support records a short reason in an owner log, without your PIN, code or email address. Your blocks, Work, progress and lifetime stay as they are.

An existing PIN is kept on update; unlock it once to link account recovery. An unreadable local key/file stays protected rather than silently resetting. A new installation starts with this local app PIN off; restoring account data does not restore it. This does not prevent uninstalling the app.

Seven-day app choices

After you save a looser app block choice, that app cannot be loosened again for seven days. Within this period you can still block more: a strictly stronger choice does not start or restart the wait. A mixed change that allows more access on any point still counts as loosening. Existing local periods are kept. Each app has its own local timing record, separate from its usage counters. The record contains the app ID and wall-clock, monotonic-clock and boot anchors; it contains no screen or notification contents. Removing a rule does not remove its local change period. Websites follow the same seven-day period, per website. Work and Schedules stay independently editable. These timing records stay in this installation’s account profile and are not sent in account backups or shared with friends. Reinstalling or restoring on another phone does not restore this local change history. The current block settings themselves remain covered by account backup. No extra permission, SDK or server is used.

Optional impulse check

After an actual block, a short local journal can offer a voluntary check-in when you enter Blocks or Schedules within two minutes. It keeps one random event ID, a fixed category such as Reels, and timing anchors; no screen contents or extra usage history. The question is limited to once per 30 minutes. Choosing Yes pauses changes to Blocks and Schedules for ten minutes across app restarts. This journal and timer stay on this installation and are excluded from account backup and sharing. Existing protection and manual Work continue.

Optional Friends and personal profile

Friends is a new test feature. It requires separate server activation; seeing its screens does not mean a live friendship, recovery or notification has succeeded. Your verified account gets a separate opaque social identity, independent of paid access. Your installation signs requests with its own Keystore key. Firebase ID tokens stay in request memory and are not logged.

An invitation has a random secret, a seven-day expiry and explicit acceptance. The server stores only the secret's keyed digest. Opening a link or preview does not accept it. You can revoke your current invitation. Share only with someone you trust. No contacts are imported. The friend sees your chosen profile name and initial, never your account email or PIN.

An accepted friendship lets both people request and approve extra time and send challenges. There are no separate permissions for each friend; accepting an invitation does not start a challenge. You choose once in My profile which profile fields all current and future active friends may see. Sharing starts off, including for existing accounts after this change. Removing or blocking a friend stops profile access and cancels open and active server requests. Allow new invite only permits a new invitation; it does not restore an old friendship or request. Friends cannot recover an app PIN.

An extra-time request sends its app or exact host label, selected minutes, installation and an opaque revision of the applicable local rule. It does not send your complete settings, visited URLs, browsing history or accessibility screen content. Only your chosen helper can approve or decline. Requests expire after 15 minutes; approvals must be started within 15 minutes. Start issues one fixed deadline. Permanent settings are kept; Work, Schedules and other protection retain priority. This version offers only supported ordinary Blocks. Online active grants are rechecked about every 30 seconds; offline a valid grant can continue until its original deadline. Restarting the phone ends these local temporary grants early. No friend can freely edit another person's settings. Inbox and outbox records are stored.

A challenge sends the chosen apps from a fixed list of seven social apps, the duration and your friend's opaque identity. The invitation expires after 24 hours. Nothing closes until your friend accepts; then the same apps close on both phones until the same end time, and neither person can stop early. Removing a friend, signing out, switching accounts or restarting the phone does not end a running challenge: it is kept on the phone, outside your account profile, until it ends. Each phone counts how often a challenge app was opened anyway and reports only these numbers per app. Your friend sees your count and you see theirs; no screen time, visited content or accessibility screen content is sent. While your own invitation is open, the app checks for an answer about once a minute, later every five minutes, only while the screen is on.

Optional phone alerts use Firebase Cloud Messaging (FCM). After an existing Friends connection is resumed, the app can register its FCM token with the own server. The token is encrypted at rest and bound to the account, installation and binding revision. The server keeps token digest, encrypted token, key version, notification-enabled status, app version, Android SDK and last registration time. Tokens are not logged. Rotation replaces the old registration; sign-out and account changes clear local notification binding immediately and attempt server unregistration. Account deletion removes these registrations. Android notification permission and the Friends requests system channel control visible alerts; Do Not Disturb is not bypassed.

FCM carries only opaque event/request/recipient IDs and expiry. The receiving app checks its account binding and fetches the actual request through the authenticated API before showing a person's name, selected app and minutes. If that fetch fails, only a generic private request alert may appear. Notification contents are private on the lock screen. Push does not approve, start or extend time. Provider acceptance is not proof that a phone displayed a notification. Offline, force-stop and device power policies can delay delivery; the inbox remains available.

My profile uses the existing Android foreground-activity measurements for phone and social media averages. A baseline is frozen only after seven complete, reliable days. Where a reliable first SwipeLess start and sufficient own historical readings exist, it uses the seven days before that start. Otherwise it first looks for the earliest complete seven-day week within the available fifteen-day history of the same account and phone. This is labelled as a baseline week with its dates, not as proof of use before SwipeLess. If no complete week is available, it continues measuring. It does not invent an original start or missing history. Incomplete weeks show their measured-day count. The current daily average uses completed days; a percentage requires two separate, non-overlapping seven-day periods with matching definitions, source and time zone. Missing or partial days are not zero. The baseline and its measurement plan are stored separately from the rolling day cache. These are measurements, not proof that SwipeLess caused a change.

You can choose an optional personal goal from examples or write up to 120 characters, and choose which goal, milestone, time-with-SwipeLess and compact screen-time summaries appear on your own profile. These choices and the goal text are part of your private account settings backup when backup is enabled. These own-profile display choices do not change friend-sharing permissions. Separately, Share with friends can publish your chosen goal text, one generated milestone, time with SwipeLess, phone-use and social-media summaries to all active friends. Choosing to share your goal makes that self-written text visible to those friends. No sport, sleep or productivity achievement is inferred from the text or reduced screen time.

Saving sharing writes the chosen fields and the matching summary together. While My profile is open, summaries for already chosen fields may refresh automatically; there is no separate manual upload step. Unselected fields are removed from the published snapshot. Raw events, individual app details, Braintraining answers and notification content are not shared. Your Google profile photo stays private and is not uploaded to the Friends server. Back up / restore my baseline is a separate explicit owner-only action. It stores the available original start, time zone, installation source, baseline averages and measurement plan with the account, including after reinstall; friends cannot read that private archive. A good completed baseline is not overwritten by a new goal. Different phone sources are not silently combined into a comparison.

Social links, global sharing choices, shared profiles and private baselines stay until changed or account deletion. Expired invitations, PIN challenges and emailed PIN codes become unusable immediately. Emailed PIN codes are deleted 24 hours after they expire, closed support requests after 30 days and owner log entries after one year, in bounded batches. Expired requests, ended challenges and idempotency responses become eligible for removal after seven days, in bounded batches during subsequent authenticated changes; inactive server data may remain until then. Account deletion removes the social identity and dependent server records. Local profile data is kept, as described in the account-deletion section. Firebase Cloud Messaging is added within the existing Firebase project; no paid plan is activated.

Sharing a progress report

Stats lets you preview and export the selected report as an image or PDF. The file contains the visible period, chosen total or app label, daily screen-time readings and their quality, and any available comparison, with SwipeLess branding. It does not contain your account name, email, account/device identifiers or configured app list. Files are generated locally; SwipeLess does not upload or post them. Only after you choose Share does Android offer other apps temporary read access to that export. The app you then choose handles further sharing under its own policy. Save PDF writes to a destination you choose. Temporary export files are removed on a later export after 24 hours; copies you save or share remain with their destination.

Your SwipeLess account

In connected builds, SwipeLess asks you to sign in or create an account at first start, using Google or an email address and password. The account identifies you; signing in alone does not give lifetime access. Local protection works independently of account backup. The backup section below explains the settings and totals saved to your account and how to pause backup.

SwipeLess has no advertising SDK or developer-operated analytics service. INTERNET and ACCESS_NETWORK_STATE support Google Play Billing, account sign-in and the lifetime service, account backup and the optional Friends and PIN-recovery requests described above. Raw accessibility observations, notification contents and Android usage events are not uploaded.

Delete your account

In the app: Settings → Account → Delete account, then confirm your current sign-in with Google or its password. Without the app, email getswipeless@gmail.com and say which account it is; we first check that the account is yours, then delete it and confirm by email.

Deletion removes your SwipeLess sign-in account, your lifetime record and its recovery, your settings and progress backup, your Friends data (social identity, friendships, requests, shared profile and private baseline archive) and your push registrations. It does not remove app data on your phone, your Google account or Google Play purchases; cancel a subscription separately in Google Play. Cloudflare D1 recovery history can hold earlier states for up to seven days on Workers Free or 30 days on Workers Paid, Firebase removes remaining sign-in data within 180 days, and owner-held encrypted recovery archives are not rewritten, as described in the sections below.

Sign-in and SwipeLess lifetime codes

Google's account picker supplies a credential to Firebase Authentication. With email sign-in, your entered password goes to Firebase over HTTPS, never to the SwipeLess lifetime server. Firebase manages registration, verification and password-reset emails, and stores the sign-in session on your device so you can stay signed in. SwipeLess does not save passwords or copy tokens into its own logs/preferences. Google sign-in can provide basic profile data to Firebase; SwipeLess displays your email in Account and can use the first name from your existing Google profile for the Home greeting. This name is used in memory, not saved in SwipeLess’s own preferences or sent to the backup server. On your own profile, SwipeLess can load the photo supplied by your verified Google provider from Google’s photo service over HTTPS. It stays in memory while that profile is open, with initials as a fallback. The photo is not uploaded to SwipeLess’s server or shared with friends.

Firebase processes authentication data, including account credentials/email, its Android app ID and technical user-agent/IP information for security, service operation and abuse prevention. Its documentation describes logged IP retention of a few weeks and removal of other auth data from live/backups within 180 days after account deletion. See Firebase's privacy information and Google's privacy policy. Phone/SMS sign-in and Analytics are not enabled in this app. Google sign-in can supply profile data to Firebase even though SwipeLess only uses the greeting in memory. Firebase's installation identifier and service metadata are distinct from SwipeLess's own installation keys. They are not raw accessibility or screen-time events. Turning off visible notification alerts or pausing SwipeLess backup does not itself stop every Google SDK operation.

After sign-in, SwipeLess sends a Firebase ID token over HTTPS to its Cloudflare-hosted lifetime server, with a short-lived challenge and proof from an Android Keystore installation key. The server verifies signature, project, issuer, expiry and verified identity; an email or client-supplied account ID is not authority. It derives a pseudonymous identifier from the verified project/UID. A verified linked Google identity can retain an older Google-based lifetime record. The earlier Google-only app route remains compatible with the same server. Entered codes and temporary server session tokens stay in app memory; a code is sent only after you tap Redeem code.

The server stores pseudonymous account associations and, after activation, a lifetime identifier, grant time and hashes of installation public keys. Those records provide recovery on the same SwipeLess account until you delete it. Switching off or changing the shared code stops new activations and does not remove existing lifetime. These entitlement records do not include blocking settings. The separate progress backup is described below. Cloudflare processes the service's network and database traffic.

Login challenges expire after five minutes; app sessions expire after at most one hour. Expired authentication records are removed in bounded cleanup during later sign-ins. Network rate limits use keyed hashes of network addresses (IPv6 /64); some sign-in/bootstrap, health and owner limits also group the larger IPv6 /48 block. Authenticated app traffic and failed lifetime-code attempts additionally use keyed account counters. Daily counters only apply to their current UTC-day window. Older records are selected for deletion in bounded batches when later traffic arrives. They can remain longer when traffic is quiet or a cleanup backlog remains; this is not a fixed 48-hour storage limit. The application does not store raw network addresses or request bodies in logs. When a request fails, the server writes one technical line with only the fixed service path, the HTTP status and a fixed result code (for example "try_later"), so outages can be found (during an overload only a sample of these lines); it contains no network address, account, token or content, and Cloudflare keeps these lines for a limited time. Provider-side network processing is separate from these application records.

Alongside Firebase's managed session, the lifetime feature saves the server-signed lifetime proof and a hash binding it to the signed-in identity, bound to the Android installation key. SwipeLess checks the signature and account, package, environment and installation binding before using it. It works offline on that installation. After reinstalling or moving to a new phone, sign in with the same SwipeLess account to request a new proof. Settings and progress use the separate account backup; permissions and a running Work clock are not restored from the server.

Signing out clears this phone's lifetime proof and temporary session; the server lifetime stays available for later sign-in. To remove server account records and lifetime recovery, sign in and choose Delete account under Settings → Account, then confirm your current account with Google or its password. Confirmation uses Firebase reauthentication without signing you out or changing accounts. A fresh, signed Firebase token and installation proof authorise removal; an unverified email account may remove only its own account, without gaining backup or lifetime access. This removes the server lifetime/associations and progress backup, then the Firebase sign-in account. When Friends is enabled, account deletion also removes the social identity and its dependent server records, including the private baseline archive described above. A local account-hash marker keeps backup paused if deletion is unfinished, including after a restart. The remaining steps can be retried; the two services are not one transaction. Cloudflare D1 recovery history (Time Travel) can retain earlier states for up to seven days on Workers Free or 30 days on Workers Paid, depending on the active plan. Deleting the SwipeLess account does not delete your Google account, Play purchases or local Blocks/Work/Stats. Previously issued offline proofs are not remotely revoked; JWT verification alone is not an immediate provider-revocation check. A public deletion-request page and final SDK review are required before consumer publication.

Account backup

When you sign in with a verified SwipeLess account, automatic progress backup is enabled. You can pause it under Settings → Account → Account backup, or retry there. This feature is free and does not require a lifetime code. Firebase proves your account to the same Cloudflare server over HTTPS.

The server saves each Braintraining game's difficulty step, last played calendar day, whether its explanation was shown and whether a round was previously missed; and daily screen-time totals for the seven social apps listed in Stats, your selected Blocks/Work apps, and one foreground phone-time total, with date, time zone, measurement coverage and reliability. Extra app breakdowns outside those groups stay on this phone; an installed-app inventory is not uploaded. It also saves your Blocks choices (apps, package IDs, selected parts, limits, website targets and legacy relaxation/ turn markers), schedule definitions and enabled state, Work app/time/break/silence choices, appearance, your optional personal goal and profile-display choices, activity-category choices and notification preferences including planned reminder titles/times. Daily block counts per target/hour, alternative counts per category and used daily limit seconds have separate installation sources. There are no individual event timestamps in these uploaded totals. The server does not receive round answers, raw Android usage events, accessibility observations, notification contents, active Work clocks or device permissions. App IDs, website targets and settings can reveal your choices; they are personal data, not anonymous analytics. Own activity-library instructions and local detector/selection history are not included in this backup.

A random backup source ID distinguishes installations so a repeated upload replaces its own reading instead of counting it again. For screen time, a separate per-account phone tag is derived locally from Android's app-signing-key/user/device-scoped identifier, your account UID and the project. The raw Android identifier is not sent or logged. This tag prevents a reinstall's repeat reading of the same Android history from counting twice, without linking different accounts. Within a phone, overlapping daily app readings use the largest validated reading; separate phones' readings are added. Factory resets or signing-key changes can change the tag and require a continuity check. A specifically established old test pair can be mapped without deleting its daily records. Block/alternative/limit-counter sources remain per installation, because their events are separate. Separate phones' recorded times are combined; incomplete or unreliable readings stay marked. The server keeps saved weeks beyond the phone's 90-day measurement cache, until you delete your account. Older weeks download when selected. A bounded download cache, account hash, revisions and successful-upload hashes stay on the phone, without tokens or passwords. Service storage limits produce a visible retry/error rather than deleting older records to make space.

Offline, local games and measurements continue. A durable local queue records an account hash, content fingerprint, revision and acknowledgement or attention state, without passwords, tokens or another copy of your settings. Pending changes can retry through Android's network-constrained JobScheduler after the app's screen or process closes. One coalesced job waits at least five minutes; an hourly catch-up job covers missed scheduling, with exponential backoff for temporary failures. Android controls actual execution and can delay it. Pausing backup, signing out or unfinished account deletion stops scheduled backup; conflicts and expired sign-in need attention. There is no guaranteed upload time, and force-stop, uninstall or device restrictions can prevent execution. Unsaved offline changes cannot survive uninstalling. A fresh installation signed into the same account restores saved game progress, available week reports, settings and available daily counts. A previous live Work session is not restarted. Android permissions still require approval on each phone. Previously unsaved settings or counts cannot be reconstructed; a legacy restore shows when earlier block counts were not backed up. That day's counter source stays marked partial across later restores, rather than claiming a complete zero. Different game versions require a choice; a game played while restoration is running is not silently replaced. Local settings, progress, statistics and saved lifetime proof are kept separately for each SwipeLess account on this phone. Switching accounts opens that account's local profile and its own cloud backup; the previous profile is kept for signing back in. Android screen-time history is imported only for periods when that profile was active. The day of a switch may be incomplete and is not treated as a full day in average comparisons. Signing out keeps local data and saved cloud progress; existing protection continues locally until another verified account is opened.

Different settings versions require an explicit choice. A choice made during restoration is not silently replaced; ordinary Blocks keep their existing seven-day relaxation rule, and Work stays freely editable. Counter sources are combined once; downloaded totals never become new local uploads. Saved count history is retained on the server; Home and rolling count details use a bounded 90-day download cache. Screen-time week reports keep their separate older-week loader.

Account deletion removes live progress, settings and count records with the lifetime records, and the social identity and dependent records described in the Friends section. A pseudonymous deletion marker blocks late token retries for seven days, then expires during bounded cleanup. Cloudflare D1 recovery history may retain an earlier state for up to seven days on Workers Free or 30 days on Workers Paid, depending on the active plan. This does not erase your local app data or delete your Google account.

The owner also keeps manually exported, encrypted server recovery archives in a private Google Drive, with the recovery password held separately. These can contain older account records, settings and daily totals; they do not contain Firebase's password database. Deleting an account from the live service does not rewrite an existing archive. Such a copy can retain older records until the owner removes the archive, separately from D1’s plan-dependent recovery history described above. Google processes the encrypted file and its storage metadata. A fixed archive retention and a deletion check before restoring service are still release requirements for this test service; there is no automatic archive-expiry promise.

Optional Android screen time

Stats offers Social media, Block apps and All screen time. Social media covers Instagram, TikTok, YouTube, Facebook, Snapchat, X and Threads, including messages, whether blocked or not. Block apps covers apps with an active ordinary Blocks rule, independently of Work and Schedules. All screen time covers recorded foreground app time, including Home, Settings and SwipeLess itself; it is not display-on time without a foreground activity. Screen-off and locked intervals and background-only audio are excluded. With concurrent activities, the latest resumed activity counts once. Social websites used in a browser count as browser time, not as their native social app. You choose whether to allow usage access in Android Settings. Blocking still works without this access. You can turn it off again in Android Settings at any time.

With permission, SwipeLess reads Android's recent app-resume/pause events and screen, lock and restart times. App and activity identifiers are used temporarily to follow app changes; this also requires events from apps outside your selection. It does not read screen text, messages, search text or notification content. Daily foreground app times and coverage and a separate phone total are kept locally for up to 90 calendar days so you can inspect each scope and app. Account backup includes only the social/selected app readings and phone total described above. Other app breakdowns stay local. No complete installed-app inventory is collected. A small clock checkpoint detects changes that make comparisons unreliable. Raw event history is not saved. Historical selected-app readings cannot stand in for missing phone totals; the new total has its own versioned measurement key.

This is time derived from Android's latest resumed app, including any time Android attributes to an app underneath a blocking overlay. It is not time saved, Work time or a measure of attention. Android keeps only a limited event history. Missing or incomplete days remain marked as such; older feed measurements are never presented as whole-app time. Turning off access stops refreshes but keeps previously saved daily readings on this phone.

In Facts you can tap the source under a fact, and Credits has links to two licences. Those open in your own browser. SwipeLess only hands over the link and sends nothing itself.

Google Play purchases

Google Play handles purchases, payments and subscription management. SwipeLess uses its official Billing library to request available products and prices and to check purchase status. Google handles the payment details; SwipeLess does not receive your card details or Google password. Without the required Play product and verification configuration, purchase actions stay unavailable and no purchase access is granted. Current app features remain available in this build.

Purchase responses, signed receipts, signatures and purchase tokens are used only in process memory to check configured products and acknowledge a confirmed purchase to Google Play. SwipeLess does not save or log those records, and does not send them to its own server. A pending purchase, an entered code or a return from Google Play is not by itself confirmed access.

If confirming a verified purchase fails, SwipeLess keeps a bounded list of one-way purchase identifiers on the phone, outside account and Android backups. These identifiers are hashes of the app package and purchase token, not the token or receipt itself. They are not uploaded or used to grant access. Android can retry confirmation when a network is available, including after process loss or a restart. Each attempt queries Google Play again and verifies the current purchase before confirming it. Only positive confirmation for the matching purchase removes its identifier; an empty query or another Play account does not erase outstanding work. Android may delay background work, and force-stopping or uninstalling the app prevents this client retry; this is not a guarantee that a purchase is confirmed within a fixed time.

Checking purchases uses the current Google Play account. That route is separate from your SwipeLess lifetime account. The in-app lifetime code field uses the SwipeLess server route above.

Google's Billing library also documents service/API-use and performance/error diagnostics. The precise fields and retention for the final release dependency set still require review; SwipeLess does not promise that the Google SDK sends no technical data. The app does not request location access or call location APIs, including from a transitively included Google library. Read Google's privacy policy for Google's data handling.

During a work session SwipeLess shows a quiet ongoing notification: ‘Work mode’, with the time that is left and which silence is on. While it runs, the minutes that are left also show as its icon in the status bar. Permission to show notifications (POST_NOTIFICATIONS) is requested only after you choose it during phone setup, enable notification options, or start a work session. Granting Android permission during setup does not switch on additional notification preferences.

SwipeLess also gives a short message when a planned break starts, the next work block starts, or the session finishes naturally. While SwipeLess is visible, it uses a dialog with one OK button. The dialog stays until OK while the same phase still applies. Outside the app, it uses one current notification in the separate ‘Work transitions’ channel, with high importance and sound and vibration off by default. Your notification permission, channel settings and Do Not Disturb determine whether Android shows it above another app; that appearance is not guaranteed. An outside notification lasts at most one minute and is removed when its phase no longer applies. These messages contain only the phase, not app names or a personal task. They are made on your phone and send nothing anywhere.

These messages do not change the session, its clock, app protection or silence. Manual pauses, resuming, editing the session's duration or break plan, ending a break early and stopping a session do not create phase messages. Old or uncertain transitions are not replayed when you return to the app or after a restart. A short interruption can still deliver the fresh current phase once. A local progress marker prevents the same transition from being shown twice; there is no list of past messages.

ACCESS_NOTIFICATION_POLICY – ‘access Do Not Disturb’ – only does anything if you choose ‘Do Not Disturb’ for a work session or recurring schedule and then give SwipeLess that access yourself, in your phone’s settings. It’s used to turn Do Not Disturb on while that protection is active. Ending one session or schedule doesn’t turn it off while another still needs it. It doesn’t let SwipeLess read your notifications, and it doesn’t change who’s allowed to reach you: your own Do Not Disturb exceptions still apply.

Recurring schedules use RECEIVE_BOOT_COMPLETED to restore the local schedule after your phone restarts. They also use SCHEDULE_EXACT_ALARM for alarms at their start and end times. On Android 12 and later, you give that special access yourself in your phone’s settings. Without it, Android may run a schedule transition later; the Schedules screen warns you when this access is missing. Neither permission reads your screen or notifications, or sends anything anywhere.

What the accessibility service reads

To tell a feed apart from the rest of an app, SwipeLess uses Android’s accessibility service to read the structure of the screen you are looking at.

For Snapchat Discover, this includes the visible public viewer controls, such as a favourite or subscribe button, together with the full-screen viewer and Discover card structure. SwipeLess does not read who you follow, subscription state, story names or the contents of those stories for this check. A private story's shared player alone does not identify a Discover feed.

It only does that in an app where you block or time a part, such as Reels in Instagram. For every other app – your bank, your messages, an app you blocked completely, an app you never set up - it reads no screen text or interface structure, with one exception for browsers described below. It only notices which app is in front, so that a time limit stops counting when you leave. While a blocking screen is visible, a reported move to another app is checked against the active window's app identifier, with at most two short retries if the move is not yet confirmed. These header checks read no child views or text. They prevent delayed background events from removing a current block.

When at least one supported partial-feed rule is enabled, an additional check of the active window's app identifier runs about every two seconds while the phone is awake and unlocked. This catches a missed app-switch or screen-change event. It reads no child views or text from other apps. Only a selected partial-feed app without a recent screen evaluation receives the existing redacted structure check. The extra checks stop with a blocking screen, a call/alarm interruption, account-profile switching, or an unavailable service. They add no wake lock, screen recording, uploaded observations or saved app-switch history.

SwipeLess also acts. It puts the blocking screen over an app, feed or website you set up. While a whole-app block applies, that screen stays until you make a choice or actually leave the app; waiting alone does not remove it. A chosen exit can go to Home or open a SwipeLess task or exercise. SwipeLess can also tap the Messages tab to take you out of a blocked feed.

While that blocking screen or an enabled feed-video cover is visible, SwipeLess temporarily mutes the shared media sound, including music from other apps. It first requests a short audio-focus transition; Android may fade a player, and after about a second shared media is muted even if that player ignores focus. It does not set the numerical volume, send play commands or read media titles, sessions or content. A recognised volume-button change takes priority for the current continuous protection. A short gap between successive video covers does not restart the sound; leaving the protected feed ends its own request immediately. A full blocking screen and feed covers can overlap without releasing each other's request. Calls, alarms and leaving all protected views release SwipeLess's own mute; an already muted phone is not unmuted. Android's audio mode and the anonymous playback usage kinds (alarm, ringtone or communication) are checked only while a block or feed-video cover is visible, to give those sounds priority. No player identity or usage list is stored. Only one local ownership bit is saved, before muting, to undo an unfinished mute on the next app start. Force-stop cannot run cleanup until the app starts again. A new mute while the stream is already muted is indistinguishable from the existing mute; Android does not report who owns it. Fixed-volume devices and remote playback may not follow phone media volume.

SwipeLess gives recognised calls and alarms priority. When a notification appears, the accessibility service sees only its kind and whether it asks to fill the screen. If it is an incoming call (also through an app) or an alarm or timer going off, the blocking screen steps aside straight away, also when your phone is on silent or vibrate. SwipeLess checks again when the call or alarm is over, or at the latest after half a minute, or a minute for an alarm. An alarm that is still sounding after that minute keeps priority while it sounds. Initial and extended alarm windows together are limited to fifteen minutes per hour; replacing a notification does not restart that allowance. Notification-based call windows have their separate five-minute hourly allowance. The phone, alarm-clock and other critical system screens remain reachable. For sounding-alarm extensions, SwipeLess only checks whether a sound of the anonymous kind "alarm" is playing, not which app plays it. It doesn't read who is calling, an alarm's label or any other part of the notification, and it keeps nothing.

If Instagram opens straight onto a feed you blocked, SwipeLess may tap its Messages tab once, within three seconds of the app coming to the front. Seeing an allowed screen with a visible Messages tab, including a tab that is already selected, ends that opening allowance. Choosing Reels afterwards follows your normal block instead of redirecting you again.

Before that tap, SwipeLess checks that the active window still belongs to the same app. After Android accepts the tap, it waits half a second and checks that app's current screen structure. Feed events during the tab transition do not open a blocking screen based on the old screen. The fresh check applies your normal rules. Leaving the app, a call or other critical screen, Work mode or a whole-app block cancels the pending redirect check. This uses the same fixed tab IDs and interface labels, visibility and selected state; it does not retain your message text or add any stored screen content.

If a whole app you blocked carries on in a small window in a corner (picture-in-picture), such as a video, SwipeLess closes that window too. The same applies to a selected blocked feed when its blocking screen was showing over that feed as you left for Home, or when a fresh check of that app's redacted structure definitely confirms that same feed. A normal allowed video that you put in a small window without a blocking screen stays open. When you leave for Home or choose a task or exercise from its blocking screen, SwipeLess checks the open windows for up to two seconds. It reads only whether a window is picture-in-picture and which app a small window belongs to, and closes only that blocked app's small window. A Home event while a blocked feed still owns the active window can trigger this bounded check once for that visit; Home must still be confirmed separately. A small window of another app, such as a video call, stays where it is. No screen content is saved or uploaded by this check.

In split-screen, SwipeLess can briefly check the app identifiers of the other visible windows when the active app occupies only part of the display. This enforces whole-app protection, including Work, Schedules and challenges, and is checked again when those protection settings change. This check reads no page, message or video content from the other window. A feed-only or website-only rule does not turn that other app into a whole-app target. These window checks do not store or upload screen content.

If you choose Reels on Home for Instagram, SwipeLess covers videos in the Home feed with a green panel instead of blocking the feed. To keep that panel on the video while you scroll, it asks Instagram for the on-screen position and visibility of a few fixed video component IDs, up to once per screen frame. It does this only while Instagram is in front, only while the feed moves or changes, and only for those IDs. It reads no text, captions, names, image content or descriptions for this. The positions are used to draw the panel and then discarded; nothing is stored or sent. The panel never takes touches, so scrolling and tapping still go to Instagram. If you set minutes or turns for that feed, the videos are shown while you have time left, and that time counts in the same local counters as Reels.

Videos in timeline for X works the same way in X's timeline: only the video that is playing is covered, located by a fixed video component ID, and only while X is in front. A video that is not playing shows its still first frame. Nothing is stored or sent.

Videos in feed for Facebook works the same way in Facebook's feed and its full-screen video player. Facebook gives its screen parts no fixed IDs, so SwipeLess walks the visible on-screen structure of the Facebook window and asks each part only whether it is visible, where it is, how many parts it contains and what kind of view it is, to find the surface a video plays in. It reads no text, captions, names, image content or descriptions, only while Facebook is in front and only while the feed moves or changes. A video that is not playing stays visible. Nothing is stored or sent.

Websites are blocked through the address bar of a known browser. SwipeLess uses fixed address-field IDs. In recent Firefox versions it finds only the address node within the fixed browser toolbar, with a bounded scan of component IDs; it never scans the page. Only the title-free address label is accepted. Unknown labels and editing fields are not used as addresses. The fixed-field list also includes Firefox Focus, Firefox Klar and Ecosia. Those additions are based on published browser source and still need device-version checks. SwipeLess checks the field's app identity and ignores ambiguous duplicate fields; it does not search arbitrary app pages.

SwipeLess reads the address only while one of your website blocks or time limits can apply, including the web version of an app you selected. It does not read a focused address field while you type. The observed browser address is compared on your phone with your own rules and then discarded. Observed browsing addresses are never kept, logged or sent. Website targets you deliberately add are settings and are included in account backup. Browser time is counted only for recognised selected targets, using the same local daily seconds and turn counters as your app rules. A different site, typing, an unreadable address bar, leaving the browser, screen off and the blocking overlay stop counting. There is no browsing history. If there are no applicable website rules or limits, browsers are not read. The app shows which browser families were tested; other versions and embedded browsers are not guaranteed. Some things are not seen: a browser that is not on that list, a browser that renamed its address bar in an update until SwipeLess is updated too, a website you installed as an app from your browser, and links that open inside another app.

Text on that screen is stripped away at the moment it is read, before anything else happens with it:

• Anything longer than 24 characters is replaced by <REDACTED>.
• Anything shorter is only kept if it appears on a fixed list of interface words such as ‘Home’, ‘Reels’, ‘Search’, ‘Share’ or ‘Settings’.
• Everything else – messages, names, captions, comments, what you typed in a search box – becomes <REDACTED> as well.

This happens in every build, including the ones used for development. What SwipeLess works with is therefore the shape of the screen: which components exist, what they are called by the app’s developers, how large they are. Not what they say. The address bar of a browser is the one exception, and only for the comparison described above.

Work silence and optional existing notification access

Work sessions and Schedules offer Off or Android’s Do Not Disturb. Do Not Disturb requires separate access in Android settings and follows your own exceptions. It suppresses interruptions; notifications may remain in the notification panel. SwipeLess does not change your exception policy. The earlier These apps option is removed. An old per-app choice becomes Off, including after account restore; it never silently becomes Do Not Disturb. Work no longer requests notification access.

If you previously granted notification access and keep it enabled, the optional listener only reads whether a posted or removed notification is a call or alarm. This lets an existing block return promptly after a call or alarm. It reads no title, text, sender, package, key, ongoing flag, group flag or removal reason. It stores and uploads no notification data. You can revoke this access in Android settings; Do Not Disturb does not require notification-listener access.

SwipeLess no longer postpones or dismisses notifications. Notifications that an older version already postponed remain subject to Android’s existing timer. The new version does not take ownership of unknown postponed notifications or of ones you postponed yourself.

What’s stored on your phone

The table describes SwipeLess’s own storage on your device. Uninstalling removes this local copy. Account backup also saves the selected settings and daily aggregates listed above; signing out or uninstalling does not delete those server records.

Time limits are now set separately for each app. If you previously used shared time, SwipeLess converts those settings once. An existing individual rule stays as it is; an app without an active individual rule receives its earlier selected target and minute limit as its own rule. Each app keeps only its own earlier limit use, with any needed difference recorded separately from measured usage. Another app's contribution does not reduce its time. The original records stay in a local archive and are removed when you uninstall SwipeLess.

After an interrupted earlier clock, affected apps stay closed for the uncertain local day. Unknown gaps are not presented as measured use. If the saved settings cannot be read or converted, they are left intact and known protection stays in place; the app shows that the saved limits need attention. Ordinary app edits become available after the conversion succeeds. Work remains freely editable.

The schedule data also has a local recovery copy on your phone, for restoring protection if its main record cannot be read. Saving an accepted change to a schedule applies its apps, times, weekdays and silence choice to its running period immediately. An accepted deletion stops that schedule's own active periods. All existing Work settings are freely editable, repeatedly and while running or paused. You can shorten or extend a manual session's total work time, change its work/break plan, add or remove apps including the last one, and change silence. Worked progress and manual pause state are preserved. App choices do not reset the clock or plan. Shortening to time already worked ends the session immediately, without a natural-completion message. Do Not Disturb follows the chosen Work or Schedule setting and your Android exceptions. Schedules allow repeated changes to name, apps, times, weekdays and silence, as well as on/off and deletion. Work edits do not use the seven-day Blocks restriction. Valid input and successful storage are still required; a stale editor cannot change a different session or recreate a deleted schedule. Other schedules and protection sources continue independently. Ordinary process or clock recovery preserves stored protection when the time is uncertain.

Protected time is counted only while the blocking service is running and a session or schedule is protecting selected apps. Time with the service off is not counted. Unknown gaps between processes are not filled in later.

When you finish the introduction for the first time, notification categories are enabled unless you already saved your own choices. You can change them in Settings → Notifications. Android permission is separate and can be refused. Replaying the introduction does not reset your choices. You can separately choose protection warnings, Work transitions, planned activities and progress updates, with quiet hours from 22:00 to 08:00 by default. Android permission, channel settings and Do Not Disturb still apply. Focus goals and records use exactly completed manual Work sessions from this update; they do not prove attention or time saved. Weekly screen-time messages require two complete, comparable calendar weeks for the same selected apps. Progress is bundled into at most one update per day. No optional notification appears over an active blocking screen. An activity reminder uses only the title, time and days you explicitly entered. Tapping a notification opens SwipeLess and does not give access to blocked apps. Power saving and force-stop can delay or prevent delivery; old activity and schedule warnings expire instead of being replayed.

Weekly review starts recording with this version. Earlier time-limit totals are kept but are not reconstructed as separate app or feed history. Only apps and feeds with a time limit or short turns are timed; it does not measure all phone use. Coverage is observed while the blocking service is healthy. Missing service intervals and uncertain clock changes are not filled in. Week-to-week comparisons require complete, comparable coverage in both periods; today is excluded. Recorded Work time excludes planned breaks and manual pauses in a session. An active schedule can still count during a session's break; overlap is counted once. Protected time includes breaks while the selected apps remain blocked. These totals are not proof of attention, work done or time saved. Completion counts record a manual session when it finishes naturally; cancelling it or ending it by shortening the total to already worked time does not count as a natural completion. One new blocking intervention counts as one attempt; refreshing its explanation does not. The new review records only daily counts by night, morning, afternoon and evening, without adding individual attempt timestamps. These aggregates and the latest anchor stay on the phone.

SwipeLess does not record private text from other apps’ screens: messages, senders, account names or feed contents. It does not read your location or contacts. Optional lifetime uses the separate installation key and verified SwipeLess account described above. Text you deliberately enter as an own activity is saved locally, as described above; that text can contain personal information if you choose to include it.

The one thing worth spelling out, because it’s the closest SwipeLess comes to a record of your behaviour: it knows that you opened a feed and for how long, per app per day. It doesn’t know what was in that feed, whose it was, or anything you did inside it.

What leaves your phone

Account sign-in, lifetime requests and the account backup described above leave the phone. When you use the optional Friends or PIN-recovery features, their signed requests also leave the phone, as does your notification token for Friends messages. Save sharing publishes the chosen fields and the matching summary together. While My profile is open, summaries for already chosen fields may refresh automatically. Nothing is shared by default. The separate Back up / restore my baseline action sends or retrieves your private baseline archive. A challenge sends its apps, duration and your friend's opaque identity, and afterwards only the per-app count of attempts. A PIN reset email goes through Brevo. The app PIN, its digest and its local verifier are not sent. Loading your own profile photo makes an HTTPS request to Google's photo service as described above. Active Work clocks, accessibility observations and other apps' notification information are not uploaded. Google Play receives purchase-related requests; Google SDK/service diagnostics are separate. SwipeLess has no separate custom Play Integrity attestation flow or general device backup. Firebase Auth includes security-related dependencies; their presence is not a claim that SwipeLess enabled phone/SMS authentication or Analytics.

Uninstalling SwipeLess removes its local data. It does not remove Google Play purchase records or cancel a subscription. Manage purchases, subscriptions and Google's data through Google Play and your Google account.

The list of apps on your phone

To let you pick an app to block, SwipeLess asks Android which apps can be started from your home screen. It doesn’t ask for the full list of installed packages, and it doesn’t keep or send this list – it’s read when you open the screen and forgotten when you leave it. The identifiers and names of apps you actually select are saved with your settings and included in account backup.

Children

SwipeLess isn’t aimed at children. It has no age profiles. The same local handling described above applies to anyone using it, including text deliberately entered as an own activity.

Changes

The account and backup server is described above. New external data processing must be described here before it is used.

Contact

For support, access/correction questions or an account-deletion request, email getswipeless@gmail.com. Do not send your password, app PIN, lifetime code or private screen contents. Account deletion is also available in Settings → Account → Delete account and requires confirmation of your current sign-in. A request by email also needs verification of account ownership before account data can be removed. Deleting an account does not cancel a Google Play subscription; manage that separately in Google Play.

The web resource for deletion requests is the section "Delete your account" above (getswipeless.com/privacy#delete-your-account). The final provider identity, applicable legal bases and fixed recovery-archive retention must be completed before consumer publication.