Skip to content
Awake Qubit
FeaturesUse CasesPricingBlogSupport
Download Free on the App Store Download Free

Privacy Policy

Effective date: July 20, 2026 · Last updated: September 22, 2026

What changed on July 20, 2026. Earlier versions of this policy said Awake Qubit collected no analytics about how you use the app, and that we had no servers. Neither is true any more. We have added product analytics (on by default), and we operate a small relay that forwards notifications to your iPhone. Both are described in full below.

We are flagging this at the top rather than letting you find it by re-reading the page, because it is a change in the direction that matters: we now collect something we previously told you we did not. If it is not a trade you want to make, the off switch is here, and the app works identically without it.

Awake Qubit keeps your data where it belongs: your sessions, the apps you watch, and your session history stay on your device and in your own iCloud account. There is no account to create, no advertising, and no data broker anywhere in this app.

We do collect product analytics: a timestamped record of certain in-app actions, tied to a per-install identifier, so we can see which features get used. It is on by default. If you have never touched the setting, it is on. You can turn it off in one tap (Share Usage Analytics), it takes effect immediately, and this page lists every event it can send.

What leaves your device

Five things can leave your device, and nothing else:

  • Crash & diagnostic reports: so we can fix bugs.
  • Product analytics: a timestamped record of certain in-app actions. On by default; you can turn it off.
  • iCloud sync data: your sessions and device state, synced through your own Apple account. We cannot read it.
  • Lock Screen notifications: when your Mac updates your iPhone's Lock Screen or alerts you, the message passes through a relay we run. These messages contain your Mac's name, and for watched-app alerts the name of the app that quit. Described below.
  • Referral program records: a salted one-way hash of your iCloud record identifier reaches a small ledger we run, on a daily status check when you are signed in to iCloud and whenever you use the referral screen, and Apple sends that ledger its server notifications about Awake Qubit Pro purchases. Described below.

We have no account system and build no user profiles. Two per-person records exist: the Apple push token needed to deliver a notification to your phone, and, in the referral program, the hashed iCloud record identifier described below, which the App Store privacy label lists as a User ID linked to you, because the ledger stores your invites and referred purchases under it. We never sell or share your data with data brokers, we run no advertising, and nothing we collect is used to target you.

Data that stays on your device

Awake Qubit reads the following data locally to do its job:

  • Power Assertions: the same wake-lock information macOS exposes to any process with normal permissions. This data never leaves your Mac.
  • App preferences: your settings (overrides, notification preferences, etc.) stored in your app's sandboxed container or iCloud Key-Value Store, accessible only to you.

iCloud sync

Device sync uses Apple's iCloud infrastructure to sync state between your Mac and iPhone on the same Apple Account. The sensitive fields (the apps you watch, your device names, your activity history) are stored with field-level encryption in your own private database. This data is governed by Apple's Privacy Policy. We never have access to your iCloud data.

Lock Screen notifications

To show a live session on your iPhone's Lock Screen, or to alert you when a watched app quits while your phone is locked, your Mac cannot talk to your phone directly. It has to go through Apple's push service, and reaching that service requires a signing key that must never ship inside an app. So your Mac sends the message to a small relay we operate, which signs it and hands it to Apple.

These messages contain your Mac's name (which for most people includes their real name, e.g. "Jane's MacBook Pro") and, for watched-app alerts, the name of the app that quit. They also carry your device's Apple push token and the session's start time and remaining duration.

The relay is a stateless function: it validates the message, signs it, forwards it to Apple, and returns Apple's answer. It has no database and no storage attached, and it does not log the contents of these messages. The only thing it writes to a log is a failure to sign, which contains no message content. Like any internet request, reaching it reveals your Mac's IP address to Cloudflare, which operates the edge it runs on and keeps standard request logs.

You can stop these messages entirely by turning off notifications for Awake Qubit in your iPhone's Settings, or by turning off the Lock Screen session card. Local notifications on the Mac itself never use the relay.

Product analytics

Awake Qubit sends a small set of in-app actions to PostHog, our analytics processor, so we can see which features get used and where the app confuses people. Your data is processed on their European Union (Frankfurt, Germany) servers. PostHog is a US company; onward transfers are governed by our data-processing agreement with them.

These are the only events the app currently records:

  • App launched: with the platform (Mac or iPhone).
  • Setup step reached: which step of the iPhone pairing walkthrough you got to (open the Mac app, same account, iCloud), and reaching the finish. This is how we see where setup loses people.
  • iCloud check result: during setup, whether your iPhone could reach iCloud (available or unavailable). Not why, and nothing about your account.
  • Setup troubleshooting opened: that you tapped "Not connecting?" during setup.
  • Session started: the kind of session (timed, indefinite, app-based, battery) and whether it came from the Mac or the phone.
  • Session extended: how many seconds were added or removed, and whether it came from the Mac or the phone.
  • Session stopped: why it ended (manually, expired, the watched app quit, battery, or unexpectedly).
  • Remote action from your phone: which action (extend, stop, keep awake, let sleep, lock screen), and whether you tapped it in the app or from a Lock Screen notification.
  • Result of a phone-started session: how long the Mac took to answer, and the outcome. The outcome can record that the Mac was unreachable, that your watched app wasn't running, that your battery was below your threshold, or that the action needed Pro: the fact, never which app or what battery level.
  • Connection pill shown or tapped: with the connection state (connected, asleep, reconnecting, unreachable, not paired).
  • Lock Mac tapped, and separately whether it succeeded, plus how long it took.
  • Connection health opened, and which control opened it.
  • Mouse Wiggler switched on or off, and its idle threshold in seconds.
  • Upgrade screen shown: that the Pro screen appeared, and which feature prompted it (e.g. Smart Pause, iPhone remote control).
  • Purchase started / completed, trial started, restore tapped: that you began or finished buying Pro, started a free trial, or tapped Restore, and which plan (monthly, annual, lifetime). Never any payment details. Apple handles the transaction; we only see that it happened, and the amounts come from Apple's own reports, not from here.
  • Referral screen viewed (referral_screen_viewed): that you opened the referral screen, and which state it showed (the introduction, the screen for someone who applied a friend's code, your referral stats, or one of the "not available right now" states).
  • Invite code requested (referral_start_completed): that you tapped "Get my invite code", how it ended (created, already created, paused, signed out of iCloud, could not verify with the App Store, or failed), and how many milliseconds the request took. Never the code itself.
  • Invite shared (referral_invite_shared): that you tapped Share or Copy on your invite code, or the gift button on a reward you earned. Which button, never who you shared with and never the code.
  • Invite code applied (referral_claim_completed): that you applied a friend's code and how it ended (a code was issued, recorded, not eligible, already applied, your own code, unknown code, paused, could not verify with the App Store, a mistyped code, or failed), plus the request time. Never the code.
  • Reward requested (referral_reward_requested): that you asked for a reward you earned, whether it was for yourself or a gift, how it ended (issued, issued again, none available yet, nothing earned, unavailable, or failed), and the request time.
  • Redeem sheet opened (referral_redeem_opened): that you tapped Redeem on an offer code, whether Apple's redeem sheet or the copy-a-link fallback opened, and whether it was an invite code or a reward code.
  • Redeem sheet closed (referral_redeem_completed): that Apple's redeem sheet closed, or that it could not open, and whether it was for an invite code or a reward code. Apple does not tell the app whether a code was redeemed there, so this event does not say either, and the reason the sheet could not open is never sent.
  • Invite code sheet opened (referral_claim_sheet_opened): that you tapped "Have an invite code?" on iPhone.
  • Referral notification shown (referral_notification_posted): that the app showed you a local notification about a reward you earned.

The referral events are listed with their internal names because a test in the app's own source checks that every one of them appears on this page before a build can send them; the other events above will get theirs the same way. None of these events ever contain an invite code, a reward code, a redemption link, an account identifier, or how many friends you referred.

We send technical context with every event: app version and build, your device model (the hardware type, e.g. "MacBook Pro" or "iPhone", not the name you gave your device), the operating system and version, screen size, your language, your time zone, network type (Wi-Fi or cellular), whether the build came from the App Store or TestFlight, and the app's own bundle identifier. Every event also carries a timestamp and your plan (free, trial, monthly, annual or lifetime) as the app last confirmed it with the App Store, or simply "Pro" if it has not yet been able to tell which. That is the tier only: never a price, a receipt or any payment detail.

Two identifiers travel with these events: a per-install identifier generated the first time the app runs, which persists between launches and encodes the moment it was created; and a session identifier that changes after thirty minutes of inactivity. Neither is derived from your Apple Account, your hardware, or any advertising ID. Your Mac and your iPhone each generate their own, and we never join them together. That is a commitment about how we work, not a technical impossibility, so we are telling you it is a promise.

Taken together, that is a reasonably specific technical fingerprint, and the identifier persists. So we describe this data as not linked to your identity rather than "anonymous": a persistent per-install identifier is pseudonymous, not anonymous, and the difference is worth stating plainly.

What product analytics never contain

This section is about analytics specifically. The notification relay is separate and is described above. The events listed above never include:

  • The names or bundle identifiers of the apps you watch, or of any other app running on your Mac.
  • Your device name.
  • Your Apple Account, email address, or any sign-in identifier.
  • Your files, documents, photos, screen contents, keystrokes, or browsing.
  • Any advertising identifier: no IDFA, no IDFV, and no tracking across apps or websites.

There is no session replay, no screen recording, no screenshotting, and no automatic capture of taps or screens: every event above is one we wrote by hand. Before an event is sent, each value also passes a filter that redacts anything matching an email address or a version-4 UUID.

One thing we cannot promise: any connection to the internet reveals your IP address to the server at the other end, and analytics is no exception. We have switched off IP-based location lookup on our events, and we have set our processor to discard the IP address rather than store it, but that is a setting on their side, not something the app can enforce, and we would be overstating things if we claimed your IP never reaches them at all.

Referral program

Awake Qubit has a referral program: you can share an invite code, and a friend who applies it gets an introductory offer on Awake Qubit Pro while you earn a free month once their subscription settles. Running it needs a small ledger on a server we operate, separate from the product analytics above, and this section describes it.

What the ledger stores. A salted one-way hash of your iCloud record identifier (so we can recognise the same account twice without holding your account details), your invite code, the codes issued to you, the platform (Mac or iPhone), whether the app was an App Store build or a test build, timestamps, and, for a friend who applies your code and later subscribes, the Apple transaction identifiers Apple signs for that purchase. If Apple reports a refund of a purchase that could still count toward an applied invite, the ledger also records that purchase's original transaction identifier, so the refunded purchase does not earn a reward. The ledger holds no name, no email, no IP address, and no device name. This is what delivering a reward and preventing fraud require, and nothing else.

How long. Your referrer record (including the platform you registered from and any ban on it), the codes issued to you, and everything linked to an applied invite are kept while the program runs (unless you ask us to delete them, as below), because a reward can take months to settle and an issued code has to stay deliverable. A purchase that has already counted toward an applied invite stays linked to it, refunded or not, like the invite's other outcomes. When Apple reports a refund of a purchase that has not counted yet, the ledger keeps its transaction identifier only while an invite that purchase could have counted toward remains open, and deletes it at the next nightly clean-up after that. Apple's server notifications themselves, which carry the transaction identifier of every Awake Qubit Pro purchase they report, and refused reward requests are deleted within 180 days.

The invite link page. When someone opens an invite link (/r/ followed by a code), we count that visit against the invite code, whether the program was live or paused at the time, with no cookie and no script, in an aggregate that is kept for 90 days. The page's App Store button passes through the same first-party download redirect as every other download button on this site, and carries an App Store campaign parameter so Apple's own analytics can attribute the install to the program. We may also count how each request to the referral service ended (for example "paused" or "rate limited"), without the code and without your IP address, to watch the service's health.

Apple's server notifications. Apple sends purchase, renewal and refund notifications for Awake Qubit Pro subscriptions to an endpoint we run. We use them to settle referral rewards and to record refunds. They are signed by Apple and verified before anything is recorded.

The analytics switch does not affect the ledger. Turning off Share Usage Analytics stops every referral event listed above; it does not stop the referral service calls, which are app functionality needed to issue and deliver a reward. If you never use the referral screen, nothing about you reaches the ledger beyond the daily status check the app makes for an account that has signed in to iCloud and, if you subscribe to Awake Qubit Pro, Apple's server notifications about your purchases described above, which are deleted within 180 days.

Deleting your referral data. We don't store your name, email or Apple ID, so we can't look you up by them. Your invite code isn't enough either: it's meant to be shared, so anyone could send it to us. To prove a request really comes from you, the app shows a referral ID you can copy from the referral screen. Email that ID to privacy@awakequbit.com and we'll delete your referral data:

  • Everything that links your referral records to you is removed, and your invite code stops working.
  • Rewards you haven't collected yet are lost, and codes we've sent you no longer show in the app, so redeem any you want to keep first.
  • Friends who used your code keep their own invites.
  • Records of purchases that counted toward an invite stay, with no link to you, so refunds are still handled correctly.
  • Backup copies are cleared within 30 days.

If you use the referral screen again later, you start fresh, with no link to your old data.

What we will never do

  • No advertising, in the app or anywhere else.
  • No selling or sharing your data with data brokers. Not now, not later.
  • No advertising identifier, and no cross-app or cross-site tracking.
  • No session replay, screen recording, or screenshotting. Ever.
  • No account, so nothing that ties your usage to a real name.

Turning analytics off

Product analytics are on by default. We do not show a consent prompt, so to be plain about it: if you have never touched this setting, it is on. The switch lives under About, next to the version number, which is not the most obvious home for a privacy control, so here is the exact path:

  • On iPhone and iPad: Settings → More → Help & about → About → Share Usage Analytics.
  • On Mac: Awake Qubit → Settings → About → Share Usage Analytics.

Turning it off stops collection immediately (not at the next launch) and clears the identifier your events were recorded under. From then on the app does not contact PostHog at all: on later launches it never even starts the analytics component, so there is no connection to make.

Two caveats we would rather state than have you discover. While analytics are on, the analytics component checks in with PostHog when the app launches, even if you do nothing in the app. And switching off makes one final request as it tears the session down, which still carries the identifier being discarded. We can stop that identifier persisting, but we cannot un-send a request that has already left.

Crash reporting is separate from this switch: turning off Share Usage Analytics stops product analytics, but crash and diagnostic reports continue, because they are what tell us the app is broken.

Legal basis (EU and UK)

We rely on legitimate interests (GDPR Article 6(1)(f)) to understand how our own app is used. The switch above is how you object: you need no reason, and the app behaves identically either way. Some European regulators take the view that storing an analytics identifier on your device should require your consent up front rather than an opt-out afterwards. We have taken the opt-out route, and we would rather tell you that is a judgement call than present it as settled.

How long we keep it

Product-analytics events are retained for 12 months and then deleted. Crash reports follow Firebase's own retention schedule. The notification relay retains nothing.

Your data rights

Because analytics events carry no name, email, or account, we cannot find yours from anything you would think to give us. If you ask us to delete your past events, the only way we could locate them is with the per-install identifier stored on your device, and we do not currently show it to you. We are adding a way to see and send it. Until then, the control that actually works is the off switch, which stops future collection and clears the identifier locally. We are telling you this because it is a real limit on what we can do for you, not because it is a feature.

For anything else (questions, complaints, or a request about data held under another part of this policy), email privacy@awakequbit.com. You also have the right to complain to your local data protection authority.

Crash & diagnostic reports

Awake Qubit uses Google Firebase Crashlytics to collect crash and diagnostic data (the crash stack, device model, and OS version) so we can find and fix bugs. This data is not linked to your identity (Crashlytics uses its own per-install identifier, so the same pseudonymous-not-anonymous caveat applies as for analytics) and is never used for tracking or advertising. We also use Firebase Remote Config to adjust feature settings remotely, including the switch that controls whether analytics are collected at all; it sends a Firebase installation identifier and your IP address, and collects nothing about how you use the app. See Firebase's privacy and security for how Google handles this data. Separately, if you opt in to sharing diagnostics with Apple, Apple may also receive crash reports it processes on its own.

Third-party services

These are every company that may receive data from Awake Qubit:

  • PostHog (European Union (Frankfurt, Germany)): product analytics, as described above. Their privacy policy.
  • Google Firebase: Crashlytics for crash reports and Remote Config for feature settings, as described above.
  • Cloudflare: hosts this website and runs the notification relay, as described above.
  • Apple: iCloud sync, push notification delivery, App Store purchases, and (if you opt in with Apple) diagnostics, all governed by Apple's own policies.

Awake Qubit contains no advertising SDKs and no cross-app or cross-site tracking SDKs. PostHog, Firebase and Cloudflare work for us under contract. Apple's part is your own iCloud and your own push notifications, which we cannot see into.

This website

This site uses Cloudflare Web Analytics to count page views. It sets no cookies of its own, does not fingerprint your browser, and does not track you across other websites, which is why you see no cookie banner. Visitors from the EU are excluded from it entirely. Cloudflare also hosts this site, keeps standard server request logs, and may set its own security cookies at the network edge to filter automated traffic.

When you click a download button, it passes through a first-party redirect on our own domain before sending you to the App Store, so we can count which button people use. This sets no cookie, runs no script in your browser, and records only which button was clicked, nothing about you. The download link in a blog post also carries an App Store campaign parameter, so Apple's own analytics can attribute the install to the blog.

Children's privacy

Awake Qubit is a general-purpose utility and is not directed at children under 13. We do not knowingly collect any data from children.

Changes to this policy

If we change this policy in a material way, and especially if we ever start collecting something we previously said we did not, we will say so in a notice at the top of this page, as we have done above, and update the effective date. We will leave that notice up for at least ninety days. Continued use of the app after a change constitutes acceptance of the updated policy.

Contact

Questions about privacy? Email us at privacy@awakequbit.com.

Awake Qubit

You can walk away and trust your Mac.

Use CasesPrivacyTermsSupportBlog

© 2026 Awake Qubit. All rights reserved.