The old design solved billing by creating an identity system
A web checkout would have needed more than a payment button. Cueable would have linked a Stripe customer, billing email, subscription record, licence identifier and Mac activation identifier. A restoration flow would then need to decide which person owned which licence and whether a new Mac was allowed to replace the old one.
None of that would have exposed a card number to Cueable, because Stripe is designed to handle sensitive payment details. It still would have created a new set of customer-linked records for Quovane to secure, retain, explain and eventually delete. That is a real privacy cost even when every component is competently built.
- A billing email can identify a person
- A licence record links that person to a product and subscription state
- A device activation identifier can link a purchase to a particular installation
- A customer portal needs a safe way to authenticate the right customer
- Support requests can connect all of those records together
Data minimisation is better than a longer promise
Privacy policies often explain how a company protects information after collecting it. A stronger design question comes first: does the company need to collect the information at all?
For Cueable, the answer changed. Apple already has a trusted payment relationship with people who use the App Store. StoreKit can authenticate and charge the customer without sending their card details, Apple Account password or full billing profile to Cueable. That lets Quovane remove its own checkout, billing email database, licence-key recovery flow and device-transfer policy.
- No Stripe Checkout
- No Stripe customer portal
- No Cueable billing account
- No emailed licence key
- No one-Mac activation database
- No website payment form
What RevenueCat does and does not do
RevenueCat will sit between StoreKit and Cueable as a purchase-management layer. Apple still charges the customer. RevenueCat validates the Apple transaction and tells Cueable whether the stable cueable_plus entitlement is active.
That service still processes limited information. It can receive an anonymous App User ID, Apple receipt or transaction details, the product identifier, purchase and expiration dates, trial or offer status, refund state, device type, operating system and technical purchase diagnostics. Pretending that this is zero data would be dishonest.
The important boundary is that Cueable does not deliberately send study notes, flashcard content, recordings or learning history to RevenueCat. For the planned account-free design, RevenueCat does not need a customer name, personal email address or payment-card number. RevenueCat states that customer data is hosted using AWS infrastructure in the United States, which is disclosed in Cueable's privacy policy rather than hidden behind vague language.
Why Apple-only is a deliberate trade-off
Apple-only payments mean Cueable+ cannot sell a cheaper web subscription that bypasses the App Store. Apple controls the purchase interface, refund process, product rules and much of the customer relationship. That reduces Quovane's control.
In return, customers get a payment interface they already recognise, prices in their local storefront, Apple-managed authentication, subscription management through their Apple Account and a standard Restore Purchases path. Quovane gets less identifiable customer data and less custom security infrastructure. For Cueable, that trade is worth making.
- Apple shows the actual local price and terms
- Face ID, Touch ID or the Apple Account confirms a purchase
- Apple manages renewals, cancellations and refunds
- The same Apple purchase history supports restoration
- Cueable returns to the free tier if an entitlement expires without deleting study data
Privacy is not a personality claim
Removing Stripe does not make Cueable morally superior to every app that uses Stripe. Stripe is a respected payment platform and many products need web billing. The point is narrower: Cueable does not need that extra customer identity layer for its intended Apple-only release.
The work now is to make the final product match the promise. That means configuring App Store products correctly, keeping RevenueCat identifiers anonymous, disabling unnecessary data collection, reviewing the RevenueCat privacy manifest, testing restoration, and updating App Store privacy disclosures before launch. A privacy-friendly diagram is only useful if the shipping app behaves the same way.
The standard Cueable wants to meet
Customers should be able to install Cueable, use the free version, purchase Cueable+ and restore it later without creating a Cueable password or handing Quovane a new personal profile. They should also be able to read exactly which companies are involved and what each one receives.
That is why the website now says plainly that Stripe is not involved, RevenueCat receives limited purchase information, Apple handles the money, and study content stays outside the purchase system. Less customer-identifiable data means less information to lose, misuse or explain away later. That is the practical privacy benefit.