A kink app walks into app review.

01 The guideline that isn't about you.

Apple's guideline 1.1.4 targets "overtly sexual or pornographic material." Early on we treated it as an existential threat and seriously considered a PWA fallback — a web app hedge in case the stores said no. Then we looked at what actually ships: connected-toy apps with millions of installs live on both stores today. The distinction that matters to review is what's on the screen, not what the app is for. A relationship-management tool — tasks, rules, points, contracts, journals, chat — is not pornographic material, whatever the relationship it manages looks like. We killed the PWA hedge, committed to both stores, and budgeted for the review process as it really is: case-by-case, somewhat unpredictable, with a rejection-and-resubmit cycle treated as a normal cost rather than a catastrophe.

02 GDPR Article 9 is your real regulator.

The stores get the headlines, but the strictest rules we operate under come from data-protection law. Data revealing a person's sex life is special-category data under GDPR Article 9 — the highest protection tier that exists, same shelf as health and religion. Two consequences followed:

• Consent has to be explicit and its own act. An 18+ age gate with a bundled "I agree to the Terms" is not special-category consent. We designed the consent step as a distinct, informed action — not a checkbox smuggled into a continue button.
• The strongest compliance story is not holding the data at all. End-to-end encryption isn't just a feature for our users; it's the load-bearing wall of our legal posture. What we cannot read, we cannot leak, sell, or be compelled to produce. The honest counterpart: what we can still see — account identifiers, who is paired with whom, when ciphertext moves — is ordinary operator data, and lawful requests for it get answered like anyone else's. We list that residual in the privacy policy next to the encryption claim, not buried under it.

The same law reached into monetisation. We considered premium-gating data export and longer retention. GDPR Article 20 makes data portability effectively mandatory — so CSV export is free, forever, and the tiered-retention concept died on the table. The rule we landed on for premium is "flex, not function": colours, custom titles, groups, higher limits. Your security and your exit are never paywalled — the app lock (PIN + biometrics), CSV export, and account deletion all ship free: selling safety back to users of an app like ours would poison the entire positioning.

03 Privacy labels are a design constraint.

Apple's privacy nutrition labels and Google's Data Safety form look like paperwork you fill in at the end. They're not — they're a gate that reaches back into your feature list. Two examples from our roadmap:

• Biometric unlock costs nothing on the label. Face ID and fingerprint APIs return only success or failure — the app never receives biometric data, so there's nothing to declare beyond the usage-description string. Free feature, zero label impact. Ship it.
• Video would cost a label change, so v1 has no video. Adding video capture means declaring "Videos" as collected data on both stores, plus E2EE-sealing large files, size limits, and moderation questions. That's not a release note; it's a compliance project. Task-proof photos in v1 are images only, and the video hooks in our codebase sit deliberately unwired until we're ready to do the whole job.

04 Crash reporting that doesn't betray the pitch.

Every template app ships analytics on by default. For an E2EE app, phoning home crash data by default contradicts the entire pitch — a stack trace can carry more context than you think. In release builds our crash reporting is opt-in and off by default — nothing runs until the user flips the toggle. (Closed-beta builds default it on with a one-time in-app notice; testers join knowing that.) When it does run, events are scrubbed on-device before sending — query strings stripped, sensitive-keyed data redacted, and message content never attached in the first place — with ingestion pinned to EU servers. When a privacy reviewer — or a user with a proxy — looks at what your release build transmits on first launch, the honest answer should be: nothing.

05 What we'd tell the next builder.

• The stores review screens, not lifestyles. Keep the surface professional; the app's purpose is legitimate relationship tooling and you should say so plainly in review notes.
• Read Article 9 before you write a schema. If your data reveals sex life, your consent flow and storage architecture are legal decisions.
• Let the labels veto features. Check the declaration cost of a feature before building it, not after.
• Never paywall safety or exit. Locks, exports, and deletion are trust infrastructure, not conversion levers.
• Hold a rejection budget. One resubmit cycle is the price of admission, not a verdict on your app.